rhel-osp-director: Deploying OSP10 with sat5, the OC nodes aren't registered. Environment: instack-undercloud-5.1.0-4.el7ost.noarch openstack-tripleo-heat-templates-5.1.0-7.el7ost.noarch openstack-puppet-modules-9.3.0-1.el7ost.noarch Steps to reproduce: Deploy overcloud with this command: openstack overcloud deploy --templates --control-scale 3 --compute-scale 2 --neutron-network-type vxlan --neutron-tunnel-types vxlan --ntp-server clock.redhat.com --timeout 90 -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e network-environment.yaml --rhel-reg --reg-method satellite --reg-sat-url <url> --reg-org <id> --reg-activation-key <key> --reg-force --ceph-storage-scale 1 After the deployment completes successfully, login to any OC node and check the available repo: Result: [heat-admin@overcloud-controller-0 ~]$ sudo yum repolist Loaded plugins: product-id, search-disabled-repos, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. repolist: 0 Expected result: List of repos provided by sat5.
can you attach output of: openstack stack resource list -n 5 overcloud
Created attachment 1229187 [details] output from heat resource-list -n5 overcloud
Created attachment 1229188 [details] output from "openstack stack environment show overcloud"
Created attachment 1229202 [details] deployment-show
the environment show indicates that all the rhel_reg_* parameters are empty or their default values. that seems to indicate that the cli did not update the arguments to the plan
Same problem with sat6 deployment.
So, the parameters are being recognized by the cli, but the values aren't properly making it into the mistral environment. Further investigation required.
The issue can be worked around with using env files: Before running the overcloud command: 1. cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration . 2. Edit the hel-registration/environment-rhel-registration.yaml and set the rhel_reg_org, rhel_reg_activation_key, rhel_reg_method, rhel_reg_sat_repo and rhel_reg_sat_url according to your environment. Run the deployment command with -e rhel-registration/rhel-registration-resource-registry.yaml -e rhel-registration/environment-rhel-registration.yaml Checked that it works for both sat6 and sat5 - saw repos on overcloud nodes upon successful deployment.
we need to check if we're relying on having the Satellite parameters to be taken them from the original $DEPLOY command ? or we can use the .yaml file in major-upgrade scenario ? otherwise it could be that major-upgrade osp9 to osp10 with SAT parameters will be blocked according this bug
Reading the code, as OSP9 installation will have registered the parameters, if no change is required for: --reg-method, --reg-org, --reg-force, --reg-sat-url, --reg-activation-key to upgrade to OSP10, then the heat parameters should already be in place and it shouldn't be needed to pass them again. On the other side tarting the upgrade using a template for the reg parameters should be working. This has to be tested. But I don't have any access to any satellite platform. (I don't know how to clear my needinfo, without clearing the other, so I don't clear anything)
Omri, Sofer provided some info, could you verify within QE team?
(In reply to Jaromir Coufal from comment #22) > Omri, Sofer provided some info, could you verify within QE team? I guess we would need someone to run clean deployment of osp9 using SAT5/6 register and then continue to major-upgrade of osp10 , and see what happens . Adding need-Info on Amit - to see who can check this from life-cycle side.
Failed to verify: Environment: python-tripleoclient-5.4.0-3.el7ost.noarch Running the deployment with args fails with: resources[1]: Property error: resources.NodeExtraConfig.properties: Property rhel_reg_auto_attach not assigned
For clarification. What was fixed in the above patch was to remove the default registration environment file. The contents of the environment file were overriding what was being passed on the command line (by design). The client was automatically including that environment file. The fix was to stop that behavior. The result is that the CLI args that exist work again, but they are no longer enough to register a system with RHN/Satellite. Therefore, it is recommended that an operator should use the environment file exclusively, and consider the cli args fully deprecated. This occurred as parameters were added to the RHN/Satellite registration template, and those parameters were not reflected in the cli.
(In reply to Brad P. Crochet from comment #27) > For clarification. What was fixed in the above patch was to remove the > default registration environment file. The contents of the environment file > were overriding what was being passed on the command line (by design). The > client was automatically including that environment file. The fix was to > stop that behavior. The result is that the CLI args that exist work again, > but they are no longer enough to register a system with RHN/Satellite. > Therefore, it is recommended that an operator should use the environment > file exclusively, and consider the cli args fully deprecated. This occurred > as parameters were added to the RHN/Satellite registration template, and > those parameters were not reflected in the cli. Sasha, does this clarification help? Can we switch this back to ON-QA or VER?
Based on comment 27, I would say this should be ON_QA. Verification should be that with a valid environment file, we can register with command line options and that with options just in an environment file, it will work as well. As noted in comment 27, deployment with *just* parameters will not work. That can be tracked in a separate bug if PM deems it worth tracking (otherwise a separate bug for updating docs should be done if not already filed)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2978.html
closed, no need for needinfo.