Replies: 1 comment 1 reply
-
Not sure I'm super fond of this idea. It would require for us to be very sure we always keep that symlink 'correct' at all times. Especially on the second part, the upgrade script which 'magically' picks some version to upgrade to, I believe is dangerous. Better be explicit. It means one has to type a destination version (big deal!), but at least removes a bunch of potential surprises. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
To simplify automation and documentation of projects running on MetalK8s, it could be useful to provide a symbolic link to the mountpoint of the currently "active" version (same version as the
metalk8s.scality.com/cluster-version
annotation on thekube-system
Namespace).Projects could reference scripts using the symlink
/srv/scality/metalk8s
, which would resolve to/srv/scality/metalk8s-{{current_version}}
:Such symlink could also be referenced in our own documentation, if desired. We could even imagine building "shim" scripts which can infer the desired version of a script to use depending on context. Take a
metalk8s-upgrade
shim:destination-version
argument, and try to find the corresponding version in the available mounted ISOsMany things are possible, but a first step to expose the current version would already make things simpler for admins trying to manage Solutions.
Beta Was this translation helpful? Give feedback.
All reactions