Commit Graph

28 Commits

Author SHA1 Message Date
Radosław Piliszek
bc053c09c1 Implement IPv6 support in the control plane
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>
2019-10-16 10:24:35 +02:00
Rafael Weingärtner
22a6223b1b Standardize the configuration of "oslo_messaging" section
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=1478274
https://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>
2019-08-15 13:18:16 -03:00
Pierre Riteau
abf10736c7 Remove unused [service_credentials] config sections
Several services inherited [service_credentials] config sections which
they don't use in their code.

Change-Id: Iccf4358e85fb3d7ed25bc1762ff532b2c32bea4a
2019-05-31 13:25:00 +01:00
Jim Rollenhagen
2e4e60503a Use keystone_*_url var in all configs
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
2019-03-06 15:08:26 -05:00
Nicolas Haller
4812d4a7a1 Fix section trustee of sahara.conf
Tested on Rocky, /v3 needs to be added to the variable auth_url to have
the trust/trustee mechanism to work. All cluster creation would fail
otherwise.

Closes-Bug: #1805896
Change-Id: Ieedac124fa22e5a7ae622c16d47d482007bbec60
2018-11-29 15:08:49 -05:00
Nicolas Haller
b439d48ab3 Fix section keystone_authtoken of sahara.conf
Tested on Rocky, it seems there is no admin_* variables and some others
are missing (username/password/...) causing keystone to return http code
400 responses.

Change-Id: If4a0919bfcd6b8d8a6bfd5df9001b4967e441e7e
Closes-Bug: #1805714
2018-11-28 17:04:39 -05:00
wu.chunyang
3fe57abeb2 fix sahara_api is always restarting
shara_api need auth_url arguments in keystone_authtoken group.
follow the configure document[0], the auth_url should under
trustee group. but the keystone use default "keystone_authtoken "
group to authenticate,if we wanna use trustee group to authenticate,
we need add "auth_section=trustee" under keystone_authtoken group
,when add this , the trustee group also need auth_type which sahara
have not register into oslo_config.when add to register,the username may
hardcode[1],so i think the best way to reslove this problem is to
add auth_url under keystone_authtoken

[0]https://docs.openstack.org/sahara/latest/configuration/descriptionconfig.html
[1]d60a3b152b/sahara/utils/openstack/keystone.py (L41)

Change-Id: I7e94cf56fa38f01e2b3d93303f8192cb66ba76ab
2018-08-10 15:24:55 +00:00
ZhongShengping
ae246945a6 Deprecate auth_uri option
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
2018-08-07 11:58:23 +05:30
wu.chunyang
d59e61a90f update sahara.conf file for kolla
The use of [keystone_authtoken] credentials for trust creation is now
 deprecated. refer to [1][2][3]

[1] d16f07ea3c/releasenotes/notes/trustee-conf-section-5994dcd48a9744d7.yaml
[2] https://docs.openstack.org/sahara/latest/configuration/descriptionconfig.html
[3] d60a3b152b/sahara/utils/openstack/keystone.py (L116)

Change-Id: I75002c6221268a3371585cf270dee18186471ef5
2018-06-08 15:47:20 +00:00
Zuul
08b4930e29 Merge "Homogenize the topics conf variable on templates" 2018-03-13 07:35:49 +00:00
Dai Dang Van
e846d48780 Support policy.yaml file [part 6]
- Sahara
- Searchlight
- Senlin
- Tacker

This will copy only yaml or json policy file if they exist.

Change-Id: I97c8bf300f14ae6d7c55c5f8962c5781cee2c40a
Implements: blueprint support-custom-policy-yaml
Co-authored-By: Duong Ha-Quang <duonghq@vn.fujitsu.com>
2018-01-26 04:37:48 +00:00
Pierre Blanc
b84bee79c3 Homogenize the topics conf variable on templates
In several templates the variable topics is configured
between simple quotes.
It is better to remove them to use the openstack default value.

Change-Id: I418c714240b38b2853a5c746203eac31588e841a
2018-01-12 16:39:47 -05:00
Zuul
9b48099441 Merge "Add support for hybrid messaging backends" 2017-11-28 19:06:49 +00:00
caowei
7ce5c46894 Remove use_neutron from sahara config
Nova network has been fully removed from the OpenStack codebase.
As such, all instances of switches on use_neutron should be removed,
as the functionality will never be meaningful.

