You’d use websockets. You can also layer on requests if you like, though I’m thinking that might be additional complexity.
Example: Websockets adapter for Python Requests library - Stack Overflow
1 Like
FYI, you can use our python API client from Windows:
PS C:\Users\15805\CODE\api_client> python3
Python 3.10.11 (tags/v3.10.11:7d4cc5a, Apr 5 2023, 00:38:17) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from truenas_api_client import Client
>>> with Client("wss://192.168.0.225/api/current", verify_ssl=False) as c:
... c.call("auth.login", "admin", "Cats")
... c.call("core.ping")
...
True
'pong'
2 Likes
1 Like
Again I feel like I’m being misunderstood. Nowhere did I mention that both pages need to be combined. But reusing the UI layout of the apps page would have been the bare minimum of introducing this instances page. The layout could have almost been copied over to the instances page. Two different pages yes. But why is the instances page so barren. The apps pages gives a quick overview of metrics. And quick view of the status with a coloured status button.
You already have that design done and it works. Why not apply it to the instances page also.
If Docker and the Incus engines provide the same data, that would be a good idea. However, I’d guess there are differences.
Correct, different back-ends, different things to wire up to get those same “stats” to be exposed. We expect to do that eventually, the cosmetic stuff will come later as the higher priority functional things get sorted out.
The same stats are already intending to be exposed in the side bar (not currently functioning though). What keeps you from exposing them in the instance line.
And why couldn’t you implement a coloured status button like on the apps page.
I really hear a lot of excuses but no concrete arguments why it’s so barren. While you could have just re-used the apps page layout for the most of it.
There is no reason why the status button couldn’t be UI consistent with the one in the apps page since it’s already exposed. There is also no reason why the metrics that are clearly intended to be exposed (now in the bottom of the side bar in graph form) couldn’t have been implemented in the instance line (just like on the apps page) even though not fully functioning yet.
I find the inability of JUST saying: “Yes we haven’t gotten to it yet but we will make it better soon.” troubling. Owning an issue is not a bad thing. Instead I get weird unrelated responses like I mentioned the pages should be combined…
In the blog video it is mentioned that the RC.1 version should be ‘feature complete’. Why always over promising and acting like RC.1 is an actual RC.1 while it’s more realistically BETA.2 because it is NOT feature complete and still ‘Experimental’ as the label on the page clearly states.
I really didn’t want to start a rant here but the overpromising and unfinished states of release versions have been a thing since the first beta of scale launched. I find it worrisome.
Personally I think the release schedule is a bit flawed. I would rather see a BETA.1 → BETA.2 (now RC.1) → RC.1 (now Release .0) → Release .0 (now .1)
I believe that’s much more in line with industry standards of what these release versions stand for. For a more stable and respectable release cadence. But that’s just my 2 cents.
Bottom line is that I hope the Instances page can be improved a lot. And that when it is mentioned something should be ‘feature complete’ in a blog video, that it actually is.
#RantOut 
We operate on a 6 month cadence for releases. Which means approx 3-4 months of development time.
This feature was considered a 2 cycle effort. Hence the experimental tagging & warnings until the next major release 25.10. That is intentional and we’ve made no secrets about it. (There are even pop-up warnings when you enter the UI to that effect) RC.1 as a whole being “feature complete” means we don’t anticipate to make massive sweeping changes in the 25.04 release cycle any further, those next major round of changes will be in 25.10 in the fall. We may occasionally slip an improvement in, but that will be the exception, not the rule.
Now you have fair points about wishing we had implemented in the same consistent style / manner as the Apps page. That is fair. But we didn’t. Not was it deemed vital to this half-way point. Getting all the basic functionality stabilized will take priority still on work still going on for 25.04.0.
1 Like
Thanks for all you do. Love riding this train…
Ha, while I can’t promise you anything will ever be PERFECT (nothing in life is), I can promise you it will be interesting! 
And you know that this statement is regarded as a curse in China, don’t you?
Honestly, 6 months feels too short. An annual cycle would leave more time to polish the product.
The mere fact that the offcial software status page still recommands 24.04 as conservative deployment today would support that a yearly cycle is enough.
“May you live in Interesting Times?” 
We came from yearly release cycles before. Wasn’t great and had its own issues as well. Maybe in the future we find a better way to handle bringing in features that are going to be two-cycle implementations though. Since so many seem confused by the “Experimental” label. We’ll noodle on that.
2 Likes
Now that is “interesting” in that in china it is a curse… I did some googleing and had some intersting comments…
“, and may government officials take note of you.”
2 Likes
It’s always tradeoffs. A year long cycle can get overloaded with features, because there isn’t another chance for a year. It can also be harder to coordinate testing for and ship.
6-month smaller releases can be more manageable, but also shorten available time so truly large features can’t land in one cycle.
Tradeoffs.
2 Likes
I don’t disagree with the 6 month cadence. It gives the opportunities to do some extra kernel and or driver bumps as other features between major version etc. I think this is a good call.
I just think RC.1 has never been really worthy of being named RC.1 and realistically has been more like BETA.2 (throughout the SCALE release history which I have been part of since Anglefish BETA.1). Just naming the release versions for what they more realistically represent would go a long way for the community for what we can actually expect from the releases versions.
You don’t have to agree with me of course. it’s just my opinion. But I did occasionally feel the community’s temperature about this and I have the idea that this is kind of the general consensus. That versions are being mislabelled too optimistically.
I hope the community here can pitch in and either support this notion or dispel it. For better feedback to the IX team.
However, I do understand the business model of using the Community Edition as a testing platform for the Enterprise side of things which actually brings in the money. I just think it can be done with a bit more grace towards the Community Edition, more realistically and slightly more conservatively naming release versions.
Why not by default have a round of two beta versions. BETA.1 and BETA.2 before going to RC.1.
Not to drag up a dead topic, but most of the entries in that chart are within margin of error of each other.
Please name the three year old (that would be 12th gen) mid-range Intel you feel is in the same performance class as the Ryzen 7 9700x.
Please, please, let the off-topic flamewar die! Do not feed the troll.
2 Likes
I believe you posted this at about the time that was changing
We are always slow to make a version as ready for conservative… we want te probability of finding a significant bug to be almost zero. That takes many system-months (100,000?) of successful operation.