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
Currently however old version of Flatcar is running, it's always updated to the latest version directly. This requires us to make sure that such an update is feasible, even for ancient versions of Flatcar.
Impact
We may want to implement a feature that requires a migration to happen during an update, which by itself may have some requirements not met by really old versions of Flatcar. Currently such features can't be implemented or need to be implemented in a way that increases maintenance burden.
Ideal future situation
Really old versions are updated eventually to the latest version by doing a series of updates to intermediate versions of Flatcar. This would allow us to implement a feature with a cutoff version, where Flatcar instances with a version lower than the cutoff will need to update to the cutoff version before being updated to the newest one.
Implementation options
This is something to implement on the Nebraska side. Syncing with other Nebraska instances needs to be thought out too.
My first thought was it would be a property of the channel, but no, it should be a property of the package
And for it to work with syncing downstream Nebraska servers, it would have to be an extra Omaha annotation that regular clients ignore.
The text was updated successfully, but these errors were encountered:
@krnowak Maybe instead of building something, adding this to the documentation would suffice? @pothos mentioned this ticket when I reported that I couldn't update. Thinking about it now, I think I hit this before but did not remember yesterday when I opened the ticket.
The work around to set GROUP=lts and to update to the LTS, and then resetting to GROUP=stable worked nicely.
Current situation
Currently however old version of Flatcar is running, it's always updated to the latest version directly. This requires us to make sure that such an update is feasible, even for ancient versions of Flatcar.
Impact
We may want to implement a feature that requires a migration to happen during an update, which by itself may have some requirements not met by really old versions of Flatcar. Currently such features can't be implemented or need to be implemented in a way that increases maintenance burden.
Ideal future situation
Really old versions are updated eventually to the latest version by doing a series of updates to intermediate versions of Flatcar. This would allow us to implement a feature with a cutoff version, where Flatcar instances with a version lower than the cutoff will need to update to the cutoff version before being updated to the newest one.
Implementation options
This is something to implement on the Nebraska side. Syncing with other Nebraska instances needs to be thought out too.
Additional information
Citing @pothos from our matrix channel:
My first thought was it would be a property of the channel, but no, it should be a property of the package
And for it to work with syncing downstream Nebraska servers, it would have to be an extra Omaha annotation that regular clients ignore.
The text was updated successfully, but these errors were encountered: