The ironic configuration in ironic.conf uses several options which have
been removed in the Train cycle:
[glance] glance_api_servers was removed in https://review.opendev.org/#/c/665929.
[neutron] url was removed in https://review.opendev.org/#/c/672971.
We should use the endpoint catalog instead of specifying the endpoint
for both of these, and also ironic inspector. region_name and
valid_interfaces have been added for that purpose.
Other options are deprecated.
[conductor] api_url: Use [service_catalog] section to lookup ironic API
endpoint instead.
[inspector] enabled: No longer used.
Change-Id: If07c4ff9bfea7d780aeff5c3295a0ace7d10ecdc
Closes-Bug: #1843067
Allows enabling neutron port forwarding plugin
and l3 extension to forward ports from floating
IP to a fixed neutron port.
Change-Id: Ic25c96a0ddcf4f69acbfb7a58acafec82c3b0aed
Implements: blueprint enable-l3-port-forwarding
Commit d68644386f5c159ac646f70883ecf1349c153c76 disabled these
deprecated plugins more than three years ago.
Change-Id: I2dd2a89a7aa2c4a54882a8b0aa8d23d874c0e4cc
Closes-Bug: #1839172
nova.conf currently uses the [neutron] "url" parameter which has been
deprecated since 17.0.0. In multi-region environments this can
cause Nova to look up the Neutron endpoint for a different region.
Remove this parameter and set region_name and
valid_interfaces to allow the correct lookup to be performed.
Change-Id: I1bbc73728439a460447bc8edd264f9f2d3c814e0
Closes-Bug: #1836952
Upstream ironic went from $net_default_ip to $net_default_mac in
ironic/drivers/modules/master_grub_cfg.txt with
https://review.opendev.org/#/c/578959/
This commit makes the same change for
ansible/roles/ironic/templates/ironic_pxe_uefi.default.j2
Using $net_default_ip breaks ironic standalone deployments with
[dhcp]dhcp_provider = none
Change-Id: I2ca9a66d2bdb0aab5cd9936c8be8206e6ade3bd5
Closes-Bug: 1842078
This resolves an issue where the web browser would complain that it
was trying to connect to insecure websocket when using HTTPS with
horizon.
Change-Id: Ib75cc2bc1b3811bc31badd5fda3db3ed0c59b119
Closes-Bug: #1841914
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
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
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>
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>
