octavia.conf is missing configuration values required to do service
catalog lookups in multiple region environments. Without them Octavia
can try to contact a service in a different region than its own. Specify
region_name and endpoint_type for the glance, neutron, and nova services
to prevent this from happening.
Change-Id: I753cf443c1506bbd7b69fc47e2e0a9b39857509c
Closes-Bug: #1841479
This makes WS (so e.g. console) always work with the way we
deploy Zun. Otherwise it used the first IP address.
Change-Id: Ib31c5944be2f6fa00cdf5da3e638a590e6bace40
Closes-bug: #1841243
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
The internal FQDN assumes that HAProxy is set up to route traffic to the
DB; other services default to the value of database_address.
Change-Id: I9a333a89adfa4f620f211c831d659b8d52e307d5
ceph-ansible by default generates what we call nova.keyring as
openstack.keyring - adding a note to not confuse users.
Change-Id: I3992a037ab8e7947e35521b5c721a89bd954fdcd
This review is the first one in a series of patches and it introduces an
optional encryption for internal openstack endpoints, implementing part
of the add-ssl-internal-network spec.
Change-Id: I6589751626486279bf24725f22e71da8cd7f0a43
The baremetal role does not currently assume too much about the
inventory, and in kayobe the seed is deployed using a very minimal
inventory.
Icf3f01516185afb7b9f642407b06a0204c36ecbe added a reference to the etcd
group in the baremetal role, which causes kayobe seed deployment to fail
with the following error:
AnsibleUndefinedVariable: 'dict object' has no attribute 'etcd'
This change defaults the group lookup to an empty list.
Change-Id: Ib3252143a97652c5cf70b56cbfd7c7ce69f93a55
Closes-Bug: #1841073
In order to orchestrate smooth transition to fluentd 0.14.x
aka 1.0 stable branch aka td-agent 3
from td-agent repository - use image labels (fluentd_version
and fluentd_binary).
Depends-On: https://review.opendev.org/676411
Change-Id: Iab8518c34ef876056c6abcdb5f2e9fc9f1f7dbdd
Nova-consoleauth support was removed in
I099080979f5497537e390f531005a517ab12aa7a, but these variables were
left.
Change-Id: I1ce1631119bba991225835e8e409f11d53276550
Sometimes mgr dashboard enablement fails with following message:
"Error ENOENT: all mgr daemons do not support module 'dashboard',
pass --force to force enablement"
Change-Id: Ie7052dbdccb855e02da849dbc207b5d1778e2c82
The MariaDB role HAProxy config section exposes MariaDB on the
mariadb_port which may not always be the same as database_port. The
HAProxy role checks that the database_port is free, and not the
mariadb_port. This could mean that the check passes, but the actual
port which HAProxy will attempt to use is taken.
This change configures HAProxy to talk to the MariaDB instances on
the mariadb_port, and maps them to the database_port which is used by
most services as part of the DB connection string.
There is a small risk that it may break someones override config.
Change-Id: I9507ee709cb21eb743112107770ed3170c61ef74
The monasca_grafana docker volume currently persists across container
builds, causing changes to installed plugins during build to be ignored.
This change deletes the volume entirely and forces plugin changes to be
applied via rebuild.
Change-Id: I36e62235a085e5c1955fdb5ae31f603be8ba69bf
The previous default timeout was 10 seconds, which does not always
allow services enough time to shut down safely.
Change-Id: I54eff91567108a7e5d99f067829ae4a6900cd859
Zun was misconfigured and defaulted to using public endpoints
which are likely inaccessible from the internal network.
This patch fixes that and removes unused and deprecated
options. Validity of options confirmed from Queens to Train
against respective docs.
Change-Id: I25cc8792351c43eb9ff45465e49fa72ceccd6cb5
Closes-bug: #1840572
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
- Test Zun on CentOS too
- Make etcd change also trigger Zun jobs (like kuryr and zun)
- Test multinode Zun deployments instead of AIO
(more likely to break)
- In Zun scenario, stop configuring docker for legacy swarm mode
(Zun is no swarm)
- Separate test-zun.sh testing script
- Show appcontainer to see which node it has been started on
Change-Id: I289b1009fe00aedb9b78cbd83298b14da5fd9670
Depends-On: https://review.opendev.org/676736
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
This commit adds the functionality for an operator to specify
their own trusted CA certificate file for interacting with the
Keystone API.
Implements: blueprint support-trusted-ca-certificate-file
Change-Id: I84f9897cc8e107658701fb309ec318c0f805883b
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>
Heat has a new option (server_keystone_endpoint_type), which can be used
to set the keystone endpoint used by instances to make callbacks to
heat. This needs to be public, since we can't assume users have access
to the internal API. However, the current method of setting
[clients_heat] endpoint_type means that communication from heat to its
own API (e.g. when a stack is a resource in another stack) uses the
public network also, and this might not work if TLS is enabled.
This change uses server_keystone_endpoint_type to keep instance traffic
on the public API, and removes the [clients_heat] endpoint_type option
to use the default in [clients] endpoint_type of internalURL.
This feature was added to heat in https://review.opendev.org/#/c/650967.
Change-Id: I932ea55a3c2a411557c34361db08bcb3a2b27eaf
Closes-Bug: #1812864
Related-Bug: #1762754
Related-Bug: #1688331
Explicitly wait for the database to be accessible via the load balancer.
Sometimes it can reject connections even when all database services are up,
possibly due to the health check polling in HAProxy.
Closes-Bug: #1840145
Change-Id: I7601bb710097a78f6b29bc4018c71f2c6283eef2
