Commit Graph

6 Commits

Author SHA1 Message Date
Mike Burns
d2566e5b94 change the default satellite tools rpm repo.
Change-Id: I60ab36b04b8932e4dbee58e21998dc984178b41c
Bugzilla:  https://bugzilla.redhat.com/1275281
2016-03-29 12:14:22 -04:00
James Slagle
5117011468 Fix satellite registration for http or https
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-03-23 10:20:16 -04:00
Jenkins
f8e58b6212 Merge "Add Satellite 5 support" 2016-03-03 12:00:31 +00:00
James Slagle
3884694d58 Add Satellite 5 support
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
2016-02-29 14:23:36 -05:00
Steve Baker
1733d74392 Set the name property for all deployment resources
There are two reasons the name property should always be set for deployment
resources:
- The name often shows up in logs, files and API calls, the default
  derived name is long and unhelpful
- Sorting by name determines the merge order of os-apply-config, and the
  execution order of puppet/shell scripts (note this is different to
  resource dependency order) so leaving the default name results in an
  undetermined order which could lead to unpredictable deployment of
  configs

This change simply sets the name to the resource name, but a future change
should prepend each name with a run-parts style 2 digit prefix so that the
order is explicitly stated. Documentation for extraconfig needs to clearly
state what prefix is needed to override which merge/execution order.

For existing overcloud stacks, heat currently replaces deployment resources
when the name changes, so this change
Depends-On: I95037191915ccd32b2efb72203b146897a4edbc9

Change-Id: Ic4bcd56aa65b981275c3d4214588bfc4de63b3b0
2015-12-10 14:48:04 +13:00
Steven Hardy
2793ab34d2 Move RHEL (un)registration to NodeExtraConfig
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
2015-10-01 10:26:16 +01:00