59a235340c
On the compute nodes, right now ssl certificates got created for libvirt, qemu-default, qemu-vnc and qemu-nbd. This is not required because the all services use the same NovaLibvirtNetwork network and therefore multiple certificates for the same hostname get created. Also from qemu point of view, if default_tls_x509_cert_dir and default_tls_x509_verify parameters get set for all certificates, there is no need to specify any of the other *_tls* config options. From [1] The intention (of libvirt) is that you can just use the default_tls_x509_* config attributes so that you don’t need to set any other *_tls* parameters, unless_ you need different certificates for some services. The rationale for that is that some services (e.g. migration / NBD) are only exposed to internal infrastructure; while some sevices (VNC, Spice) might be exposed publically, so might need different certificates. For OpenStack this does not matter, though, we will stick with the defaults. Therefore with this change InternalTLSNbdCAFile, InternalTLSVncCAFile and InternalTLSQemuCAFile get removed (which defaulted to /etc/ipa/ca.crt anyways) and just use InternalTLSCAFile. Also all cerfificates get created when EnableInternalTLS is true to and mount all SSL certificates from the host. This is to prevent certificate information is not available in a qemu's process container environment if features get switched later, which has shown to be problematic. [1] https://docs.openstack.org/nova/latest/admin/secure-live-migration-with-qemu-native-tls.html Also squashes |
||
---|---|---|
ci | ||
common | ||
container_config_scripts | ||
deployed-server | ||
deployment | ||
doc | ||
environments | ||
extraconfig | ||
firstboot | ||
network | ||
network-data-samples | ||
plan-samples | ||
puppet | ||
releasenotes | ||
roles | ||
sample-env-generator | ||
scripts | ||
tools | ||
tripleo_heat_templates | ||
zuul.d | ||
.ansible-lint | ||
.gitignore | ||
.gitreview | ||
.testr.conf | ||
babel.cfg | ||
bindep.txt | ||
config-download-software.yaml | ||
config-download-structured.yaml | ||
j2_excludes.yaml | ||
LICENSE | ||
network_data_dashboard.yaml | ||
network_data_default.yaml | ||
network_data_ganesha.yaml | ||
network_data_routed.yaml | ||
network_data_subnets_routed.yaml | ||
network_data_undercloud.yaml | ||
network_data.yaml | ||
overcloud-resource-registry-puppet.j2.yaml | ||
overcloud.j2.yaml | ||
README.rst | ||
requirements.txt | ||
roles_data_undercloud.yaml | ||
roles_data.yaml | ||
setup.cfg | ||
setup.py | ||
test-ansible-requirements.txt | ||
test-requirements.txt | ||
tox.ini | ||
vip_data_default.yaml |
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 | scn013 | 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 | rabbit | ||
om-notify | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | rabbit | ||
redis |
|
|
||||||||||
haproxy |
|
|
|
|
|
|
|
|
|
|
||
memcached |
|
|
|
|
|
|
|
|
|
|
||
pacemaker |
|
|
|
|
|
|
|
|
|
|
||
nova |
|
|
|
|
ironic |
|
|
|
|
|
||
placement |
|
|
|
|
|
|
|
|
|
|
||
ntp |
|
|
|
|
|
|
|
|
|
|
|
|
snmp |
|
|
|
|
|
|
|
|
|
|
|
|
timezone |
|
|
|
|
|
|
|
|
|
|
|
|
mistral |
|
|||||||||||
swift |
|
|||||||||||
aodh |
|
|
||||||||||
ceilometer |
|
|
||||||||||
gnocchi |
|
|
||||||||||
barbican |
|
|||||||||||
zaqar |
|
|||||||||||
cephrgw |
|
|||||||||||
cephmds |
|
|||||||||||
manila |
|
|||||||||||
collectd |
|
|||||||||||
designate |
|
|||||||||||
octavia |
|
|
||||||||||
rear |
|
|||||||||||
Extra Firewall |
|