Similar to Updating, but more complicated, because we need to bring down all the services to do the upgrade, because the DB may not be compatible between the 2 releases.

It would be desirable to be able to do the upgrade with:

• Minimum service downtime
• Not breaking any ongoing operation
• Minimum human operator interaction

Ideally

• Would take into account that the driver namespace in the configuration has changed
• Would take into account that configuration options may have dissapeared
• Would support rollback on the upgrade
• Would support a parallel test to confirm that the driver at least loads with the old configuration

What are the use cases this RFE is solving?

The manila-operator needs to support moving a deployment from RHOSO 18 to RHOSO 19. This would involve making all the service changes (configuration, database schema/model/data migrations, crontab changes, file changes) necessary for the service to be running with RHOSO 19. This upgrade must be “accessible” - i.e., no resources created via manila must be affected during the upgrade - for example, if a share is mounted on a container in a compute node, it must continue to remain accessible through this upgrade.

High Level view on how the feature works

The main upgrade is driven and orchestrated by the openstack-operator that is able to inject new containers using the OpenstackVersion CR. 

Is this feature driver dependent or driver related?

Are there any known limitations? (e.g multi attach + encryption)

No; unless any feature is deprecated/removed in the OpenStack Manila version we use for RHOSO 19. The operator is backend agnostic.

Is a CLI change required, does the openstack cmd support it?

No impact on the CLI.

Does this RFE impact / need to be included into the control plane podification?

This RFE concerns the manila-operator and is limited to the manila-operator

Does this RFE benefit/impact DCN?

Manila will be supported with DCN at some RHOSO 18 feature pack release. We cannot assess the impact of DCN yet.

Does this RFE benefit/impact shift on stack?

Shift on Stack is a workload on RHOSO. We need to ensure that an upgrade doesn’t disrupt workloads.

Can this feature be turned on or used in an existing environment?

This is an upgrade RFE; so this feature will only apply during upgrade from RHOSO 18 to RHOSO 19

Does this feature affect another DFG or product?

The upgrades DFG currently owns test jobs to test major version upgrades (FFU). We don’t yet know if this will continue with RHOSO 18→19. They may not test every combination; this may need Manila QE to ensure we have testing for drivers we have a potential of risk - “Ceph NFS” and “CephFS Native”

Does this feature depend on another RFE?

We may have an epic for the Podification core team to resolve how the upgrade works with the OpenStack operator. We’ll add a dependency when that RFE exists.

How will the feature affect Upgrades?

This is an upgrades RFE

How will the feature affect performance or scaling?

There should be no impact if the same reasonable maintenance window is preserved for upgrades as it is for minor updates. During this maintenance window, no manila control plane operations are possible. 

What are the test cases for this RFE?

• We need to test for the “accessibility” of the upgrade process - i.e., no workloads are affected when we upgrade.
• We need to test that resources created with manila can be further operated upon after upgrade. For example - create a snapshot, or clone existing snapshot to a share and write some more data into it.

Are there CI implications?

The automated tests must be run in the CI

Does it have documentation impact and require early planning with the doc team?

Yes; usual upgrade documentation - we don’t yet know if there is any breaking change. At the moment, we think the usual cross-DFG coordinated upgrade effort can be used here as well.

Are there known packaging challenges?

No

Are there any security considerations?

No - as long as we ensure we’re not messing with the security of manila resources (access rules) 

How much upstream resistance might there be to this feature?

None

Will this feature require new or different support skills?

Not likely; not different than managing a RHOSO 19 greenfield environment 

Will this be required for knowledge transfer to GSS?

Yes.

Will this feature impact existing partners or certification programs?

Partners are expected to ship new containers if applicable for RHOSO 19; and these container images must be present prior to them certifying on RHOSO 19. The certification tooling is expected to be ready prior to beta as with current RHOSP/RHOSO release timelines. Partners must certify on the platform before their technology is considered “supported”. Partners do not test upgrades.

API Deprecation/Compatibility?

The manila-operator should be able to handle compatibility between RHOSO 18 and RHOSO 19 releases. The goal is to require minimal input from the human operator.

Are any GUI impact/changes required (Horizon)?

No