aboutsummaryrefslogtreecommitdiffstats
path: root/extraconfig/pre_deploy/rhel-registration/scripts
AgeCommit message (Collapse)AuthorFilesLines
2017-04-06Merge "Don't disable satellite repo after registration"Jenkins1-1/+0
2017-03-15Don't disable satellite repo after registrationBen Nemec1-1/+0
Previously the rhel registration script disabled the satellite repo after installing packages from it. This means those packages will never be updated, which is not desirable from a long-term maintenance perspective. I believe this behavior is a holdover from the dib registration script, where we don't want to leave repos enabled because the image may be deployed many times and each instance needs to be re-registered. In t-h-t we don't have that problem because the script only runs at deploy time so it's okay and desirable to leave the repos enabled. Change-Id: I5d760467b458d90d74507a55effc49b71d22eaa3 Closes-Bug: 1673116
2017-03-14Fixes multiple issues with retry function in rhel-registration.Vincent S. Cojot1-17/+31
There were multiple issues in retry() in rhel-registration: - There was no need for it to be recursive (local variables got overwritten) - There was no delay between multiple attempts, leading to faster but more frequent failures. - The max number of attempts was set too low for some environements. With this patch, rhel-registration now works more reliably with slow-links for portal registration and does not attempt to DDos the portal or your satellite server. Change-Id: I594d3c94867b45a7a58766dbcc66edead78d6a4e
2017-03-01Merge "Use --disable= in subscription-manager to avoid shell expansion."Jenkins1-1/+1
2017-02-28Use --disable= in subscription-manager to avoid shell expansion.Vincent S. Cojot1-1/+1
In extraconfig/pre_deploy/rhel-registration/scripts/rhel-registration, there's a line that says: retry subscription-manager repos --disable '*' I believe this is broken and will result in shell expansion being made. The proper line should be: retry subscription-manager repos --disable='*' This regression came from commit 2b06ed8adce2bcc18480b71c0f20a0ec2d21de19. (Also see https://review.openstack.org/#/c/381233 ) This patch fixes the regression while preserving functionality of the above change. Closes-Bug: 1667316 Change-Id: I54f0db3f1f596f6356f7445cdc61737f20f14318 Signed-off-by: Vincent S. Cojot <vincent@cojot.name>
2017-02-22Adds http proxy support for registering RHEL overcloud nodesVincent S. Cojot1-0/+80
It is quite common in large entreprises that direct HTTP/HTTPS to the outside world is denied from nodes/systems but reaching out through a proxy is allowed. This change adds support for an HTTP proxy when RHEL overcloud nodes reach out to either the RHSM portal or to a satellite server. This allows the overcloud nodes to download updates even in locked-down environments. The following variables are settable through templates: rhel_reg_http_proxy_host: rhel_reg_http_proxy_port: rhel_reg_http_proxy_username: rhel_reg_http_proxy_password: Note the following restrictions: - If setting rhel_reg_http_proxy_host, then rhel_reg_http_proxy_port cannot be empty. - If setting rhel_reg_http_proxy_port, then rhel_reg_http_proxy_host cannot be empty. - If setting rhel_reg_http_proxy_username, then rhel_reg_http_proxy_password cannot be empty. - If setting rhel_reg_http_proxy_password, then rhel_reg_http_proxy_username cannot be empty. - If setting either rhel_reg_http_proxy_username or rhel_reg_http_proxy_password, then rhel_reg_http_proxy_host AND rhel_reg_http_proxy_port cannot be empty Change-Id: I003ad5449bd99c01376781ec0ce9074eca3e2704
2017-01-10Add retry to RHEL registrationCharles Llewellyn1-13/+30
Occasionally we can see transient network outages when attempting to register with the Redhat Portal or Satellite server. This causes deployment or scaleout operations to fail. These outages are minimal and retrying often resolves the issue. This becomes more prevelant during testing as we deploy infrastructure far more frequently. Change-Id: If23785fbe2eea4643918b2e68915bbc13c1b1112
2016-10-03Disable all repos during rhel registrationBen Nemec1-0/+1
Some accounts get repos automatically enabled when the system is registered, which is a problem because some of these repos pull in things we don't want like early beta versions of software. Since a full list of desired repos is supposed to be included as part of the registration config, let's just disable all repos to start with to ensure we have a clean repo configuration. I'm not sure whether satellite has the same problem (I would think not, since satellite should only be providing the desired repos), so I'm only making this change for portal registration. Change-Id: I052080352e8b1c9b985e42d91a6c42b3258b0b11 Closes-Bug: 1629922
2016-03-29change the default satellite tools rpm repo.Mike Burns1-1/+1
Change-Id: I60ab36b04b8932e4dbee58e21998dc984178b41c Bugzilla: https://bugzilla.redhat.com/1275281
2016-03-23Fix satellite registration for http or httpsJames Slagle1-4/+5
If the satellite registration url was specified with https, the curl command to detect the satellite version would not work as expected since -L was not passed and you get redirected to https when testing the ping api. To additionally handle the case where https is specified, also use curl directly with -k to download the configuration rpm instead of using rpm with a url. Fixes another bug with a missing $ in the reference to the $satellite_version variable. Change-Id: I984fdfc415eeeed4ef29cc8d0812e1b67545d6b1
2016-02-29Add Satellite 5 supportJames Slagle2-7/+36
Add Satellite 5 support to the RHEL registration environment and resources. The registration script is updated to support both satellite versions in place given the similarity of the options for both scenarios. The satellite version is detected based on $REG_SAT_URL, and that determines whether subscription-manager or rhnreg_ks is used. Change-Id: Ic261c8a16a7d6d3978f8bfc6e53f75dbe1b716db
2015-10-01Move RHEL (un)registration to NodeExtraConfigSteven Hardy2-0/+139
Currently, we have a problem because the unregistration happens in the "post deploy" phase, which works fine when the top-level stack is being deleted, but not when the ResourceGroup of servers is being scaled down, because then the normal "post deploy" update ordering is respected and we try to unregister after the corresponding server has been deleted. So, instead, register/unregister each node inside the unit of scale, e.g the role template being scaled down, which is possible via the new NodesExtraConfig interface, which means unregistration will take place at the right time both on stack delete and on scale-down. Change-Id: I8f117a49fd128f268659525dd03ad46ba3daa1bc