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
{{role.name}}ExtraConfig was previously ignored if the role used
deprecated params in roles_data.yaml. This was due to the usage of
server_resource_name in the ExtraConfig resource, where
service_resource_name also defaulted to
deprecated_service_resource_name. So, the new {{role.name}}ExtraConfig
was never actually used.
Change-Id: I83e57317e2c56260957be90c66290a41a926835a
Closes-Bug: #1758343
Add support for the SshKnownHostsDeployment resources to
config-download. Since the deployment resources relied on Heat outputs,
they were not supported with the default handling from tripleo-common
that relies on the group_vars mechanism.
Instead, this patch refactors the templates to add the known hosts
entries as global_vars to deploy_steps_playbook.yaml, and then includes
the new tripleo-ssh-known-hosts role from tripleo-common to apply the
same configuration that the Heat deployment did.
Since these deployments no longer need to be triggered when including
config-download-environment.yaml, a mapping is added that can be
overridden to OS::Heat::None to disable the deployment resources when
using config-download.
The default behavior when not using config-download remains unchanged.
Closes-Bug: #1746336
Change-Id: Ia334fe6adc9a8ab228f75cb1d0c441c1344e2bd9
Since Pike, minor updates are done via the composable services
framework. The old shell script approach hasn't been used/tested for 2
releases now, and should be dropped.
Also drop the UpdateWorkflow interface. Before we started doing
upgrades via Ansible, we used this pluggable resource interface to
perform oneshot operations like migrations to WSGI or AODH
services. Nowadays this interface is not referenced from anywhere and
we'd probably rather do similar operations via Ansible tasks.
Change-Id: I6c5eafe76eb53bc38d100a9ba132dd8fe6dd2d5f
Since https://review.openstack.org/#/c/514707/ added the net_ip_map
to hieradata, we can look up the per-network bind IPs via hiera
interpolation instead of heat map_replace.
In some cases the ServiceNetMap lookup is used for other things,
but anywhere we make use of the "magic" translation via NetIpMap
is changed the same way.
This will enable more of the configuration data to be exposed per
role vs per node in a future patch (to simplify our ansible
workflow).
Co-authored-by: Bogdan Dobrelya <bdobreli@redhat.com>
Change-Id: Ie3da9fedbfce87e85f74d8780e7ad1ceadda79c8
The roles would get generated with deprecated parameter group, but no
parameter in that group. Heat would then refuse that template.
Change-Id: I526c8177d1a759ae9e48cdb8b94fc2aa7fe3c6fb
Closes-Bug: #1750828
action was specified twice on NetworkDeployment. The first occurrence is
just ignored by Heat, so remove it for clarity.
Change-Id: Iff24a65c09f37f2777787e7436f7902f5e6a122f
Closes-Bug: #1747072
The subnet property is added to puppet/role.role.j2.yaml as
`{{role}}ControlPlaneSubnet`. Roles with a different subnet specified
can be used to deploy a routed network architecture by using one
role per routed network.
When enabling the neutron segments plug-in to support routed-networks
the neutron IPAM code will defer ipallocation unless the port create
request contain enough details. (Ref: LP Bug: #1695740) By adding the
subnet to port create request this change enables tripleo deployment
on an undercloud with Neutron segments plug-in and routed networks.
This depends on a Heat change that improves network logic in server
resource to not replace the current port if new props match what is
on the current interface. Without this adding the subnet property on
update/upgrades would cause a port replacement, which in turn would
cause IPAM info in undercloud neutron to miss-match the deployed
overcloud nodes.
Depends-On: Iab75ec49b962617943017dcaf1b04b89f91a982e
Change-Id: I33804bfd105a13c25d6057e8414e09957939e8af
Implements: blueprint tripleo-routed-networks-deployment
This allows specific roles, e.g ComputeRealTime to specify defaults
where the services are the same as some existing roles but a different
image and/or configuration are needed.
Inspired by discussion of this requirement in:
https://review.openstack.org/#/c/531739/
RoleParametersDefaults is merged with the user provided parameters
with precendence to user parameters, as this is a special parameter,
which contains a map of the actual parameters to be applied to a
role.
Partially Implements: blueprint tripleo-realtime
Change-Id: I6497144340d3b9276e6ed141d3bc655bfbbeb53c
Workflows may need access to the list of blacklisted hostnames so they
can filter on that value. This change adds that input to the workflow
execution environment.
Change-Id: I41de32b324a406633699d17933ae05417b28c57b
Partial-Bug: #1743046
Workflows triggered from deploy-steps.j2 were not honoring the
blacklist, particularly ceph-ansible. This patch starts to address that
issue by passing in a list of blacklisted ip addresses to the workflow
execution environment that the workflow can make use of to filter
against ctlplane_service_ips.
Change-Id: Ic158171c629e82892e480f1e6903a67457f86064
Partial-Bug: #1743046
These were hardcoded, even though the rest of the network-related bits
were already dynamically generated with jinja.
Change-Id: I8b9e36cbc355065a9117b0a5c5b46afd6ee25d58
Closes-Bug: #1732457
We currently do not have a single hiera key that simply
returns the CloudDomain (Domain Suffix) that was configured
during the deployment. As it is a rather useful thing to have
on the overcloud nodes, let's pass it down for all roles.
IHA is at least one user where this information is needed in
hiera.
Change-Id: I7a510e3bbeb367a46bf6ccc565393b1e7a1a1f33
The compute service list is polled until all expected hosts are reported or a
timeout occurs (600s).
Adds a cellv2_discovery flag to puppet services. Used to generate a list of
hosts that should have cellv2 host mappings.
Adds a canonical fqdn and that should match the fqdn reported by a host.
Adds the ability to upload a config script for docker config instead of using
complex bash on-liners.
Closes-bug: 1720821
Change-Id: I33e2f296526c957cb5f96dff19682a4e60c6a0f0
To enable per-node override of bind IPs via the per-role
ExtraConfig paramaters, we need to enable hiera interpolation
that references the keys defined in NetIpMap, so we add them
to the hieradata. To minimise the risk of any conflicts in
keynames it's added near the bottom of the hierarchy, but
I'm not aware of any conflicting names in our templates/modules.
This will allow per-node hieradata override of bind IPs e.g:
parameter_defaults:
ComputeRack1ExtraConfig:
nova::vncproxy::host: "%{hiera('rack1_internal_api')}"
ComputeRack2ExtraConfig:
nova::vncproxy::host: "%{hiera('rack2_internal_api')}"
Closes-Bug: #1726884
Change-Id: Icf7da1d78176c2ee0197ff2459d69d995cbb16ad
The changes in puppet/role.role.j2.yaml should have been made
to overcloud.j2.yaml, because we don't want the hard-coded reference
to the deprecated name in the parent template. Note we need to
pass this value from the parent template so the %index% substitution
works, which is required for predictable placement via *SchedulerHints
Partial-Bug: #1711656
Change-Id: Ided1802daac48d737f53caa7093df814ba101dd0
In case of an OSP upgrade, some of the roles may require
the reconfiguration of network via os-net-config, especially
with roles having DPDK nics. In order to facilitate this
configuration per role, the THT parameter
'NetworkDeploymentActions' is made role specific.
Change-Id: I17a1812cf9e1c60fb893bf36dc99ab3ec5fc7250
Add some special-casing for backwards compatibility, such that the
Compute role can be rendered via j2 for support of composable networks.
Change-Id: Ieee446583f77bb9423609d444c576788cf930121
Partially-Implements: blueprint composable-networks
Add deprecated role-specific parameters to role definition, in
order to special-case some parameters for backwards compatibility,
such that the Controller role can be rendered via j2 for support
of composable networks.
Co-Authored By: Dan Sneddon <dsneddon@redhat.com>
Change-Id: I5983f03ae1b7f0b6add793914540b8ca405f9b2b
Partially-Implements: blueprint composable-networks
This de-couples public TLS from controllers to now run wherever HAProxy
is deployed.
Partially-Implements: blueprint composable-networks
Change-Id: I9e84a25a363899acf103015527787bdd8248949f
The key_name default is ignored because the parameter is used in
some mutually exclusive environments where the default doesn't
need to be the same.
Change-Id: I77c1a1159fae38d03b0e59b80ae6bee491d734d7
Partial-Bug: 1700664
This is currently included in the controller-role template, so we need
to add it to the generic role.role.j2.yaml in order to convert the
controller-role template to be rendered via j2
Change-Id: I01bf01c8a31e4cc26f202dd1774845ec33f50bcd
Partially-Implements: blueprint composable-networks
To enable backwards compatibility with rendering the controler-role
template add this deprecated parameter for all roles - we should
remove this in a future release after the tripleoclient warnings re
deprecated parameters are available.
Change-Id: Icce93a4109191609848ca216c946a32663753b93
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
Add a new output, DeployedServerEnvionmentOutput, that can be used as
the contents of an environment file to input into a services only stack
when using split-stack. The parameter simplifies the manual steps needed
to deploy split-stack.
By default, the resource that generates the output is mapped to
OS::Heat::None.
implements blueprint split-stack-default
Change-Id: I6004cd3f56778f078a69a20e93a0eba0c574b3db
Render all per-network resources and interfaces via j2 to enable
future support for custom networks via network_data.yaml
Note this doesn't enable custom networks for the built-in roles
as we skip j2 rendering for them, this will be resolved by converting
them to use the generic role template instead of the hard-coded
ones listed in the j2_excludes.yaml.
Depends-On: I18fa3829ff38ac200550d8e36bbe334c0005da22
Change-Id: I49565f9389f3ec9aef4861e23a3bed64a85501e6
Partially-Implements: blueprint composable-networks
Currently we only consume the name with a special-case
for the disable constraints boolean, but it will be more
flexible if we consume the whole roles_data mapping for
each role, so that e.g composable networks and other
per-role customizations can be expressed in these
templates
Partially-Implements: blueprint composable-networks
Depends-On: Id1249b78b3dd87e91d572ffa31b7a541f3cde2c7
Change-Id: I355534ec456479944f66106e957404a660d8f2d2
I471037de35e7f349d900462ec3ffb16fe2d6ebd9 accidentally removed the
default from the RoleParameters parameter. This change just puts
it back.
Change-Id: I29b472897e07229715fc2fea3b55e90473eb0069
This change uses the NeutronPhysicalBridge parameter on all roles,
rather than hard-coding the "br-ex" name. Previously, there were
different parameters for controller and compute roles, but since
we use a unified bridge name with OVS, this is unnecessary.
Change-Id: I6d9189404fae67bcc33ddc2ba3ce1b0385dd989d
Closes-bug: 1669130
DPDK has to be enabled on openvswitch on the boot before
configuring the network as when the network uses DPDK ports
OvS should be ready to handle DPDK. Enabled DPDK via
PreNetworkConfig by checking if ServiceNames contains
DPDK service.
Implements: blueprint ovs-2-6-dpdk
Closes-Bug: #1654975
Depends-On: I83a540336c01a696780621fb2b39486a6abf0917
Change-Id: I7af4534d91e67c94ba559b78b9ac6a001e639db3
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
The DeploymentSwiftDataMap parameter is used to set the
deployment_swift_data property on the Server resoures. The parameter is
a map of role names and node indexes to Swift container and object names
to be used for storing deployment data.
The parameter allows for using predefined Swift objects for storing
deployment data instead of container/object names with generated uuid's
from Heat.
implements blueprint split-stack-default
Depends-On: Ia07e9374a4b95bd0e74fc47fb9df4bf6ad096715
Change-Id: I471037de35e7f349d900462ec3ffb16fe2d6ebd9
Adds a new output, ServerOsCollectConfigData, which is the
os-collect-config configuration associated with each server resource.
This can be used to [pre]configure the os-collect-config agents on
deployed-server's.
Having the data available as a stack output is more user friendly than
having to query several nested levels of stack resources, and then
inspect resource metadata.
implements blueprint split-stack-default
Change-Id: Iaf062f1a72e2a9e4d97f84c67f72408a6b5cebfc
Depends-On: I8acfd67cd8138d587cc362184c84a08134bf3157
First, this parameter must match what is configured on the
undercloud, so strengthen that language.
There is also now an undercloud.conf parameter that can be used to
set the requisite options on the undercloud services, so just point
users at that rather than trying to explain how to configure the
services manually (which is error-prone and doesn't survive
undercloud updates).
Change-Id: I002cce176e3430473a29e79efde3464bddb24cc7