In Rancher 2.5, I could click three dots and get an “api view” from every deployment I wanted. In Rancher 2.6 I dont see this “api view” anymore.
All I want is get these:
actions ": {
pause
redeploy
resume
rollback
Any help?
The new UI effectively uses only the the native k8s API. This allow a bunch of new things (e.g. there was no way to see namespaces that aren’t in a project before), but leaves you with only that for your own automation and “actions” are not really a concept that exists in their API.
(In reality we actually talk to a thin layer on top of that, which we call Steve, at /v1, and if you turn on ‘devleoper tools’ in your user prefs there is actually still a ‘View in API’ action for it that will show you it. But we consider this an internal implementation detail and not a public API, there are no guarantees that anything about using it will still be compatible with any future release.)
But those are not going to be actions that show up in Steve either. All those really are are shortcuts for making a particular set of edits to the body of the workload and then saving it back.
- Pause & resume are toggling a boolean in the spec
- Redeploy changes an annotation’s value, which causes k8s to create a new replicaset and migrate over to it.
- Rollback is reading the config out of an old replicaset and patching it back in to the current spec, etc.
I get use to use API view for CI/CD using Azure DevOps, redeploy workload etc. How to manage it properly now?
@vincent thanks for clarification about /v1 API.
Can you say little more about current recommended public API for automation?
I thought, that /v1 - Steve - is new and recommended public API for Rancher 2.6+. “View in API” works fine for /v1 through browser dev tools as you said.
“Old” API, which mentioned @lolhax1337 is /v3 - Norman. This one is still presented in 2.6+, so @lolhax1337 you can use it without problems. And this is expected because 2.6 isn’t breaking change, so old API has to work.
As I understand
- Norman /v3 - is old one, it will be deprecated/deleted in rancher 3, maybe earlier in 2.7/2.8?
- Steve /v1 - is new one, but isn’t public and recommended for automation
What is successor of Normal /v3 as public API for automation when Steve isn’t?
There is no ‘successor’; k8s has an API that works fine and that is what we suggest you use for anything in a downstream cluster, and for managing the newer features that are ‘gitops’-aware (e.g. RKE2/K3s provisioning in 2.6) in the management/local cluster and meant to be directly manipulated from git/kubectl.
For older global-level things Norman/v3 is fine to continue to use. Some of the validation and event triggers actually only happen through there, so you should or in some cases must continue to use Norman for the global types it supports. (It can’t really be deprecated until all that logic is moved into validating webhooks or controllers watching for changes, which is not scheduled to happen any time soon).
Steve/v1 is a thin layer on top of the k8s API that maps some fields around so that the same UI client code can talk to it and Norman, and adds a few features that make the UI more useful or efficient. For example all ‘watches’ for live updating are combined into one websocket instead of many individual. There’s no efficient native way to get the counts of how many of each kind of resource for the left nav from k8s so steve provides that. The UI doesn’t want to decide how to summarize the conditions for every possible resource type into a single state string. That sort of thing.
But all that exists for our UI; there’s really no reason for you to use that, with a custom client to talk to it, versus using the regular k8s API. There’s lots of existing clients and swagger generators and such that support that, and your code will then work against any k8s whether it’s Rancher or not.
All the actions in this thread can be done as some variant of sending a PATCH to update a field on the target workload (or a PUT of the whole edited object).
Thanks @vincent for clarification.
Using rancher APIs - especially Norman/v3 - is very convenient for regular web developers, who aren’t skilled in devops/k8s so much. With help of API browser and UI itself, it’s easy way how to automate some basic kubernetes tasks without studying tons of k8s stuff. One example - json for new workload is very minimal in Norman and API creates service for you automatically. Super easy and nice feature.
As you said, I hope that old Norman/v3 will useful in next versions of rancher.
We already rewrote some task to Steve/v1, because there were troubles to manage some k8s resources from UI when was created from old API. So please make not so much BC breaks in this new Steve/v1 API 
Can you recommend some tooling or whatever is near and convenient for usage as old Norman/v3?
Thanks
Using rancher APIs - especially Norman/v3 - is very convenient for regular web developers, who aren’t skilled in devops/k8s so much.
Agreed. When we are testing Rancher in our environment is would be convenient to have an API that was more aligned to the functions presented in the UI, and so documentation around the v3 API would be beneficial.
Hi! As norman api is not being deprecated yet, is there any way to deploy charts with norman api but as new kind of apps so that can be updated/navigated on new apps menu (not as legacy apps)?
Or any other recommended way to deploy charts similar as it was possible with norman / old catalog system?
Thanks!
So how can i check my certs expiration date now?
I was following this doc: When will my cluster certificates expire? | Support | SUSE
A good question, I already wasted hours trying to find a solution.
Anybody found out how to check certificate expiretion wit Rancher 2.6?
Hi, just in case. Any news with this?
Any suggestion on how to deploy and mantain apps on rancher 2.6 / 2.7 VIA API?
With norman v3 we where doing something like this:
project.create_app(createData = {
“answers”: answers,
“targetNamespace”: appName,
“externalId”: catalogExternalId,
})
Thanks!