Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide some sort of cloud-config for upgrades #849

Open
davidcassany opened this issue Sep 19, 2024 · 2 comments
Open

Provide some sort of cloud-config for upgrades #849

davidcassany opened this issue Sep 19, 2024 · 2 comments
Labels
kind/enhancement New feature or request

Comments

@davidcassany
Copy link
Contributor

The idea would be having a mechanism to define some cloud-config for the upgrade. This is relevant in cases where the cloud-config initially provided in the MachineRegistration is no longer valid or incomplete after the upgrade. In such cases it would be handy having the availability to apply some additional cloud-config that is honored on next reboot after the upgrade or even applied during the upgrade via upgrade hooks.

Consider something like setting a cloud-config in ManagedOSImage resource that is converted in to a yaml file that gets dropped in node's /oem partition before starting the elemental upgrade call, this way even upgrade hooks could be an option.

@davidcassany davidcassany added the kind/enhancement New feature or request label Sep 19, 2024
@anmazzotti
Copy link
Contributor

anmazzotti commented Sep 23, 2024

I wondered about this use case too, so I'll drop some input.

My understanding was that the new config should not override the existing ones (for example from the registration).
I find this normal as the registration config has probably "static" things configured that you most likely do not want to change, for example users definition. If anyone wants to replace that, I would recommend a machine reset. It's the safest option.

We already have the SeedImage.spec.cloud-config to be included in the system after upgrade too, in order to add new configs.

What I think the request wanted was to execute scripts or apply OS configuration changes during the upgrade process.
My idea was to add something like SeedImage.spec.evaluateCloudConfig, so that a config can be passed to be evaluated during upgrade. If using yip syntax the user can specify the stage, but if using cloud-init syntax then we should convert to either after-upgrade or before-upgrade by default I'd say, there is no "during". I would opt for the latter, or we could make it toggable with an additional field.

Still this enters the configuration changes scenario, so my argument as usual is to use the reset flow instead.

Edit: Nevermind this entire comment. The SeedImage.spec.cloud-config is already ran at image boot, so it does already what I described.

@davidcassany
Copy link
Contributor Author

We already have the SeedImage.spec.cloud-config to be included in the system after upgrade too, in order to add new configs.

Indeed, SeedImage.spec.cloud-config is already executed at boot. However seedImage has nothing to do with upgrades, it is only meaningful for installations and new deployments. The problem is we are missing a way modify configuration as part of an upgrade, which could be also read as apply an upgrade process if you need to modify a configuration for whatever reason.

Also note this feature is also leading us to the need of snapshotting /oem (and probably other persistent areas) somehow (otherwise rolling back is just not really meaningful). Also this is something to consider in order to better align with Micro, their approach is to use persistent overlays that matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

2 participants