Micsonfiguration of Barbican, Ceilometer, and Nova oslo_messaging sections
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kolla-ansible |
Fix Released
|
Medium
|
Rafael Weingartner | ||
Stein |
Triaged
|
Medium
|
Unassigned | ||
Train |
Fix Released
|
Medium
|
Rafael Weingartner |
Bug Description
Kolla-ansible does not configure nova notifications as it should. If 'searchlight' is not installed (enable) the 'notification_
* https:/
* https:/
Moreover, 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.
And, last, but not least. By default, Kolla-ansible was not enabling Keystone notification when 'enable_
Changed in kolla-ansible: | |
importance: | Undecided → Medium |
Changed in kolla-ansible: | |
status: | New → In Progress |
Reviewed: https:/ /review. opendev. org/670626 /git.openstack. org/cgit/ openstack/ kolla-ansible/ commit/ ?id=22a6223b1b0 d56011a4ddf3662 104280d370f4ee
Committed: https:/
Submitter: Zuul
Branch: master
commit 22a6223b1b0d560 11a4ddf36621042 80d370f4ee
Author: Rafael Weingärtner <email address hidden>
Date: Fri Jul 26 09:25:25 2019 -0300
Standardize the configuration of "oslo_messaging" section
After all of the discussions we had on /review. opendev. org/#/c/ 670626/ 2", I studied all projects that
"https:/
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: publisher/ messaging. py. messaging_ notifications" section in 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/
Therefore, we do not need to do anything for the
"oslo_
* 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 format' should be 'unversioned'. The default is notifications; but that queue has no consumer when
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_
'both'; so nova will send a notification to the queue
versioned_
'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 /bugs.launchpad .net/ceilometer /+bug/1665449
https:/
* 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.
...