Change-Id: I6af9af897b5a4416082307e01dca951c9b7026ad
Depends-On: Ib9d87dd339d637b69fb27315d92228cbc523c8eb
2017-11-24 10:07:26 +08:00
Andrew Smith
fd1d3af0df Add support for hybrid messaging backends
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
2017-11-22 14:09:40 -05:00
Jeffrey Zhang
cacf08f0a6 Remove all kolla-kubernetes configurations
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
2017-07-18 22:00:58 +08:00
Bertrand Lallau
372e991bec Standardize Keystone domain variables
As described here:
https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L841
https://github.com/openstack/keystone/blob/master/keystone/conf/identity.py#L21

* default project domain name MUST be named 'Default'
* default project domain id MUST be named 'default'
* default project user name MUST be named 'Default'
* default project user id MUST be named 'default'

Change-Id: I610a0416647fdea31bb04889364da5395d8c8d74
2017-07-06 14:34:11 +00:00
Bertrand Lallau
afdd11b9a2 Generalize api_interface_address variable usage
Useful api_interface_address variable has been define here:
https://github.com/openstack/kolla-ansible/blob/master/ansible/group_vars/all.yml#L57
In order to simplify codebase we must use it as much as possible.

Change-Id: I18fec19bf69e05a22a4142a9cd1165eccd022455
2017-05-23 08:35:15 +00:00
junbo
0bb72638db Fix saraha-engine authencation issue
Change-Id: Ieb6ad24bf76efaafa0f8e7391ad671ce094a8ece
Closes-Bug: #1687635
2017-05-03 08:20:59 +08:00
Bertrand Lallau
811266b5c5 Sahara: add oslo_messaging_notifications config
Sahara can send RPC notifications to Ceilometer as define here:
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L147

oslo_messaging_notifications section MUST be managed in sahara.conf
file.

Change-Id: Ifdb5c1454a4940d4c1d8b521eb6c91529af142f3
2017-03-14 11:21:00 +01:00
Eduardo Gonzalez
775d8019b6 Add custom policies in service.json
Include custom policy.json files in service-api.json.j2 files

Change-Id: Ic55bfc6f61131aa72c3497ce8b2282056bcc7f92
Partially-Implements: blueprint custom-policies
2016-12-02 16:22:17 +00:00
Martin André
0e6c0abcd1 Fix syntax error in sahara permissions
Key was missing an ending double quote.

Change-Id: Ia11e3f7484c1937cd11a01410dcbee213e994338
Related-Bug: #1631503
2016-10-18 08:26:12 +02:00
zhubingbing
cab32bc727
Fix sahara upgrade permission issue
Change-Id: If7d28829a4c134c655e1b08df1d3ceb7e1989f3c
Partial-Bug: #1631503
2016-10-17 09:26:48 +08:00
Jenkins
6d40d52dcd Merge "Make sahara api worker configurable" 2016-10-10 19:31:09 +00:00
liyingjun
9de0894fbd Make sahara api worker configurable
Sahara api workers is hard-coded to 2 [1], it should be configurable as
other services do.

[1]:
https://github.com/openstack/kolla/blob/master/ansible/roles/sahara/templates/sahara.conf.j2#L9

Change-Id: Iefb487275c4e0d02f58a198e3995ca096f5e9218
Closes-bug: 1631835
2016-10-10 12:06:22 +08:00
liyingjun
d1b95be49a Use rootwrap in sahara config
In cases where a proxy command is being used to access cluster
instances, rootwrap is needed for sahara user in docker container.

http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#non-root-users

TrivialFix

Change-Id: Ic2b7deb6bd0e5f740944c32d89390fb56b88f4fa
2016-10-10 10:53:26 +08:00
liyingjun
e31dede2b0 Fix generated sahara conf
There should be a blank line between 'transport_url' and 'use_neutron = True',
otherwise these line will be merge into one line after rendering.

TrivialFix

Change-Id: I66d14d5bc4b03b450cdcc0f7ac80548ed90bcd2d
2016-09-10 10:12:42 +08:00
zhubingbing
0c9debe893 Add sahara ansible role
Change-Id: I75b58248bfc4e86cace75faa82526d55a9ebbdbf
Partially-Implements: blueprint sahara-role
2016-09-07 15:29:02 +00:00