Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
On upgrade we map PostDeploySteps to a different implementation
which we missed to update in I36a642fbc2076ad9e4a10ffc56d6d16f3ed6f27a
Change-Id: Ia619ab935c66081769e69c53d1ca41925d86abbb
Closes-Bug: #1700755
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
This was made configurable in a recent commit [1] So this flag makes it
easier for deployers to use that functionality.
[1] Ic68266eaf39d6803f7c3e299095578bbcfd63b88
Change-Id: Iffff20dcda53bc7237586dd240e581bcb0282844
|
|
|
|
|
|
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
|
|
|
|
|
|
Starting with the Ocata release, bare metal nodes are no longer get recognized
by nova automatically. To avoid forcing users into running nova manage command
each time they enroll a node, we will have to allow enable the periodic task
to do so.
Change-Id: I8b0afac54dc9bd51dbe2ae4f237e4de50459be0f
Closes-Bug: #1697724
|
|
In order to deploy OpenDaylight with DPDK we need to copy the DPDK
config for OVS done in the neutron-ovs-dpdk service template, without
enabling OVS agent for compute nodes. To do this correctly, we should
inherit and openvswitch service which is a common place to set OVS
configuration and parameters. Note: vswitch::dpdk config will be called
in prenetwork setup with ovs_dpdk_config.yaml so there is no need to
include that in the step config for neutron-ovs-dpdk-agent service or
opendaylight-ovs-dpdk.
Changes Include:
- Creates a common openvswitch service template, which in the future
will migrate to be its own service.
- Renames and fixes OVS DPDK configuration heat parameters in the
openvswitch template.
- neutron-ovs-dpdk-agent now inherits the common openvswitch template.
- Adds opendaylight-ovs-dpdk template which also inherits common ovs
template.
- Uses OVS DPDK config script to allow configuring OVS DPDK in
prenetwork config (before os-net-config runs). This has an issue
where hieradata is not present yet, so we have to redefine the heat
parameters and pass them via bash. In the future this should be
corrected.
- Adds opendaylight-dpdk environment file used to deploy an ODL + DPDK
deployment.
- Updates neutron-ovs-dpdk environment file.
Closes-Bug: 1656097
Partial-Bug: 1656096
Depends-On: I3227189691df85f265cf84bd4115d8d4c9f979f3
Change-Id: Ie80e38c2a9605d85cdf867a31b6888bfcae69e29
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
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
|
|
|
|
Change-Id: Ifa985f29fbd589f58cb2fc75b5f442f7651fb2bf
Depends-On: I952c86db88dcd611722a3feaea88f618eee17620
|
|
Change-Id: Iccd31c798b91c494b20489d52e289d9a250b929c
|
|
Change-Id: Id7188ee8a4b05f0aa3c76c4da581e8c4f1b85d86
|
|
I'm not sure why this was here, but without a Listen directive in
Apache's ports.conf Horizon is inaccessible. Removing this allows
Horizon to work again.
Change-Id: Ic221e15f188cf50b485e995035cb96f5d5960a72
Closes-Bug: 1696439
|
|
Change-Id: I4d6a8b53bf07892ba4ae2579f192dc21297ad110
Closes-Bug: #1699026
|
|
|
|
|
|
This will add the node's FQDN to the mysql certificate request
besides the VIP's FQDN which we already use. This is needed for
adding TLS to the replication traffic. The CA file was also added
as hieradata, since the path will be needed for the TLS
configuration.
bp tls-via-certmonger
Change-Id: I9252303b92a2805ba83f86a85770db2551a014d3
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
This will set the max_active_keys setting in keystone.conf, and
furtherly we'll read this value from tripleo-common to do purging of
keys if necessary.
bp keystone-fernet-rotation
Change-Id: I9c6b0708c2c03ad9918222599f8b6aad397d8089
|
|
The list that was passed contained repeated services, which was
problematic if we wanted to use this list in puppet. So instead we pass
a list with the unique names.
Change-Id: Ib5eb0c5b59a9a50344d22c258ca461e8f1e52c86
|
|
|
|
The bootstrap_nodeid can have capital letters while the hostname may
not. In puppet we use downcase for this comparison, so let's follow a
similar pattern for scripts from THT.
Change-Id: I8a0bec4a6f3ed0b4f2289cbe7023344fb284edf7
Closes-Bug: #16998201
|
|
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
|
|
|
|
The bug that prevented it from being a comma delimited list was fixed.
Change-Id: Ia5296140763849bdeac481c812f70a42d907c214
|