* Add a new post install software deployment which runs
a python script to configure the undercloud control
plane network. Replaces section in post shell script.
Change-Id: I1cd594564d1628a6e1fccb9eadf18b716ccc5c72
Stdin does not work for the 'openstack keypair create' command
used in extraconfig/post_deploy/undercloud_post.sh, when installed
via Heat templates.
This ends up with different keys created for underlcoud admin and
the default nova keypair, which is configured by Ironic for
overcloud nodes. So those can not be contacted by undercloud
admin via SSH.
The deployed-server/scripts/enable-ssh-admin.sh fails w/o
that fix and makes not possible to deploy BM/OVB overcloud on top
of UC installed with Heat.
Change-Id: Ifb9c2d5eef731c41999d4ef5daa447edf74fd262
Co-authored-by: Harald Jensas <hjensas@redhat.com>
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
- Replicate what has been done in _post_config_mistral
(instack-undercloud)
- Cleanup cron triggers before cleaning workflows.
- Re-create publish-ui-logs-hourly cron trigger.
- If validations are enabled, execute copy_ssh_key workflow.
Depends-On: I10abed7f1514e9d72d5ebac0c85bad11cdf3210f
Depends-On: I01c4497324b2c8666d9f749147693d580c0a5e20
Change-Id: If641a9f91c85a0dcc5fcd8d89784ff4258123ea7
When upgrading to a containerized undercloud, the stackrc needs to be
overriden so we don't rely on hiera CLI anymore to get the admin
password.
Change-Id: Ie2579bf83d709838557c56d952e61656b84acf31
Expose the configuration of net.ipv4.ip_forward via the kernel service.
Depends-On: I6ea6fb8ed300d284c961e7474ff84d104f326255
Change-Id: I557e4a41c4e5be3a2f50e5d5ddc86e17c1eb44e1
Related-Bug: #1750194
The default control plane subnet name is "ctlplane-subnet", so let's
create the right subnet for the containerized undercloud.
Note: the subnet can't be overriden (yet) but for now we rely on the
default.
Change-Id: I15954bced81ef6c3e1a1f4a73bc989f33d08d6f7
We want to configure a TLS url for the underclouds stackrc
when a user specified or generated TLS certificate is used.
This patch updates the existing check so that
the PublicSSLCertificateAutogenerated paremeter is also used
when deciding if the SSL URL should be enabled.
Change-Id: I7561b5de7749ca57f8ac8056b470228e1026eb31
We weren't creating the default flavors for the undercloud. Do it here!
Co-Authored-By: Martin André <m.andre@redhat.com>
Change-Id: Ic0b00ab42422e8d7f1ddd750d993c7919af0823e
Add a parameter to control the homedir of the
Undercloud user. Useful if you don't want stackrc
and ssh creds in /root/
Change-Id: I2ad703689b600280b2c1ab1752654f2d334cb6db
Co-Authored-By: Ian Main <imain@redhat.com>
Commit 5a400f8011 broke the stackrc for
the containerized undercloud, making all the openstack commands fail
with:
Cannot use v2 authentication with domain scope
This replaces the OS_TENANT_NAME variable with OS_PROJECT_NAME to and
switch to versionless auth_url to use keystone v3 instead.
Change-Id: I869adb75294b38c61e508870a69e1637bb410a94
Closes-Bug: #1719796
This adds some extra parameters that we now set in instack-undercloud's
stackrc. Some of which are required for the latest keystone v3
support.
Change-Id: I7043d105ce8312656cb3f2ef23cfaded62c9cf83
Closes-bug: #1718991
It seems UpdateIdentifier is an overloaded parameter - it is used
both to trigger package updates in the minor update case as well as
to trigger the upgrade steps during a major upgrade. I'm not sure
it's appropriate to change either of the descriptions as a result,
so for the moment that is added to the exclusion list.
Change-Id: Ied36cf259f6a6e5c8cfa7a01722fb7fda6900976
Partial-Bug: 1700664
With the composable undercloud installer, it's possible to disable
services. The extraconfig script assumes both, neutron and nova, are
installed and fails if they aren't.
This patch checks if those services are available before.
Change-Id: Idcc2b9809fcfa92649a0a1f45175ce417dc0e608
Add a new roles data YAML file and environment to help
create the undercloud via t-h-t.
Partially-implements: blueprint heat-undercloud
Change-Id: I36df7fa86c2ff40026d59f02248af529a4a81861
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 user feedback indicates we need better examples showing how
we can run an extraconfig template, e.g on post-deploy so that it
runs every update, regardless of if a change to the config has
occurred. We can leverage DeployIdentifier for this, just like with
the puppet deployments.
This can be tested with an example like this:
resource_registry:
OS::TripleO::NodeExtraConfigPost: tripleo-heat-templates/extraconfig/post_deploy/example_run_on_update.yaml
Change-Id: I45d8f8093ab45c03238ec56651c437128661cb95
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
In the case of using portal registration with an
activation key, the RHEL registration script is still
executing a `subscription-manager attach` command. This
should not happen if an activation key is provided. This
is because an activation key already provides the
subscriptions to attach.
Change-Id: I2907bede28a9b7bef71cedeea69c876eb4949df0
The recently added cinder-netapp extraconfig contains some additional
hieradata which needs to be applied during the initial pre-deployment
phase, e.g in controller-puppet.yaml (before the manifests are applied)
so wire in a new OS::TripleO::ControllerExtraConfigPre provider resource
which allows passing in a nested stack (empty by default) which contains
any required "pre deployment" extraconfig, such as applying this hieradata.
Some changes were required to the cinder-netapp extraconfig and environment
such that now the hieradata is actually applied, and the parameter_defaults
specified will be correctly mapped into the StructuredDeployment.
Change-Id: I8838a71db9447466cc84283b0b257bdb70353ffd
Currently we've got a mix of SoftwareConfig resource with
StructuredDeployments resources - while this will work it's
inconsistent and normally using the corresponding
SoftwareDeployments resouce is encourgaged instead.
Change-Id: I308d62d4ff491c073e3e8650fd4c2c65bf96d14a
Adds a potential usage of the post-deploy hooks to register a server
with RHN or a satellite.
Note this requires some additional parameters, which can be specified in
environment_rhel_reg.yaml, and this must be passed into the call to heat
via another -e parameter. An alternative may be to have a global
extraconfig_env.yaml at the top level, which the scripts always pass, or
to use the global environment (/etc/heat/environment.d/default.yaml) on
the seed.
Co-Authored-By: James Slagle <jslagle@redhat.com>
Change-Id: Ia6fd270122cbc2e51beb672654e5e1ebd3bd2966
Adds optional hooks which can run operator defined additional config on
nodes after the application deployment has completed.
Change-Id: I3f99e648efad82ce2cd51e2d5168c716f0cee8fe