aboutsummaryrefslogtreecommitdiffstats
path: root/overcloud.j2.yaml
AgeCommit message (Collapse)AuthorFilesLines
2017-08-11Convert compute-role.yaml to role.role.j2.yamlSteven Hardy1-8/+2
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
2017-08-03Merge "Add environment for setting a custom domain name"Jenkins1-2/+2
2017-08-02Make many networking parameters consistentBen Nemec1-1/+1
These are mostly the low hanging fruit that only required a few minor changes to fix. There are more that require a lot of changes or might be more controversial that will be done later. Change-Id: I55cebc92ef37a3bb167f5fae0debe77339395e62 Partial-Bug: 1700664
2017-07-27Add environment for setting a custom domain nameBen Nemec1-2/+2
Just setting CloudDomain won't make the domains used consistent. There are a number of CloudName parameters that must be set as well. This change adds a sample environment that includes all of those parameters so it is easy to set everything consistently. Also fixes the description of CloudNameCtlplane to reflect the actual use for that parameter. Change-Id: I56d1c1c5619f83c16c4e8350aa84fccc3d748425
2017-07-17Handles {controller,NovaCompute}ExtraConfig deprecation in ovecloud.j2Giulio Fidente1-3/+29
We missed to parse and merge {controller,NovaCompute}ExtraConfig data in change [1]. Also fixes whitespaces handling in docker-steps.j2 and puppet-steps.j2 previously updated by [2]. 1. Id37de5864138edd5476c097a8a1f0763faeaf768 2. I36a642fbc2076ad9e4a10ffc56d6d16f3ed6f27a Change-Id: Ia9983bc991eb79e479855993c1c8819ddfb52e38
2017-07-14Add role_merged_configs into workflow executions environmentxiGiulio Fidente1-23/+61
Merges per-role config settings into merged_config_settings which is wired into the workflow executions environment. Useful to consume role config settings from within a workflow. Change-Id: Id37de5864138edd5476c097a8a1f0763faeaf768
2017-07-14Adds network/cidr mapping into a new service propertyGiulio Fidente1-0/+16
Makes it possible to resolve network subnets within a service template; the data is transported into a new property ServiceData wired into every service which hopefully is generic enough to be extended in the future and transport more data. Data can be consumed in service templates to set config values which need to know what is the subnet where a deamon operates (for example the Ceph Public vs Cluster network). Change-Id: I28e21c46f1ef609517175f7e7ee19e28d1c0cba2
2017-07-13Remove special-case of memcache node ips for ipv6Steven Hardy1-2/+0
This should be handled in puppet-tripleo, as is done for some other services e.g ceph. This has also been identified as a possible performance problem due to the nested get_attr calls. Change-Id: I7e14f0219c28c023c4e8e1d4693f0bfa9674d801 Related-Bug: #1684272 Depends-On: Iccb9089db4b382db3adb9340f18f6d2364ca7f58
2017-07-13Merge "Use ServerOsCollectConfigData value in output"Jenkins1-4/+1
2017-07-13Merge "Add DeployedServerEnvironmentOutput"Jenkins1-0/+37
2017-07-11Add dependency relationship between nested get_attr targetsZane Bitter1-0/+9
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
2017-07-10Use ServerOsCollectConfigData value in outputJames Slagle1-4/+1
Just use the value from the ServerOsCollectConfigData resource in the output instead of recalculating the value for each role via jinja. Change-Id: I4e3bf4f25c9a8f677d5d177eb409594193a86405
2017-07-10Add DeployedServerEnvironmentOutputJames Slagle1-0/+37
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
2017-06-29Add ServerIdMap outputSteven Hardy1-0/+18
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
2017-06-27Merge "Provides a list of per-service ctlplane IPs to the workflows env"Jenkins1-0/+12
2017-06-27Merge "Allows use of Mistral workflows during deployment steps"Jenkins1-0/+1
2017-06-26Merge "Add VipMap output"Jenkins1-0/+6
2017-06-26Merge "Add split-stack environments"Jenkins1-6/+6
2017-06-26Merge "Add os-collect-config data as an output"Jenkins1-0/+15
2017-06-26Provides a list of per-service ctlplane IPs to the workflows envGiulio Fidente1-0/+12
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
2017-06-26Allows use of Mistral workflows during deployment stepsGiulio Fidente1-0/+1
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
2017-06-15Add VipMap outputJames Slagle1-0/+6
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
2017-06-15Add split-stack environmentsJames Slagle1-6/+6
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
2017-06-15Add os-collect-config data as an outputJames Slagle1-0/+15
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
2017-06-15Update CloudDomain descriptionBen Nemec1-2/+2
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
2017-06-13Modify PreNetworkConfig config inline with role-specific parametersSaravanan KR1-0/+1
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
2017-05-31Server blacklist supportJames Slagle1-7/+44
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
2017-05-26Merge "Add RoleNetHostnameMap output"Jenkins1-1/+13
2017-05-26Merge "Store role_data in an OS::Heat::Value resource"Jenkins1-8/+16
2017-05-19Add RoleNetHostnameMap outputSteven Hardy1-1/+13
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
2017-05-19Update the template_version alias for all the templates to pike.Carlos Camacho1-1/+1
Master is now the development branch for pike changing the release alias name. Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
2017-05-17Store role_data in an OS::Heat::Value resourceSteven Hardy1-8/+16
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
2017-05-15Add role specific information to the service templateSaravanan KR1-0/+7
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
2017-05-02Ensure AllNodesExtraConfig runs before AllNodesDeployStepsSteven Hardy1-0/+1
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
2017-04-21Merge "Add environment to preselect only VIP IP addresses"Jenkins1-1/+3
2017-04-18Merge "SSH known_hosts config"Jenkins1-0/+17
2017-04-18Merge "Add RoleNetIpMap output to overcloud.j2.yaml"Jenkins1-0/+6
2017-04-13SSH known_hosts configOliver Walsh1-0/+17
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
2017-04-12Add tags to rolesAlex Schultz1-1/+9
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
2017-04-11Add RoleNetIpMap output to overcloud.j2.yamlSteven Hardy1-0/+6
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
2017-04-07Add environment to preselect only VIP IP addressesDan Sneddon1-1/+3
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
2017-04-03Merge "Remove useless trailing '\n' in /etc/hosts file."Jenkins1-1/+1
2017-03-30Merge "Add NodeCreateBatchSize parameter"Jenkins1-0/+8
2017-03-27Remove 'Controller' role references from overcloud.j2.yamlDan Prince1-6/+6
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
2017-03-22Remove useless trailing '\n' in /etc/hosts file.Gael Chamoulaud1-1/+1
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>
2017-03-17Add NodeCreateBatchSize parameterSteven Hardy1-0/+8
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
2017-03-17Pick dynamically the first node for stack validationLuca Lorenzetto1-6/+18
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
2017-02-27Merge "Don't recalculate EndpointMap to get outputs"Jenkins1-2/+8
2017-02-15docker: new hybrid deployment architecture and configurationDan Prince1-5/+17
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
2017-02-10Delivers upgrade scripts where upgrade steps are disabledmarios1-0/+1
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>