Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Starting with Pike, Heat will do attribute resolution in a single pass. A
consequence of this is that when the result of a get_attr is passed to
another get_attr call, there must be a dependency relationship between the
resources so that the inner attribute is resolved first before we try to
determine which attributes are required from the resource in the outer
call.
There are two uses of nested dep_attr in the overcloud template. One (which
hopefully can be removed soon) is in the allNodesConfig resource. In this
case, the {{primary_role_name}}IpListMap already depends on the
ServiceNetMap.
The second is in the KeystoneAdminVip output. This patch makes the VipMap
depend on the ServiceNetMap so that attributes can be resolved in a single
pass in that case.
Change-Id: I438a79748b9b408ec1101271d96c60d84028b57e
|
|
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
|
|
This exposes the nova server IDs for each role, and the bootstrap node
so that we can add this data to the tripleo dynamic ansible inventory
Change-Id: I2fc48eec77210805c0139fa4abcbf4dd721e7c37
|
|
|
|
|
|
|
|
|
|
|
|
Adds in the execution environment of the workflow steps a list of
per-service network IPs. This can be used by the workflows to
execute actions against the nodes hosting a given service.
Change-Id: Id7c735d53f04f6ad848b2f9f1adaa3c84ecd2fcd
Implements: blueprint tripleo-ceph-ansible
|
|
Introduces a general mechanism meant to allow for the execution
of workflows during the deployment steps.
Services can define workflow actions to be triggered during a step
in the newly added service_workflow_tasks section. The syntax is:
service_workflow_tasks:
step2:
- name: my_action_name
action: std.echo
input:
output: 'hello world'
Implements: blueprint tripleo-ceph-ansible
Depends-On: If02799e7457ca017cc119317dfb2db7198a3559f
Depends-On: Ibc5707f9f06266fe84ad1dd91dcb984157871d30
Change-Id: I36a642fbc2076ad9e4a10ffc56d6d16f3ed6f27a
|
|
Add VipMap output to the top level stack output. VipMap is a mapping
from each network to the VIP address on that network. Also includes the
Redis VIP.
This output facilitates deploying split-stack so you can feed the VIP
addresses from VipMap as inputs into the services stack.
implements blueprint split-stack-default
Change-Id: I245920994613c9bd10801c25fa545267aa49b239
|
|
Add 2 new environments to faciltate deploying split-stack:
environments/overcloud-baremetal.j2.yaml
environments/overcloud-services.j2.yaml
The environments are used to deploy 2 separate Heat stacks, one for just
the baremetal+network configuration and one for the service
configuration.
In order to keep Heat's view of the server's hostname consistent across
the 2 stacks the 2 environments set the same HostnameFormat with
"overcloud" as the stack name.
implements blueprint split-stack-default
Change-Id: I0b3f282c08af6fecea8f136908b806db70bada46
|
|
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
|
|
Existing host_config_and_reboot.role.j2.yaml is done in ocata to
configure kernel args. This can be enhanced with use of role-specific
parameters, which is done in the current patch. The earlier method is
deprecated and will be removed in Q releae.
Implements: blueprint ovs-2-6-dpdk
Change-Id: Ib864f065527167a49a0f60812d7ad4ad12c836d1
|
|
Adds the ability to blacklist servers from all SoftwareDeployment
resources. The servers are specified in a new list parameter,
DeploymentServerBlacklist by the Heat assigned name
(overcloud-compute-0, etc).
implements blueprint disable-deployments
Change-Id: I46941e54a476c7cc8645cd1aff391c9c6c5434de
|
|
|
|
|
|
This exposes a list of hostnames similar to the RoleNetIpMap, this
will be consumed by the dynamic inventory ref
https://review.openstack.org/465558
Change-Id: I61efac5634e9b6fbb820e693c71a0adae5fa8b6a
|
|
Master is now the development branch for pike
changing the release alias name.
Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
|
|
Looking up role_data is very slow, particularly when referencing the
RoleData output, as it re-resolves every output for all the (many) nested
stacks in the *ResourceChain resources.
There is work ongoing to optimize this in heat, but this approach improves
performance considerably (my local output-show for RoleData is 10x faster)
so we can consider including RoleData in the tripleo dynamic ansible inventory,
which may be needed for validations and minor updates in future.
Change-Id: I5e6665703e859dc1ec6b60dece70f858c9afaf66
|
|
When a service is enabled on multiple roles, the parameters for the
service will be global. This change enables an option to provide
role specific parameter to services and other templates.
Two new parameters - RoleName and RoleParameters, are added to the
service template. RoleName provides the role name of on which the
current instance of the service is being applied on. RoleParameters
provides the list of parameters which are configured specific to the
role in the environment file, like below:
parameters_default:
# Default value for applied to all roles
NovaReservedHostMemory: 2048
ComputeDpdkParameters:
# Applied only to ComputeDpdk role
NovaReservedHostMemory: 4096
In above sample, the cluster contains 2 roles - Compute, ComputeDpdk.
The values of ComputeDpdkParameters will be passed on to the templates
as RoleParameters while creating the stack for ComputeDpdk role. The
parameter which supports role specific configuration, should find the
parameter first in in the RoleParameters list, if not found, then the
default (for all roles) should be used.
Implements: blueprint tripleo-derive-parameters
Change-Id: I72376a803ec6b2ed93903cc0c95a6ffce718b6dc
|
|
When implementing custom roles, we lost an implicit dependency that
ensured AllNodesExtraConfig is applied before AllNodesDeploySteps,
which causes problems if you need to write hieradata via the
AllNodesExtraConfig hook (some cisco integrations we have in tree
do this, and are now broken because the ordering is no longer ensured.
Change-Id: Ie78ecbb4e135ab7f196867ef9d8d271049a9cd10
Closes-Bug: #1687597
|
|
|
|
|
|
|
|
Fetch the host public keys from each node, combine them all and write to the
system-wide ssh known hosts. The alternative of disabling host key
verification is vulnerable to a MITM attack.
Change-Id: Ib572b5910720b1991812256e68c975f7fbe2239c
|
|
Prior to Ocata, the Controller role was hardcoded for various lookups.
When we switched to having the primary role name being dynamically
pulled from the roles_data.yaml using the first role as the primary
role as part of I36df7fa86c2ff40026d59f02248af529a4a81861, it
introduced a regression for folks who had previously been using
a custom roles file without the Controller being listed first.
Instead of relying on the position of the role in the roles data, this
change adds the concepts of tags to the role data that can be used when
looking for specific functionality within the deployment process. If
no roles are specified with this the tags indicating a 'primary'
'controller', it will fall back to using the first role listed in the
roles data as the primary role.
Change-Id: Id3377e7d7dcc88ba9a61ca9ef1fb669949714f65
Closes-Bug: #1677374
|
|
To enable easier detection of the IPs associated with nodes (such
as to enable the tripleo-validations ansible inventory to work with
custom roles more easily) expose the data we already have about the
nodes/roles and the list of IPs for each network.
Change-Id: I5667a142f47fbff120c703bedadd8b6e163c9480
|
|
This change adds two files which demonstrate manipulation of the
VIP IP addresses without using an external load balancer. This
allows the configuration of DNS, or allows for continuity when
replacing an existing environment.
The fixed IPs for the virtual IPs are set using the new parameters,
and this change also adds a RedisVirtualFixedIPs parameter for
setting the Redis VIP.
Partial-Bug: https://bugs.launchpad.net/tripleo/+bug/1604946
Change-Id: I4e926f1c6b30d4009d24a307bc21e07e1731b387
|
|
|
|
|
|
This patch again removes hard coded role references to
the overcloud.yaml template that was added in
fd15a091f7ab6927833275df17b96ecacc2b1827. This
breaks the composable undercloud work (undercloud-containers ci job as
well).
Change-Id: Ie30b2573dc4d2b45ebc0afc0e0d73bfdf41e4d4b
Closes-bug: #1676528
|
|
In HA deployment mode, we've got some trailing '\n' generated at the beginning
of each controller role nodes line in the undercloud /etc/hosts [1].
[1] - http://paste.openstack.org/show/603721/
Closes-Bug: #1674697
Change-Id: Ic38bc2a5df79dadf72025f207e91a38cc0ab0a92
Signed-off-by: Gael Chamoulaud <gchamoul@redhat.com>
|
|
This uses the heat resource group batched create feature to ensure
we don't create more than 30 nodes at a time, which has been reported
as the maximum supported by the default ironic ipxe/TFTP configuration.
Change-Id: If3651e4c465d8d7bd4c8f2b48d45b1272ff2d272
|
|
When replacing the controller node with resource id 0,
AllNodesValidation will fail because there is an hardcoded reference
to resource.0. With this commit the id for validation is extracted
dynamically with yaql query, picking the first available.
Thanks to Steven Hardy for pointing to the right direction.
Change-Id: I8f2bfacbc005d948bd31ebd51c3d3df3182d5a3c
Closes-Bug: #1673439
|
|
|
|
This patch implements a new docker deployment architecture that
should us to install docker services in a stepwise manner alongside
of baremetal puppet services. This works by using Yaql to select
docker specific services (docker/services/*.yaml) vs the puppet
specific ones and then applying the selected Json to relevant Heat
software deployments for docker and baremetal puppet in a stepwise
fashion.
Additionally the new architecture
leverages new composable services interfaces from Newton to
allow configuration of per-service container configuration
sets (directories that are bind mounted into kolla containers) by
using the Kolla containers themselves. It does this by spinning up
a throw away "configuration only" version of the container being
configured itself, then running the puppet apply in that container and
copying the generated config files into /var/lib/config-data. This
avoids having to install all of the OpenStack dependency packages
in the heat-agent-container itself (our previous approach) and should
allow us to configure a much wider variety of container config files
that would otherwise be impossible with the previous shared approach.
The new approach (combined) should allow us to configure containers in
both the undercloud and overcloud and incrementally add CI coverage to
services as we containerize them.
Co-Authored-By: Martin André <m.andre@redhat.com>
Co-Authored-By: Ian Main <imain@redhat.com>
Co-Authored-By: Flavio Percoco <flavio@redhat.com>
Change-Id: Ibcff99f03e6751fbf3197adefd5d344178b71fc2
|
|
This delivers a /root/tripleo_upgrade_node.sh to those nodes
that have the disable_upgrade_deployment flag set to true.
They will later be upgraded manually by the operator who will
invoke the script delivered here using upgrade-non-controller.sh
We can also deliver any service specific upgrade configuration,
such as configuring nova-compute to use the placement API as this
is required in order for placement to be configured and installed
during the subsequent upgrade steps for controller services.
This removes the compute and swift specific upgrade scripts as
they are now merged into the common
tripleo_upgrade_node.sh - removing any hard coded
reference to a particular role name (compute/objectstorage) and
only relying on the disable_upgrade_deployment is roles_data.yaml
Change-Id: I4531a4038b78087ef4a1a62c35f1328822427817
Co-Authored-By: Mathieu Bultel <mbultel@redhat.com>
|
|
As of Ocata, whenever Heat needs to get the value of an output from a
nested Stack it will still load the Stack in memory and re-resolve the
output value. This means that the EndpointMap's endpoint_map output, which
is huge, gets loaded and recalculated whenever showing the EndpointMap or
KeystoneUrl outputs of the main (overcloud) stack. To avoid this, store the
value locally in an OS::Heat::Value resource. This means that the
EndpointMap will only be resolved once, during the stack create/update, and
the outputs can refer to that value.
Change-Id: Ia79eceeea309f5508713a310849f5d366a035430
Depends-On: If0f80cab94c28514d1569b1025362ab9d9d31512
|
|
Where the role has disabled upgrades, we need to skip both the ansible and
puppet steps. To do this we refactor the post.j2.yaml so that it can be
included in the upgrade template with an adjusted list of roles.
Note this requires https://review.openstack.org/#/c/425220/ - this
change will be required for local testing of this patch
(run mistral-db-mange populate after updating tripleo-common
and restart the mistral services, or update your repos and re-run
openstack undercloud install).
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: Ie7d0fa6fef3528bd93e6cde076b964ea8de3185a
|
|
files/partitions
This submission:
- Fix an error in the AllNodesExtraConfig resource.
(Can't merge servers multiple times).
- Add environment files to deploy swap file/partition
without manual edit over the templates.
- If a swap partition is mounted without having it available
the deployment will fail, the fix checks that if the
partition is not created then the deployment continues.
- Removing empty extra lines in swap templates.
- Adjust description and remove unnecessary comments in
swap templates.
Closes-Bug: 1652184
Change-Id: I828bbbbd4c178956aac74af49f80fcd4f62fa16b
|
|
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
|
|
|
|
This enables the deployer to dynamically add nova metadata to the
servers based on the output of service profiles that implement the
metadata_settings key in the role_data output for the profiles.
One can set an implementation via the OS::TripleO::ServerMetadataHook
resource, which currently is set as OS::Heat::None. So, because of
the default implementation, if left untouched it actually does
nothing.
Currently, besides the list, which is metadata_settings, this hook also
takes the name of the node that it's setting the metadata for.
This is useful for nova vendordata plugins that can parse said metadata.
Change-Id: I8a937f711f0b90156fbb6c4632760435ef846474
|
|
In order to call commands that need to be run on a single node, we
create a new per-service variable that will contain the first node of
each role containing the service.
Change-Id: I03e8685f939e8ae1fcd8b16883b559615042505d
Partial-Bug: #1615983
|
|
|
|
For some upgrade scenarios, e.g all-in-one deployments, it may
be possible to run the upgrade steps, then apply puppet in one
stack update, so reverse the order here. For normal deployments
the upgrade steps are mapped to OS::Heat::None so this will have
no effect.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I3c78751349a6ac2bc5dff82f67bffe13750ac21c
|