Introduce kolla_address filter.
Introduce put_address_in_context filter.
Add AF config to vars.
Address contexts:
- raw (default): <ADDR>
- memcache: inet6:[<ADDR>]
- url: [<ADDR>]
Other changes:
globals.yml - mention just IP in comment
prechecks/port_checks (api_intf) - kolla_address handles validation
3x interface conditional (swift configs: replication/storage)
2x interface variable definition with hostname
(haproxy listens; api intf)
1x interface variable definition with hostname with bifrost exclusion
(baremetal pre-install /etc/hosts; api intf)
neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network
basic multinode source CI job for IPv6
prechecks for rabbitmq and qdrouterd use proper NSS database now
MariaDB Galera Cluster WSREP SST mariabackup workaround
(socat and IPv6)
Ceph naming workaround in CI
TODO: probably needs documenting
RabbitMQ IPv6-only proto_dist
Ceph ms switch to IPv6 mode
Remove neutron-server ml2_type_vxlan/vxlan_group setting
as it is not used (let's avoid any confusion)
and could break setups without proper multicast routing
if it started working (also IPv4-only)
haproxy upgrade checks for slaves based on ipv6 addresses
TODO:
ovs-dpdk grabs ipv4 network address (w/ prefix len / submask)
not supported, invalid by default because neutron_external has no address
No idea whether ovs-dpdk works at all atm.
ml2 for xenapi
Xen is not supported too well.
This would require working with XenAPI facts.
rp_filter setting
This would require meddling with ip6tables (there is no sysctl param).
By default nothing is dropped.
Unlikely we really need it.
ironic dnsmasq is configured IPv4-only
dnsmasq needs DHCPv6 options and testing in vivo.
KNOWN ISSUES (beyond us):
One cannot use IPv6 address to reference the image for docker like we
currently do, see: https://github.com/moby/moby/issues/39033
(docker_registry; docker API 400 - invalid reference format)
workaround: use hostname/FQDN
RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4.
This is due to old RabbitMQ versions available in images.
IPv4 is preferred by default and may fail in the IPv6-only scenario.
This should be no problem in real life as IPv6-only is indeed IPv6-only.
Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will
no longer be relevant as we supply all the necessary config.
See: https://github.com/rabbitmq/rabbitmq-server/pull/1982
For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed
to work well). Older Ansible versions are known to miss IPv6 addresses
in interface facts. This may affect redeploys, reconfigures and
upgrades which run after VIP address is assigned.
See: https://github.com/ansible/ansible/issues/63227
Bifrost Train does not support IPv6 deployments.
See: https://storyboard.openstack.org/#!/story/2006689
Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c
Implements: blueprint ipv6-control-plane
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
After all of the discussions we had on
"https://review.opendev.org/#/c/670626/2", I studied all projects that
have an "oslo_messaging" section. Afterwards, I applied the same method
that is already used in "oslo_messaging" section in Nova, Cinder, and
others. This guarantees that we have a consistent method to
enable/disable notifications across projects based on components (e.g.
Ceilometer) being enabled or disabled. Here follows the list of
components, and the respective changes I did.
* Aodh:
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.
* Congress:
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.
* Cinder:
It was already properly configured.
* Octavia:
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.
* Heat:
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Ceilometer:
Ceilometer publishes some messages in the rabbitMQ. However, the
default driver is "messagingv2", and not ''(empty) as defined in Oslo;
these configurations are defined in ceilometer/publisher/messaging.py.
Therefore, we do not need to do anything for the
"oslo_messaging_notifications" section in Ceilometer
* Tacker:
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Neutron:
It was already properly configured.
* Nova
It was already properly configured. However, we found another issue
with its configuration. Kolla-ansible does not configure nova
notifications as it should. If 'searchlight' is not installed (enabled)
the 'notification_format' should be 'unversioned'. The default is
'both'; so nova will send a notification to the queue
versioned_notifications; but that queue has no consumer when
'searchlight' is disabled. In our case, the queue got 511k messages.
The huge amount of "stuck" messages made the Rabbitmq cluster
unstable.
https://bugzilla.redhat.com/show_bug.cgi?id=1478274https://bugs.launchpad.net/ceilometer/+bug/1665449
* Nova_hyperv:
I added the same configurations as in Nova project.
* Vitrage
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Searchlight
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.
* Ironic
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.
* Glance
It was already properly configured.
* Trove
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Blazar
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Sahara
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Watcher
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.
* Barbican
I created a mechanism similar to what we have in Cinder, Nova,
and others. I also added a configuration to 'keystone_notifications'
section. Barbican needs its own queue to capture events from Keystone.
Otherwise, it has an impact on Ceilometer and other systems that are
connected to the "notifications" default queue.
* Keystone
Keystone is the system that triggered this work with the discussions
that followed on https://review.opendev.org/#/c/670626/2. After a long
discussion, we agreed to apply the same approach that we have in Nova,
Cinder and other systems in Keystone. That is what we did. Moreover, we
introduce a new topic "barbican_notifications" when barbican is
enabled. We also removed the "variable" enable_cadf_notifications, as
it is obsolete, and the default in Keystone is CADF.
* Mistral:
It was hardcoded "noop" as the driver. However, that does not seem a
good practice. Instead, I applied the same standard of using the driver
and pushing to "notifications" queue if Ceilometer is enabled.
* Cyborg:
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.
* Murano
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Senlin
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Manila
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Zun
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.
* Designate
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
* Magnum
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components
Closes-Bug: #1838985
Change-Id: I88bdb004814f37c81c9a9c4e5e491fac69f6f202
Signed-off-by: Rafael Weingärtner <rafael@apache.org>
Several services inherited [service_credentials] config sections which
they don't use in their code.
Change-Id: Iccf4358e85fb3d7ed25bc1762ff532b2c32bea4a
This allows barbican service endpoints to use custom hostnames, and adds the
following variables:
* barbican_internal_fqdn
* barbican_external_fqdn
These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.
This also adds a barbican_api_listen_port option, which defaults to
barbican_api_port for backward compatibility.
This option allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.
Change-Id: I1807a9c8b64d737d0e278bb3e925fecb4fadfb08
Implements: blueprint service-hostnames
We're duplicating code to build the keystone URLs in nearly every
config, where we've already done it in group_vars. Replace the
redundancy with a variable that does the same thing.
Change-Id: I207d77870e2535c1cdcbc5eaf704f0448ac85a7a
Barbican API uses uWSGI, which by default writes out log files using
0640 permissions and default ownership for the user. This means that the
log file in /var/log/kolla/barbican/barbican-api.log is not readable by
fluentd.
This was tested via the following command on a queens deployment:
$ docker exec -it fluentd bash
find /var/log/kolla/ -type f | while read f; do test -r $f || echo
"Cannot read $f"; done
Cannot read /var/log/kolla/barbican/barbican-api.log
Generally there are a few ways in which access is provided to log file
for fluentd:
1. Set log file ownership to $USER:kolla, permissions to 0640.
2. Set log file ownership to $USER:$USER, permissions to 0644.
3. MariaDB is a special case, and uses 0640 with the fluentd user added
to the mysql group.
Of these, 1. seems the most secure.
This change uses the --logfile-chmod argument to set the log file
permissions to 644, since it does not appear possible to specify a group
to change ownership to using --logfile-chown. We use command line
arguments since putting the option in the config file does not seem to
work. Perhaps it is an ordering issue.
Change-Id: If98ca7cd9630b5622132a00718cb09304b8285b3
Closes-Bug: #1794472
Option auth_uri from group keystone_authtoken is deprecated[1].
Use option www_authenticate_uri from group keystone_authtoken.
[1]https://review.openstack.org/#/c/508522/
Co-Authored-By: confi-surya <singh.surya64mnnit@gmail.com>
Change-Id: Ifd8527d404f1df807ae8196eac2b3849911ddc26
Closes-Bug: #1761907
If SSL is enabled, api of multiple services returns
wrong external URL without https prefix.
Removal of condition for deletion of http header.
Change-Id: I4264e04d0d6b9a3e11ef7dd7add6c5e166cf9fb4
Closes-Bug: #1749155
Closes-Bug: #1717491
- Barbican
- Ceilometer
- Cloudkitty
- Congress
- Designate
This will copy only yaml or json policy file if they exist.
Change-Id: Iaa19f64073d8bdee948bc2de58e095ca72afc092
Implements: blueprint support-custom-policy-yaml
Co-authored-By: Duong Ha-Quang <duonghq@vn.fujitsu.com>
This commit separates the messaging rpc and notify transports in order
to support separate and different oslo.messaging backends
This patch:
* add rpc and notify variables
* update service role conf templates
* add example to globals.yaml
* add release note
Implements: blueprint hybrid-messaging
Change-Id: I34691c2895c8563f1f322f0850ecff98d11b5185
kolla-kubernetes is using its own configuration generation[0], so it is
time for kolla-ansible to remove the related code to simplify the
logical.
[0] https://github.com/openstack/kolla-kubernetes/tree/master/ansible
Change-Id: I7bb0b7fe3b8eea906613e936d5e9d19f4f2e80bb
Implements: blueprint clean-k8s-config
Kolla-ansible actually bring it's own barbican-api-paste.ini file to
enable Keystone authentication, in order to fix this
https://bugs.launchpad.net/kolla/+bug/1625337
auth_token middleware is actually managed by Barbican.
Furthermore barbican-api-paste.ini brings by Kolla-ansible is outdated:
* http_proxy_to_wsgi middleware is missing
Hence this file should not be managed statically by kolla-ansible.
This patch keep custom paste file feature. Just put the file to
/etc/kolla/config/barbican/barbican-api.ini path.
Change-Id: Ia50237f7df7f89526a976575b017145c71b11ec0
Closes-bug: #1695026
When using the simple_crypto plugin, barbican expects the
[simple_crypto_plugin] kek config value to be a base64-encoded 32 byte
value. However, kolla-ansible is providing a standard autogenerated
password.
There are two relevant variables in kolla-ansible -
barbican_crypto_password (a standard password) and barbican_crypto_key
(a HMAC-SHA256 key). There is no use of barbican_crypto_key other than
when it is generated. barbican_crypto_password is used to set the
[simple_crypto_plugin] kek config value but causes an error when the
simple_crypto plugin is used as the value is not in the expected format.
Using barbican_crypto_key instead resolves the error. Clearly there is a
naming issue here and we should be using barbican_crypto_key instead of
barbican_crypto_password.
This change removes the barbican_crypto_password variable and uses
barbican_crypto_key instead.
Change-Id: I63e2b381c260265e5901ee88ca0a649d96952bda
Closes-Bug: #1699014
Related-Bug: #1683216
Co-Authored-By: Stig Telfer <stig@stackhpc.com>
The barbican service should use the external fqdn as value for the
host_href parameter. Typically this is the endpoint that clients
would use to connect to barbican from outside.
Change-Id: I075acb6335354a61f935d57a7b84f0f92978c9bd
Closes-Bug: #1660282
PyMySQL is prefered to PythonMySQL for Sqlalchemy, as it provides
python3 support and is actively maintained, and is therefore the
currently recommended lib for db connections.
* https://wiki.openstack.org/wiki/PyMySQL_evaluation
Kolla currently uses PyMySQL for all connections bar Barbican
(which works fine with PyMySQL): once this commit is merged it will
be possible to remove the PythonMySQL libs, and mysql libs for kolla
images (except kolla-toolbox).
TrivialFix
Change-Id: Id256387134ca551a181c5e49c9b6d63f62b72523
This fixes a race condition when starting barbican processes,
as by default they attempt to manage the db schema on startup.
TrivialFix
Change-Id: Ic168211880709a3279511ce519756e4cbdd57fe8
By default Barbican has not enabled the Keystone authentication:
[pipeline:barbican_api]
pipeline = cors unauthenticated-context apiapp
According to the Barbican install guide[1] this pipeline should be:
pipeline = cors authtoken context apiapp
[1]: http://docs.openstack.org/developer/barbican/setup/keystone.html
Change-Id: I941515a98772a72762b20507e100e7872f3b4ab8
Closes-bug: #1625337
