Currently when deploying with TLS for internal API traffic, Neutron is
not configured to securely communicate with OVSDB. In regular OVS agent
deployments OVS listens on ptcp and accepts any incoming connection. In
ODL deployments OVS is configured to only listen for pssl connections.
To allow Neutron agents to communicate with OVSDB in pssl, Neutron needs
to be configured with SSL key/certificate in order to connect to OVS.
This patch adds key/certificate generation for NeutronBase service to be
consumed by any agent. The only agent required with ODL is DHCP, so
this patch only addresses configuring SSL there. However, a future
patch could enable SSL for default ML2/OVS agent deployments as well by
building off of this change.
Note, by default OVSDB listens on port 6640. This does not work in ODL
deployments when ODL is on the control node because ODL also listens
on port 6640. Therefore from the ODL service, the ovsdb_connection
setting for DHCP agent is modified when ODL is deployed.
Depends-On: I82281eefa1aa81207ccd8ea565cffc6ca0ec48de
Depends-On: I4bbaf00f0776cab0be34d814a541fb2fd1e64326
Closes-Bug: 1746762
Change-Id: I97352027d7f750d0820610fb9e06f82b47e77056
Signed-off-by: Tim Rozet <trozet@redhat.com>
When copying templates or files with the
process-templates.py's shutil, ignore cases when
the source and the destination are same files.
This allows the following scenario:
- Symlink t-h-t from the installed package to a work dir
- Process j2 templates with overwrite in the work dir
Required-by: https://review.openstack.org/#/c/542875
Change-Id: I9a9c32f05fde325709998f4fe8bc7fef6c25b5c5
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
This change introduces some basic repo management for fast-forward
upgrades using the tripleo-repos tool as the default implementation.
The following parameters have been added to the template to allow for
additional implementations to be added.
FastForwardRepoType - Currently defaults to tripleo-repos
FastForwardRepoArgs - Currently defaults to tripleo-repos args for O and P
bp fast-forward-upgrades
Change-Id: I92f6f5015f34e6c5e8ef131f303d9c8144d1c83e
As outlined in the spec, fast-forward upgrades aim to take an
environment from an initial release of N to a release of N>=2, beyond
that of the traditionally supported N+1 upgrade path provided today by
many OpenStack projects.
For TripleO the first phase of this upgrade will be to move the
environment to the release prior to the target release. This will be
achieved by disabling all OpenStack control plane services and then
preforming the minimum number of steps required to upgrade each service
through each release until finally reaching the target release.
This change introduces the framework for this phase of the fast-forward
upgrades by adding playbooks and task files as outputs to RoleConfig.
- fast_forward_upgrade_playbook.yaml
This is the top level play and acts as the outer loop of the process,
iterating through the required releases as set by the
FastForwardUpgradeReleases parameter for the fast-forward section of the
upgrade. This currently defaults to Ocata and Pike for Queens.
Note that this play is run against the overcloud host group and it is
currently assumed that the inventory used to run this play is provided
by the tripleo-ansible-inventory command.
- fast_forward_upgrade_release_tasks.yaml
This output simply imports the top level prep and bootstrap task files.
- fast_forward_upgrade_prep_tasks.yaml
- fast_forward_upgrade_bootstrap_tasks.yaml
These outputs act as the inner loop for the fast-forward upgrade phase,
iterating over step values while importing their associated role tasks.
As prep tasks are carried out first for each release we loop over step
values starting at 0 and ending at the defined
fast_forward_upgrade_prep_steps_max, currently 3.
Following this we then complete the bootstrap tasks for each release,
looping over steps values starting at
fast_forward_upgrade_prep_steps_max + 1 , currently 4 and ending at
fast_forward_upgrade_steps_max,currently 9.
- fast_forward_upgrade_prep_role_tasks.yaml
- fast_forward_upgrade_bootstrap_role_tasks.yaml
These outputs then finally import the fast_forward_upgrade_tasks files
generated by the FastForwardUpgradeTasks YAQL query for each role. For
prep tasks these are always included when on an Ansible host of a given
role. This differs from bootstrap tasks that are only included for the
first host associated with a given role.
This will result in the following order of task imports with their
associated value of release and step:
fast_forward_upgrade_playbook
\_fast_forward_upgrade_release_tasks
\_fast_forward_upgrade_prep_tasks - release=ocata
\_fast_forward_upgrade_prep_role_tasks - release=ocata
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=0
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=0
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=1
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=1
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=2
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=2
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=3
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=3
\_fast_forward_upgrade_bootstrap_tasks - release=ocata
\_fast_forward_upgrade_bootstrap_role_tasks - release=ocata
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=4
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=4
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=5
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=5
\_$roleA/fast_forward_upgrade_tasks - release=ocata, step=N
\_$roleB/fast_forward_upgrade_tasks - release=ocata, step=N
\_fast_forward_upgrade_release_tasks
\_fast_forward_upgrade_prep_tasks - release=pike
\_fast_forward_upgrade_prep_role_tasks - release=pike
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=0
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=0
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=1
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=1
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=2
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=2
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=3
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=3
\_fast_forward_upgrade_bootstrap_tasks - release=pike
\_fast_forward_upgrade_bootstrap_role_tasks - release=pike
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=4
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=4
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=5
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=5
\_$roleA/fast_forward_upgrade_tasks - release=pike, step=N
\_$roleB/fast_forward_upgrade_tasks - release=pike, step=N
bp fast-forward-upgrades
Change-Id: Ie2683fd7b81167abe724a7b9245bf85a0a87ad1d
If we use variables defined in later step in conditional before
checking which step are we on we will fail.
Resolves: rhbz#1535457
Closes-Bug: #1743764
Change-Id: Ic21f6eb5c4101f230fa894cd0829a11e2f0ef39b
Templates processor fails to locate *.j2 files,
when a custom output dir is specified.
Ensure *.j2 templates are on their expected search
paths for upcoming pasring and rendering
Change-Id: Idbc93e27574c66a9a5a73e3fcd7e88647282f201
Closes-bug: #1748425
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
In puppet neutron ovs agent we apply workaround which we forgot
to reuse in the docker service definition.
Resolves: rhbz#1536142
Closes-Bug: #1744126
Change-Id: If3a63cad754a875f56b604033c1aff498243140c
L2GW Neutron driver is only present in neutron-server-opendaylight
image. This service will apply its configuration to that image,
but it should be extensible to other containers such neutron-server
in the future.
Depends-On: I22023a645c4752c6371b5cea5ab69c7503991887
Change-Id: I9c39e9ff2ce2e15d3e383035c8cac7413e9eeb03
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
BGPVPN Neutron driver is only present in neutron-server-opendaylight
image. This service will apply its configuration to that image,
but it should be extensible to other containers such neutron-server
in the future.
Depends-On: I22023a645c4752c6371b5cea5ab69c7503991887
Change-Id: Ie2b958f67859d285b02af5a80b2a14ccaaf9820a
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
rootwrap.conf is not a nova conf file.
Also cleaned up redundant config file args, were the same as the defaults.
Change-Id: I4db5b0c896e7b3ee00c0d97cf07caacb83f04a9c
Related-bug: 1739492
S3 storage driver is a supported option for gnocchi upstream.
The puppet change has been added in this commit
I5a49fa34d344c4464ea883bf96350f00b0a17eac
Change-Id: Ib44278ef87c8c4d1c39a50d24c1f02fe1fe4042e
This config-dir is included in default neutron-server
exec command as explained in the bug
Change-Id: I22023a645c4752c6371b5cea5ab69c7503991887
Closes-Bug: #1748173
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
Certs were being generated for all networks in service net map.
This was failing as we do not generate hieradata for all of these networks.
Switching from yaql to jinga templating to match the logic that
generates the hieradata.
Change-Id: Ic6c25aceb07ea3824a8fb23549bc5d1205e5cefc
Closes-bug: 1748023
Closes-Bug: 1748053
We're deploying containerized OpenShift, which means openshift-ansible
deploys also containerized OVS. When not disabled explicitly, the bare
metal OVS service seemed to persist at least partially, and it likely
caused issues with the containerized OVS, where nodes in `kubectl get
nodes` would go from Ready status to NotReady shortly after the
deployment finished.
Change-Id: I8952198be7f78a699cf363af2e10f26714e94850
Closes-Bug: #1741224
After merging [0], the step for each upgrade_task
is now handled in a 'when' condition. This patch
changes all the 'tags:' in upgrade_tasks to their
corresponding 'when:' statement.
[0] https://review.openstack.org/#/c/510902/
Change-Id: Id740f69db8ea4ba883a90d9f70a705640c3855d4
Precision Time Protocol (PTP) is a protocol used to
synchronize clocks throughout a network. When used
in conjunction with hardware support, PTP is capable
of sub-microsecond accuracy which is far better than
is normally obtainable with NTP.
Change-Id: I98a1833db28944cfd5a89e4f28c192bb9af8ebbb
Depends-On: Idc78df3a90b73be504480bc9d33a3f0041d2d84f