You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, a user cannot find out on his own which metal-stack version is deployed in an environment. It is only known by the people who deploy the software (operators). A user can query the metal-api version endpoint, but it is not possible to deduce the actual metal-stack release from that.
However, it would be very useful for users to have this information such that they can automatically pull and use compatible clients to access the metal-api.
Question is if it does make sense to make the metal-stack version obtainable because operators can theoretically diverge from metal-stack releases with individual components such that there is no guarantee anymore that clients belong together.
metalctl update do checks against metal-api/version endpoint from which release this was deployed, fetching metalctl will then use the version specified in the metal-stack/release
At the moment, a user cannot find out on his own which metal-stack version is deployed in an environment. It is only known by the people who deploy the software (operators). A user can query the metal-api version endpoint, but it is not possible to deduce the actual metal-stack release from that.
However, it would be very useful for users to have this information such that they can automatically pull and use compatible clients to access the metal-api.
Question is if it does make sense to make the metal-stack version obtainable because operators can theoretically diverge from metal-stack releases with individual components such that there is no guarantee anymore that clients belong together.
Probably relates to metal-stack/metalctl#5.
The text was updated successfully, but these errors were encountered: