crudini is not installed by default on Red Hat derivitive OS's, so we
shouldn't rely on it. We probably can't just install it since this
script is the rhel-registration script, so there are likely no repos
enabled when we need it.
Instead just use grep/cut/sed to get the value we need.
Change-Id: I78fce8b6c7f1d3528f9d8c02772f95cb8ad3b3c8
Closes-Bug: #1771830
The new master branch should point now to rocky.
So, HOT templates should specify that they might contain features
for rocky release [1]
Also, this submission updates the yaml validation to use only latest
heat_version alias. There are cases in which we will need to set
the version for specific templates i.e. mixed versions, so there
is added a variable to assign specific templates to specific heat_version
aliases, avoiding the introductions of error by bulk replacing the
the old version in new releases.
[1]: https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#rocky
Change-Id: Ib17526d9cc453516d99d4659ee5fa51a5aa7fb4b
This is potentially confusing now we added RHELRegistrationActions
since it's unused but mentions DeploymentActions.
Change-Id: Ifb335cb8055528fd9b64081b30e987524169dc95
This can be used in the case where e.g a satellite has been added
after the initial deployment to re-register the nodes with the
satellite, even those nodes that already exist.
Change-Id: I944bc4c65b08de1ca08dd91f55764ebfe141dd9c
Similar to I8bd89f2b24bafc6c991382b9eb484cfa9a2f8968,
use yum to check if updates are available during RHEL registration and
run upgrades only when there are some.
Change-Id: I42cd699d21cbec7d754edf1b8d83e75de0f2c7d9
When using RHSM with a proxy, we want to make sure the proxy can be
reached. This patch verify that a tcp socket can be open from the client
to the proxy.
This patch also does a bit of refactoring:
- --retry-delay 10 --max-time 30 is now used in a parameter everytime we
use curl.
- proxy options are now used everytime curl is used, even for detecting
which version of Satellite is running, now we use proxy options.
Co-Authored-By: Vincent S. Cojot <vincent@cojot.name>
Change-Id: I4dcac1528c10f698338383445e27c8a613f9bcd9
Closes-Bug: #1724970
When deploying with RHSM, sat-tools 6.2 will be installed instead of 6.1.
The new version is supported by RHEL 7.4 and provides katello-agent package.
Change-Id: I04a9feab02bf606ad6ca923a17947dcca30258da
Closes-Bug: #1728638
katello-agent is an optional package, we don't want to use retry.
The package is available or not.
Fixing a regression from https://review.openstack.org/#/c/386529
Since we use "| true", we can't really use "retry" here.
Change-Id: Id8cd9ac54e158ee1743b2f72b169b3a066f69168
Closes-Bug: #1728614
For deployments running on RHEL with Satellite 6 (or beyond) with
Capsule (Katello API enabled), the Katello API is available
on 8443 port, so the previous API ping didn't work for this case.
Capsule is now supported since we just check if katello-ca-consumer-latest
rpm is available to tell that Satellite version is 6 or beyond.
Closes-Bug: #1716777
Change-Id: If76763b367917fc15f609ad144679750602826eb
Workaround systems getting registered as "localhost" during
RHEL registration if they don't have a fqdn set by first
rm'ing the /etc/rhsm/facts directory. When the directory does not
exist, the katello-rshm-consumer which runs when installing
the katello-ca-consumer will not set the hostname.override fact to
"localhost".
Change-Id: Ia29aa9c775f715f9745bb7e1e4022cc395a7d092
Partial-Bug: #1711435
Don't unregister systems from the portal/satellite
when deleting from Heat. There are several reasons why
it's compelling to fix this behavior. See
https://bugs.launchpad.net/tripleo/+bug/1710144
for full information. The previous behavior can be triggered
by setting the DeleteOnRHELUnregistration parameter to "true".
Closes-Bug: #1710144
Change-Id: I909a6f7a049dc23fc27f2231a4893d428f06a1f1
There were 2 problems with this condition making the
rhel-registration.yal template broken:
"conditions" should be "condition"
The condition should refer to just a condition name defined in the
"conditions:" section of the template.
Change-Id: I14d5c72cf86423808e81f1d8406098d5fd635e66
Closes-Bug: #1709916
There is a Heat patch posted (via Depends-On) that resolves the issue
that caused this to be reverted. This reverts the revert and we need to
make sure all the upgrades jobs pass before we merge this patch.
This reverts commit 69936229f4def703cd44ab164d8d1989c9fa37cb.
Closes-Bug: #1699463
implements blueprint disable-deployments
Change-Id: Iedf680fddfbfc020d301bec8837a0cb98d481eb5
This reverts commit d6c0979eb3de79b8c3a79ea5798498f0241eb32d.
This seems to be causing issues in Heat in upgrades.
Change-Id: I379fb2133358ba9c3c989c98a2dd399ad064f706
Related-Bug: #1699463
Commit I46941e54a476c7cc8645cd1aff391c9c6c5434de added support for
blacklisting servers from triggered Heat deployments.
This commit adds that functionality to the remaining Deployments in
tripleo-heat-templates for the ExtraConfig interfaces.
Since we can not (should not) change the interface to ExtraConfig, Heat
conditions are used on the actual <role>ExtraConfigPre and
NodeExtraConfig resources instead of using the actions approach on
Deployments.
Change-Id: I38fdb50d1d966a6c3651980c52298317fa3bece4
Adds the ability to perform a yum update after performing the RHEL
registration.
Change-Id: Id84d156cd28413309981d5943242292a3a6fa807
Partial-Bug: #1640894
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
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
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>
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
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
Heat now supports release name aliases, so we can replace
the inconsistent mix of date related versions with one consistent
version that aligns with the supported version of heat for this
t-h-t branch.
This should also help new users who sometimes copy/paste old templates
and discover intrinsic functions in the t-h-t docs don't work because
their template version is too old.
Change-Id: Ib415e7290fea27447460baa280291492df197e54
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
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
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
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
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