This fixes Octavia in scenarios requiring providing
CA cert (self-signed, internally-signed).
Change-Id: I60b7ec85f4fd8bbacf5df0ab7ed9a00658c91871
Closes-Bug: #1872404
When using the split config style, all backends would be empty, which
meant that HAProxy was unable to serve any traffic. This turned out to
be due to a bad default in the split config template.
Closes-Bug: #1872545
Change-Id: I952e526e735e1d31445963f04d41d66bbdbfdee4
Refactor service configuration to use the copy certificates task. This
reduces code duplication and simplifies implementing encrypting backend
HAProxy traffic for individual services.
Change-Id: I0474324b60a5f792ef5210ab336639edf7a8cd9e
etcd via tooz does not support group membership required by
Designate coordination.
The best k-a can do is not to configure etcd in Designate.
Change-Id: I2f64f928e730355142ac369d8868cf9f65ca357e
Closes-bug: #1872205
Related-bug: #1840070
Allow operators to use custom parameters with the ceilometer-upgrade
command. This is quite useful when using the dynamic pollster subsystem;
that sub-system provides flexibility to create and edit pollsters configs,
which affects gnocchi resource-type configurations. However, Ceilometer
uses default and hard-coded resource-type configurations; if one customizes
some of its default resource-types, he/she can get into trouble during
upgrades. Therefore, the only way to work around it is to use the
"--skip-gnocchi-resource-types" flag. This PR introduces a method for
operators to execute such customization, and many others if needed.
Depends-On: https://review.opendev.org/#/c/718190/
Change-Id: I92f0edba92c9e3707d89b3ff4033ac886b29cf6d
Some services look for /etc/timezone on Debian/Ubuntu, so we should
introduce it to the containers.
In addition, added prechecks for /etc/localtime and /etc/timezone.
Closes-Bug: #1821592
Change-Id: I9fef14643d1bcc7eee9547eb87fa1fb436d8a6b3
In kolla ansible we typically configure services to communicate via IP
addresses rather than hostnames. One accidental exception to this was
live migration, which used the hostname of the destination even when
not required (i.e. TLS not being used for libvirt).
To make such hostnames work, k-a adds entries to /etc/hosts in the
bootstrap-servers command. Alternatively users may provide DNS.
One problem with using /etc/hosts is that, if a new compute host is
added to the cloud, or an IP address is changed, that will not be
reflected in the /etc/hosts file of other hosts. This would cause live
migration to the new host from an old host to fail, as the name cannot
be resolved.
The workaround for this was to update the /etc/hosts file (perhaps via
bootstrap-servers) on all hosts after adding new compute hosts. Then the
nova_libvirt container had to be restarted to pick up the change.
Similarly, if user has overridden the migration_interface, the used
hostname could point to a wrong address on which libvirt would not
listen.
This change adds the live_migration_inbound_addr option to nova.conf. If
TLS is not in use for libvirt, this will be set to the IP address of the
host on the migration network. If TLS is enabled for libvirt,
live_migration_inbound_addr will be set to migration_hostname, since
certificates will typically reference the hostname rather than the
host's IP. With libvirt TLS enabled, DNS is recommended to avoid the
/etc/hosts issue which is likely the case in production deployments.
Change-Id: I0201b46a9fbab21433a9f53685131aeb461543a8
Closes-Bug: #1729566
This patch introduces an optional backend encryption for Keystone
service. When used in conjunction with enabling TLS for service API
endpoints, network communcation will be encrypted end to end, from
client through HAProxy to the Keystone service.
Change-Id: I6351147ddaff8b2ae629179a9bc3bae2ebac9519
Partially-Implements: blueprint add-ssl-internal-network
This is a follow up to I001defc75d1f1e6caa9b1e11246abc6ce17c775b. To
maintain previous behaviour, and ensure we catch any host configuration
changes, we should perform host configuration during upgrade.
Change-Id: I79fcbf1efb02b7187406d3c3fccea6f200bcea69
Related-Bug: #1860161
Elasticsearch 6.x dropped support for mapping types[1], which by default
the Kibana index used. This means that when deploying ELK 6.x, the
Kibana index must be migrated to the new schema to preserve dashboards
and visualizations. There is a process defined[2], which involves
creating a new index with the specified schema, then reindexing the old
index's data into the new index, then doing a rename/delete.
This adds support for that workflow via Ansible. It takes place after
the ES container is restarted after an upgrade, so there will be a
(short) period of time where the Kibana index is not migrated. During
this time, Kibana still loads, but presents the user with a status
screen informing that the index needs migration.
[1]:
https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html
[2]: https://www.elastic.co/guide/en/kibana/6.x/migrating-6.0-index.html
Implements: blueprint elasticsearch-kibana-version-upgrade
Depends-On: https://review.opendev.org/709624
Change-Id: I4550629e2113f3da7f1cecfeab0d5fe0d899dae8
This updates the elasticsearch configuration file (and loading
mechanism) for ELK 6.x.
The default location for the configuration for all package
distributions is /etc/elasticsearch[1], so now that is where we
overwrite the elasticsearch.yml.
The path.conf and path.scripts paths are no longer supported and will
raise exceptions if utilized in 6.x.
[1]:
https://www.elastic.co/guide/en/elasticsearch/reference/6.x/settings.html#config-files-location
Implements: blueprint elasticsearch-kibana-version-upgrade
Depends-On: https://review.opendev.org/#/c/647748/
Change-Id: I4f74bfe07d4b7ca18953b11e767cf0bb94dfd67e
manila share container name variable is fixed in some places,
but in the defaults directory, manila share container_name variable
is variable. If the manila share container_name variable is changed
during deployment, it will not be assigned to container name,
but a fixed 'manila_share' name.
Change-Id: Iea23c62518add8d6820b76b16edd3221906b0ffb
The use of default(omit) is for module parameters, not templates. We
define a default value for openstack_cacert, so it should never be
undefined anyway.
Change-Id: Idfa73097ca168c76559dc4f3aa8bb30b7113ab28
Currently there are a few services that perform host configuration
tasks. This is done in config.yml. This means that these changes are
performed during 'kolla-ansible genconfig', when we might expect not to
be making any changes to the remote system.
This change separates out these host configuration tasks into a
config-host.yml file, which is included directly from deploy.yml.
One change in behaviour is that this prevents these tasks from running
during an upgrade or genconfig. This is probably what we want, but we
should be careful when any of these host configuration tasks are
changed, to ensure they are applied during an upgrade if necessary.
Change-Id: I001defc75d1f1e6caa9b1e11246abc6ce17c775b
Closes-Bug: #1860161
In [1] only neutron-openvswitch-agent was fixed and not xenapi.
That merged in Ussuri and went cleanly into Train.
In Stein and Rocky, the backport was not clean and
accidentally fixed xenapi instead of the regular one.
Neither the original bug nor its incomplete fix were released,
except for Rocky. :-(
Hence this patch also removes the confusing reno instead of
adding a new one.
[1] https://review.opendev.org/713129
Change-Id: I331417c8d61ba6f180bcafa943be697418326645
Closes-bug: #1869832
Related-bug: #1867506
Not everyone wants Kafka data stored on a Docker volume. This
change allows a user to flexibly control where the data is stored.
Change-Id: I2ba8c7a85c7bf2564f954a43c6e6dbb3257fe902
keystone and keystone_fernet container name variable is fixed
in some places, but in the defaults directory, keystone
and keystone_fernet container_name variable is variable.
If the keystone and keystone_fernet container_name variable is
changed during deployment, it will not be assigned to keystone
and keystone_fernet, but a fixed 'keystone' and 'keystone_fernet' name.
Change-Id: Ifc8ac69e6abc4586f0e4fd820b9022aea9f76396
kolla-toolbox container name variable is fixed in some places,
but in the defaults directory, kolla-toolbox container_name variable
is variable. If the kolla-toolbox container_name variable is changed
during deployment, it will not be assigned to kolla-toolbox,
but a fixed 'kolla-toolbox' name.
Change-Id: I9579017761ff47477dba597282be9ae6fab4242a
Deploy HAProxy on one or more servers. Add another server to the
inventory in the haproxy group, and run the following:
kolla-ansible prechecks --limit <new host>
The following task will fail:
TASK [haproxy : Checking if kolla_internal_vip_address and
kolla_external_vip_address are not pingable from any node]
This happens because ansible does not execute on hosts where
haproxy/keepalived is running, and therefore does not know that the VIP
should be active.
This change skips VIP prechecks when not all HAProxy hosts are in the
play.
Closes-Bug: #1868986
Change-Id: Ifbc73806b768f76f803ab01c115a9e5c2e2492ac
