Hide Forgot
Description of problem:The customer has 2 satelite content views, 1 for osp7 and 1 for osp8. Before the upgrade he unregistered the system from the osp7 content view and registered it with osp8. Therefore there were no longer openstack 7.0 repos. However in the /home/stack/templates/environments/major-upgrade-pacemaker-init.yaml it tries to disable the openstack 7.0 repos, so we get: subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms Error: rhel-7-server-optional-beta-rpms is not a valid repository ID. Which causes the upgrade to fail. The workaround is to comment out the lines in the major-upgrade-pacemaker-init.yaml so that we don't run into this. I think the script should be a little more robust to handle such encounters with satellite. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. unregister system from osp7 satellite content view 2. registyer system with osp8 satellite content view 3. run the upgrade 4. the script will fail since the osp7 repo's are not present. Actual results: failure Expected results: success Additional info: Workaround would be to comment out the lines that attempt to disable the 7.0 openstack repos so they don't fail: major-upgrade-pacemaker-init.yaml parameter_defaults: UpgradeLevelNovaCompute: kilo UpgradeInitCommand: | set -e #if subscription-manager status >/dev/null 2<&1; then # subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms --disable=rhel-7-server-openstack-7.0-director-rpms # subscription-manager repos --enable=rhel-7-server-openstack-8-rpms --enable=rhel-7-server-openstack-8-director-rpms #elif rhn-channel -l >/dev/null 2>&1; then # rm -f /etc/sysconfig/rhn/systemid 2>/dev/null # rhnreg_ks --activationkey='_RHEL_REG_ACTIVATION_KEY_' --serverUrl='_RHEL_REG_SAT_URL_/XMLRPC' --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --force #fi resource_registry: OS::TripleO::Tasks::UpdateWorkflow: ../extraconfig/tasks/major_upgrade_pacemaker_init.yaml OS::TripleO::Tasks::PackageUpdate: ../extraconfig/tasks/yum_update_noop.yaml OS::TripleO::ControllerPostDeployment: OS::Heat::None OS::TripleO::ComputePostDeployment: OS::Heat::None OS::TripleO::ObjectStoragePostDeployment: OS::Heat::None OS::TripleO::BlockStoragePostDeployment: OS::Heat::None OS::TripleO::CephStoragePostDeployment: OS::Heat::None Another workaround may be to have osp7 and osp8 repo's in the same content view so there is no need to manually disable the osp7 repos before running the update scripts.
Hi Jaromir, the script is still the same so we may still have the problem with this kind of scenario. Should we make a effort here to support this (in osp8/9/10) ? Regards,
Yes, if we are upgrading while using Satellite, we are relying on repos provided by Satellite. In that case I don't think we should try to remove old repos and add new ones. (only in cases of using Satellite)
Small clarification to the comment above - only if there is another content view. The question is - are we able to find out what contents are available and if they have required repos? Maybe it might be enough just document use cases and to provide a switch in upgrade command to disable this part of code on demand (--no-repo-removal) so that user doesn't need to hack the script manually... Thoughts?
I think this is just a doc bug for changing how repo enablement/updates work. Assuming it hasn't changed in the last couple releases, the UpgradeInitCommand parameter is what does all this work. It has some logic that determines sub-man vs sat5 and does different things based on that. If people need a customized option there, they can override that parameter. Trying to code all of the permutations of sat 5 vs CDN vs sat 6 with 1 content view vs sat 6 with multiple content views vs different activation keys, etc is extremely difficult. In the OSP 10 logic, the only thing I see that might be worth mentioning that should be maintained if the command is overridden is the "yum install rhosp-release". Otherwise, it's just sat5 vs cdn logic.
Hi Dan, Do you need any info from us here?
Hi Dan, looks like we should warn the user that he shouldn't disable repo through the interface as the init script does it. Is that enough to move forward?
I think so.
Actually, just a quick question. The repo change occurs in OSP8, OSP9, and OSP10. For OSP11 and beyond, how is the repo change maintained?
Ah wait, I see. The rhel-registration now does a bulk disable and then re-enables repositories defined via environment file.
This note is now live on OSP8 to 10. Here is the OSP10 version: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/upgrading_red_hat_openstack_platform/chap-upgrading_the_environment#sect-Major-Upgrading_the_Overcloud-Init Sofer, any chance you can have a look at the note and let me know if I need to modify the wording?
Hi Dan, so for the "subscription-manager status" block that fine, but I'm not sure about the "rhn-channel -l" part of the block. In there the user has to provide two parameters : # downstream only rhel_reg_activation_key: type: string description: RHN activation key default: '' rhel_reg_sat_url: type: string description: RHN server URL default: '' and the switch of repo doesn't seem to be automatic. Mike could you confirm/precise that in the rhn-channel part of the Init command we don't need to do anything ?
Hi Sofer, Just in case, I've also mentioned to update those params in the following section: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/upgrading_red_hat_openstack_platform/chap-upgrading_the_environment#sect-Pre-Upgrade_Notes_for_Overcloud I think that should cover all scenarios. What do you think?
He Dan, I'm not enough familiar with this, but It looks good. Thanks,
The rhn-channel stuff is all related only to Satellite 5. I think it looks ok, but better to have QE validate it.
Hi folks, Did QE still need to validate this? If not, I'll close this BZ.
(In reply to Dan Macpherson from comment #22) > Hi folks, > > Did QE still need to validate this? If not, I'll close this BZ. The new rhel_reg_activation_key provides access to the new repos required for upgrade so this looks good to me.
Thanks, Marius! Closing this BZ.