Upgrading to 2.7 does not re-enable loop device provisioning #2982

gdemonet · 2020-12-14T13:58:36Z

Component: salt, upgrade

What happened:

When implementing a solution for #2726 in #2936, we failed to account for upgrade scenarios, where existing SparseLoopDevice Volumes already provisioned will not have a proper systemd unit created.
Thus, after upgrade, any such Volume will fail to have its device provisioned on node reboot.

What was expected: Seamless upgrade, loop devices still provisioned on node startup.

Steps to reproduce: From a MetalK8s 2.6 cluster with existing SparseLoopDevice Volumes, upgrade to 2.7 and reboot.

Resolution proposal (optional):

During upgrade, ensure the systemd unit files are created for existing Volumes
During downgrade, remove the unit files (and re-provision the devices using the metalk8s_volumes module)

The text was updated successfully, but these errors were encountered:

This will simplify the introduction of other states depending on `.installed`, into which we move the systemd unit template and cleanup script creation. See: #2982

Since the management of loop devices changed between 2.6 and 2.7 (introduction of systemd units for this purpose), we want to ensure there will not be duplicated devices pointing to the same sparse file. To do this, we introduce a "cleanup" formula, which can operate in two modes, 'upgrade' and 'downgrade' (controlled via pillar). For upgrade, we manage this cleanup in the `deploy_node` orchestrate, during the drain. For downgrade, we cannot change the `deploy_node` orchestrate, so we manually drain and cleanup from the `downgrade` orchestrate. See: #2982

This will ensure all loop devices are managed as expected after an upgrade. Note that this means invalid Volumes which were not prepared yet will break upgrade. Fixes: #2982

Since the management of loop devices changed between 2.6 and 2.7 (introduction of systemd units for this purpose), we want to ensure there will not be duplicated devices pointing to the same sparse file. To do this, we introduce a "cleanup" formula, which can operate in two modes, 'upgrade' and 'downgrade' (controlled via pillar). For upgrade, we manage this cleanup in the `deploy_node` orchestrate, during the drain. For downgrade, we cannot change the `deploy_node` orchestrate, so we manually drain and cleanup from the `downgrade` orchestrate. See: #2982

This will ensure all loop devices are managed as expected after an upgrade. Note that this means invalid Volumes which were not prepared yet will break upgrade. Fixes: #2982

This will simplify the introduction of other states depending on `.installed`, into which we move the systemd unit template and cleanup script creation. See: #2982

Since the management of loop devices changed between 2.6 and 2.7 (introduction of systemd units for this purpose), we want to ensure there will not be duplicated devices pointing to the same sparse file. To do this, we introduce a "cleanup" formula, which can operate in two modes, 'upgrade' and 'downgrade' (controlled via pillar). For upgrade, we manage this cleanup in the `deploy_node` orchestrate, during the drain. For downgrade, we cannot change the `deploy_node` orchestrate, so we manually drain and cleanup from the `downgrade` orchestrate. See: #2982

This will ensure all loop devices are managed as expected after an upgrade. Note that this means invalid Volumes which were not prepared yet will break upgrade. Fixes: #2982

The `volume_utils` module interacts with a C library, and some values are `c_char_p` which translates to bytes in Python 3 (instead of string in Python 2). This change breaks the blkid probe, which in turns makes the `metalk8s_volumes.is_prepared` execution function always return False. Adding `.decode('ascii')` to the relevant places fixes this issue. See: bddea0b See: #2982