rtamalin
commented
4 years ago I have kicked off https://ci.suse.de/blue/organizations/jenkins/openstack-ardana-fergal/detail/openstack-ardana-fergal/43/pipeline and https://ci.suse.de/blue/organizations/jenkins/openstack-ardana-fergal/detail/openstack-ardana-fergal/45/pipeline jobs based on the PR#3891 branch, rebased on top of this branch, to validate these changes in a Jenkins run, though I have already tested them manually use the manual mode from the command line.
Recent SOC 9 CLM upgrade testing attempts to upgrade a cloud that had been updated by the SUSE-Cloud/automation update process would fail when the CLM product ardana-upgrade.yml playbook was being run run on the cloud due to detection that CLM packages have bee updated needing ardana-init, config-processor-run.yml and ready-deployment.yml to be run again.
This appears to be due to lingering SLE 12 SP3 and Cloud8 repos still being enabled on the deployer, and containing packages with the same names but higher versions, causing zypper dist-upgrade to retain the Cloud8 versions of such packages. However when the SOC9 ardana-init command, or ardana-upgrade.yml product playbook, is run, then ansible tasks are run that cleanup potential lingering repos, meaning that when the ardana-upgrade.yml subsequently triggers an additional run of zypper dist-upgrade on the deployer node, instead of it being a no-op action, instead it results in a "downgrade" of those packages to the SOC 9 CLM versions, causing the playbook failure due to the detection of updated CLM packages having been installed.
The reason that there were lingering SP3/Cloud8 repos is that the ardana-disable-repos.yml playbook, which is what disables/removes repos that will conflict with the zypper dist-upgrade of the deployer to SP4/Cloud9, is not being setup with the same runtime settings as the deploy or update workflows for these reasons:
The Updates-test repos settings were not being enabled for the disable-repos or upgrade task modes because those states were not being checked for as part of the sles_test_repos_enabled or cloud_test_repos_enabled enablement flag definitions.
The update workflow uploads the update_to_cloudsource specified in the input.yml as the -Updates rather than -Pool repo when we are working with devel & staging repos, thus emulating the repo layout on a real system, so for the ardana-disable-repos.yml run we need to override the cloud_update_repos_enabled enablement flag to true so that the setup_zypper_repos repos knows that it has to disable/remove the Cloud -Updates repo.
These changes permit a SUSE-Cloud/automation based deploy + update + upgrade run to complete successfully without hitting the above issue.