Adds rabbitmq_server_additional_erl_args variable which
is appended to RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS
environment variable to RabbitMQ server startup script.

This can be used to configure the schedulers.

Docs attached.

Change-Id: Id683c8cc6dac61354ffd94f3b460335b42136ba2
Co-authored-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Related-bug: #1846467

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>

Depends-On: I75e00312b36e1678b90a42cf58d24652323eff27
Change-Id: Ia716fabffca41eff816e59bbf9f4cab79ee8b72f

In order to migrate to the latest release of rabbitmq (3.7), we need to
first remove this deprecated plugin which is no longer supported (the
problems it solved are now addressed in rabbitmq itself).

This avoids a circular dependency in CI where the new images depend on
the new clustering and the new clustering depends on the new images.

Change-Id: I921459f3e40b9e0d4af9497384e49aabf0abe79b

When a RabbitMQ node in multiple RabbitMQ nodes is started during
multinode deployment, it is required to communicate with each other
to be clustered. However, RabbitMQ nodes cannot communicate between
them due to missing host name in the nodename environment variable
of RabbitMQ. Subsequently, all of RabbitMQs cannot be started and
it will give rise to a deployment failure.

Change-Id: I7b4ba76807750db4a14d859454ba650bdaaf23ca
Signed-off-by: Taeha Kim <kthguru@gmail.com>

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

Certain services such as Murano and trove require access to a rabbitmq
instance from tenant networks. [0]

Exposing the internal rabbitmq to end users is a security hole, hence
there are two options, 1) use vhosts in the existing rabbitmq, or two a
separate rabbitmq instances. Given the importance of rabbitmq to the
OpenStack deployment, we have decided to go with a separate instance.
Refer to [1] for more detail on the various options.

This change makes the rabbitmq role generic so that it can be reused, in
this case to start 'outward_rabbitmq'. It needs to be exposed via
haproxy both for network isolation and also because this is what Murano
configuration requires.

Follow on patches will be added to add a vhost in this outward instance
for Murano and other services which require access.

Based on the original work by bdaca[2]

[0] http://murano.readthedocs.io/en/stable-liberty/intro/architecture.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109091.html
[2] https://review.openstack.org/#/c/374525



Change-Id: Ib2bcc7ed4bf4f883a7cd1dfad3db89201e3cfd8d
Partial-Bug: #1620374
Depends-On: I020eb6219f89a310451becde41f6f1c7f54baadd
Co-Authored-By: Bartłomiej Daca <bartek.daca@gmail.com>

This issue still exsits when disable ipv6 feature.

This reverts commit 5480bd9b.

Change-Id: I1e6c6bff5585cf5a49890668203d6971112c32f1

Closes-Bug: #1562701
Change-Id: Ica68bdee81223232995bc21ad5e5d5fbf9e8b05f

Thgis PS add missing check for Kubernetes orchestration engine,
without these changes, running kolla-ansible genconfig fails
for Kubernetes environment.

TrivialFix

Change-Id: I25eeb7ae3ddba7c924f6d48aa24afdbe74227170

enable_rabbitmq_cluster is now a "yes" by default but you can set it
to "no" if you want to disable clustering under any circumstances.

The agreement made at OpenStack in Austin was that Kolla-Kubernetes
would concentrate on RabbitMQ and MariaDB without clustering but
with persistent storage and workload migration, then examine how to
do proper distributed functionality as the project progresses, so I
am just following what we'd already agreed upon.

First, it helps us deal with issues of version upgrades without
dealing with clustered version upgrades and the synchronization
thereof.

Second, it provides an alternative model for durability when used in
Kubernetes.  Understand that, if we disable RabbitMQ's clustering,
Kubernetes is still able to re-schedule the queue off of a failed node
in ways that Kolla-Ansible is not.  There are known issues with
RabbitMQ clustering, especially with auto-heal turned on.  For many
small-to-mid-sized clusters, it's going to provide for a better
operator experience to have the known potential for a 30 second blip
after RabbitMQ node failure than it is to have the known potential
for partition and data loss and/or manual operations after you've
turned off auto-heal.

Kolla-kubernetes has already turned off host networking for the
RabbitMQ pod; it's safe to set the interface address in the
Kubernetes context.

The question was asked why don't I just set the RabbitMQ cluster to be
a single instance.  It's unlikely that Kubernetes RabbitMQ with a
PetSet will be clustered in the same declaritive fashion as the
rabbitmq-clusterer plugin. Easier to just disable it and worry about
how to configure the kube-friendly clustered RabbitMQ at a later point
in time.  Furthermore, it's an entirely valid case for many OpenStack
control planes hosted atop Kolla-Kubernetes to accept the possibility
of a 30-60 second blip in lieu of the long and questionable history
of RabbitMQ clustering in production.

Co-authored-by: Ryan Hallisey <rhallise@redhat.com>
Change-Id: I7f0cb22d29a418fce4af8d69f63739859173d746
Partially-implements: blueprint api-interface-bind-address-override

The comment was confusing and not explaining what the real issue is
when binding erlang to an IPv4 address.

Change-Id: I819ea137fa37c0b2711efb1e7cb1e518ae26b9ab
Related-Bug: #1562701

Please refer to the Closes-Bug identifier for detailed information
pertaining to this issue.

Closes-Bug: #1562701

Change-Id: I77563930e14e11ea48e7edfef0bff80002279381

The rabbitmq-server package is upgraded to 3.5.7 in cloud-archive
so we update centos to match

The xen-utils package now needs an explict version, xen-utils-4.6 is
what is provided by cloud-archive mitaka

Libvirt 1.3 is in the ubuntu cloud-archive. This has a new daemon for
logging that needs further implementation in newton. For now, it has
been disabled within the qemu.conf

Co-Authored-By: Jeffrey Zhang <jeffrey.zhang@99cloud.net>
TrivialFix
Change-Id: I84217824817c484b6800a64cbd7767b127a3098e

Partially implements: blueprint heka
Change-Id: I8fd3324daf15e52712591c2b3cbec613d82b73b3

Change-Id: I2a9c6fa16444a2142ab77f58d188eda84a2e59fd
Partially-Implements: blueprint rabbitmq-clusterer

In rabbitmq we removed the requirement for hostname since that is
already installed.

Change-Id: Ia2355e332d53763db630d19663c2ddc8bf3aa425
Paritially-Implements: blueprint install-from-ubuntu

Cleanup all options in the rabbitmq confs. Allow all ports to be
configurable.

Change-Id: I9b3b485a4f3a25d20c0f19d13638f717daa169dc
Partially-Implements: blueprint update-configs

The original purpose for having an abstract like 'database' rather than
the service name of 'mariadb' has been change. Our direction is different
and this patch reflects consistent naming throughout

Change-Id: I704896191cc5243f9dab2a4cca9120e9dc2ceb2c
Closes-Bug: #1478328

This binds rabbitmq, epmd, and the management plugin to a single ip. The
syntax is very tricky, but this is all functional.

Change-Id: Iecbb00f6c4fe3044688ae3258da31b9aabbd1501
Closes-Bug: #1478073

Adds initial support for Rabbitmq in Ansible using the CONFIG_EXTERNAL methods.

Additionally, this refactors some of the Rabbitmq config script to allow for
reuse by CONFIG_EXTERNAL.

Partially Implements: blueprint ansible-service

Change-Id: I1765548f7e4f1258eb8a49e2a23242955f52655d