ac1584a44f
TLS client verification used to be accidentally disabled in libvirt.
This was fixed in libvirt-6.10.0-1[1].
Which means, once you're using libvirt-6.10.0-1 or higher, a client
certificate is mandatory during live migration with TLS.
In this case, the server certificate generated by TripleO is valid
for client _and_ server:
Key Purpose (not critical):
TLS WWW Server.
TLS WWW Client.
So most deployments can re-use the same certificate for client and
server. Why? Because if both migration ends points are located
on the same infrastructure, it is reasonable to use the same
certificate for both client and server roles.
Introducing QemuDefaultTLSVerify parameter
This parameter will allow operators to enable or disable TLS client
certificate verification. Enabling this option will reject any client
who does not have a certificate signed by the CA in
/etc/pki/qemu/ca-cert.pem.
The default is true and matches libvirt's. We will want to disable this
by default in train.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1879477#c3
Depends-On: https://review.opendev.org/c/openstack/puppet-nova/+/787249
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1945760
Change-Id: I3b252854a0dbf121d69bab79543561da6be781f4
(cherry picked from commit
|
||
|---|---|---|
| ci | ||
| common | ||
| container_config_scripts | ||
| deployed-server | ||
| deployment | ||
| environments | ||
| extraconfig | ||
| firstboot | ||
| network | ||
| plan-samples | ||
| puppet | ||
| releasenotes | ||
| roles | ||
| sample-env-generator | ||
| scripts | ||
| tools | ||
| tripleo_heat_templates | ||
| validation-scripts | ||
| zuul.d | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| LICENSE | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| capabilities-map.yaml | ||
| config-download-software.yaml | ||
| config-download-structured.yaml | ||
| default_passwords.yaml | ||
| j2_excludes.yaml | ||
| net-config-bond.j2.yaml | ||
| net-config-bridge.j2.yaml | ||
| net-config-linux-bridge.j2.yaml | ||
| net-config-noop.j2.yaml | ||
| net-config-standalone.j2.yaml | ||
| net-config-static-bridge-with-external-dhcp.j2.yaml | ||
| net-config-static-bridge.j2.yaml | ||
| net-config-static.j2.yaml | ||
| net-config-undercloud.j2.yaml | ||
| network_data.yaml | ||
| network_data_dashboard.yaml | ||
| network_data_ganesha.yaml | ||
| network_data_routed.yaml | ||
| network_data_subnets_routed.yaml | ||
| network_data_undercloud.yaml | ||
| overcloud-resource-registry-puppet.j2.yaml | ||
| overcloud.j2.yaml | ||
| plan-environment.yaml | ||
| requirements.txt | ||
| roles_data.yaml | ||
| roles_data_undercloud.yaml | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
tripleo-heat-templates
Heat templates to deploy OpenStack using OpenStack.
- Free software: Apache License (2.0)
- Documentation: https://docs.openstack.org/tripleo-docs/latest/
- Source: https://opendev.org/openstack/tripleo-heat-templates
- Bugs: https://bugs.launchpad.net/tripleo
- Release notes: https://docs.openstack.org/releasenotes/tripleo-heat-templates/
Features
The ability to deploy a multi-node, role based OpenStack deployment using OpenStack Heat. Notable features include:
- Choice of deployment/configuration tooling: puppet, (soon) docker
- Role based deployment: roles for the controller, compute, ceph, swift, and cinder storage
- physical network configuration: support for isolated networks, bonding, and standard ctlplane networking
Directories
A description of the directory layout in TripleO Heat Templates.
- environments: contains heat environment files that can be used with -e
on the command like to enable features, etc.
- extraconfig: templates used to enable 'extra' functionality. Includes
functionality for distro specific registration and upgrades.
- firstboot: example first_boot scripts that can be used when initially
creating instances.
- network: heat templates to help create isolated networks and ports
- puppet: templates mostly driven by configuration with puppet. To use these
templates you can use the overcloud-resource-registry-puppet.yaml.
- validation-scripts: validation scripts useful to all deployment
configurations
- roles: example roles that can be used with the tripleoclient to generate
a roles_data.yaml for a deployment See the roles/README.rst for additional details.
Service testing matrix
The configuration for the CI scenarios will be defined in tripleo-heat-templates/ci/ and should be executed according to the following table:
| - | scn000 | scn001 | scn002 | scn003 | scn004 | scn006 | scn007 | scn009 | scn010 | non-ha | ovh-ha |
|---|---|---|---|---|---|---|---|---|---|---|---|
| keystone |
|
|
|
|
|
|
|
|
|
|
|
| glance |
|
swift |
|
|
|
|
|
|
|
||
| cinder |
|
iscsi | |||||||||
| heat |
|
|
|||||||||
| ironic |
|
||||||||||
| mysql |
|
|
|
|
|
|
|
|
|
|
|
| neutron |
|
|
|
|
|
|
|
|
|
||
| neutron-bgpvpn |
|
||||||||||
| ovn |
|
||||||||||
| neutron-l2gw |
|
||||||||||
| om-rpc | rabbit | rabbit |
|
rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | ||
| om-notify | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | ||
| redis |
|
|
|||||||||
| haproxy |
|
|
|
|
|
|
|
|
|
||
| memcached |
|
|
|
|
|
|
|
|
|
||
| pacemaker |
|
|
|
|
|
|
|
|
|
||
| nova |
|
|
|
|
ironic |
|
|
|
|
||
| ntp |
|
|
|
|
|
|
|
|
|
|
|
| snmp |
|
|
|
|
|
|
|
|
|
|
|
| timezone |
|
|
|
|
|
|
|
|
|
|
|
| sahara |
|
||||||||||
| mistral |
|
||||||||||
| swift |
|
||||||||||
| aodh |
|
|
|||||||||
| ceilometer |
|
|
|||||||||
| gnocchi |
|
|
|||||||||
| panko |
|
|
|||||||||
| barbican |
|
||||||||||
| zaqar |
|
||||||||||
| ec2api |
|
||||||||||
| cephrgw |
|
||||||||||
| tacker |
|
||||||||||
| cephmds |
|
||||||||||
| manila |
|
||||||||||
| collectd |
|
||||||||||
| designate |
|
||||||||||
| octavia |
|