rancher / elemental

Elemental is a software stack enabling centralized, full cloud-native OS management with Kubernetes.
https://elemental.docs.rancher.com/
Apache License 2.0
303 stars 39 forks source link

How to handle migration from Micro 5 to Micro 6 ? #1572

Open kkaempf opened 1 month ago

kkaempf commented 1 month ago

When upgrading from Micro 5 to Micro 6, configuration might break due to changes made within Micro. Currently known

We need to take a decision how to handle these changes. We can either adapt configurations (to make the migration transparent) or document the changes (asking users to manually adapt their configs).

emedni commented 1 month ago

Without understanding the full details here, so take this with a pinch of salt - there's usually a couple of different approaches we could take and the team would probably be best placed on the decision based on what you know to be an ideal user experience and how much work this is vs. where this is in the priority lane for us.

So my Q: What would happen if we wrote the docs to document changes and what users need to do; and then waited on adapting the configs >> based on how many hits we get on the docs pages and/or user/clients feedback we could invest in it (do we have stats on docs?).

I.e. is it easier for us to write clear docs or to adapt configs (I don't know how much time-investment either of this is for the team)?

(edit: fixed typos)

ldevulder commented 1 month ago

I.e. is it easier for us to write clear docs or to adapt configs (I don't know how much time-investment either of this is for the team)?

One of the main issue is that some changes are on SLMicro side which is not related to Elemental and changes can happened "anytime" (I mean outside of Elemental development). So at least a link to SLMicro official changes can be added (if such thing exists).

Also a recent version of Elemental operator is able to install OS images based on SLMicro6 (new ones) but also on SLMicro5 (previous stable version) but the config files could be different in that case, so this need to be carefully documented.

So IMHO clear documentation looks "easier" to do.