search

canonical / charmed-openstack-upgrader

Automatic upgrade tool for Charmed Openstack
Apache License 2.0
3 stars 12 forks source link

Add skip apps command line flag. #522

Closed chanchiwai-ray closed 3 months ago

chanchiwai-ray commented 3 months ago

Add --skip-apps flag to allow COU to skip some applications, likely some auxiliary charms in charmed openstack deployment such as vault. And this feature currently only support vault.

The motivation behind this is that we observe some applications in a charmed openstack deployment can be deviated from the recommended setup and still working fine. Vault is an example: the vault version (1.10.x) is above the recommended version for current openstack version (reference) but still working fine on production. The problem is worsen because users are not recommended to downgrade vault. So we need a workaround for user to skip upgrading some applications that are known to be working and can't afford to switch to recommend version.

Closes: #472

chanchiwai-ray commented 3 months ago

Do you think there is any check required because we provide an option to skip the app. This may cause a risk that user make the cloud not in a consistence application version. For example ovn-central required ovn-chassis to be upgraded first, if you skip ovn-chassis, you will have a chance to upgrade ovn-central first.

That is a valid concern for the future. TBH, the "choices" should be reviewed carefully. Currently, vault should be safe to skip since it's an auxiliary apps, openstack deployment should not strongly depends on vault.

jneo8 commented 3 months ago

I am ok to separate the skip and checks, but can you open an issue to trace it? Also provide some comments to mention it's dangerous.

samuelallan72 commented 3 months ago

@gabrielcocenza

In my opinion the ideal scenario would let use the --force flag to be able to generate the plan,

--force currently only forces upgrade of non-empty hypervisors. This would be changing the semantics a lot.

be able to generate the plan, but not allow to upgrade.

This would not be useful. The use case here is that some clouds may have a much newer version of vault than officially supported. Vault cannot be downgraded, so the only option is to force COU to stop blocking on the unsupported vault version.

My preference would be to either update the version lookup.csv to allow these newer versions, or to have a generic ignore/skip so an operator can force upgrade. I don't think this implementation is ideal, but it is a way to unblock an upcoming upgrade at short notice.

a amazing way to let users shoot in the foot.

There is a fine line between footguns and not getting in the way of experienced users. Clouds that will be used with COU will have oddities and COU must work with them.

gabrielcocenza commented 3 months ago

@chanchiwai-ray Thanks for clarifying.

Please add some more context in the PR description saying that some clouds might have newer versions of vault and that it's not recommended to roll back because as the upstream documentation says:

Simply replacing the newly-installed Vault binary with the previous version will not cleanly downgrade Vault, as upgrades may perform changes to the underlying data structure that make the data incompatible with a downgrade.

And tag that this PR solves #472

I think it's necessary to also include documentation about the --skip-apps on how-to. Do you plan to add it in a different PR?

chanchiwai-ray commented 3 months ago

I think it's necessary to also include documentation about the --skip-apps on how-to. Do you plan to add it in a different PR?

Let's add this to a different PR