Micsonfiguration of Barbican, Ceilometer, and Nova oslo_messaging sections

Bug #1838985 reported by Rafael Weingartner
6
This bug affects 1 person
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_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. Related bug reports are:
* https://bugzilla.redhat.com/show_bug.cgi?id=1478274
* https://bugs.launchpad.net/ceilometer/+bug/1665449

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_cadf_notification' was set to 'no'. That parameter was a bit misleading, one could interpret that when it is set to 'no', the legacy mode is used. However, that is not what happens. As a consequence, Keystone is configured without any notifications.

Mark Goddard (mgoddard)
Changed in kolla-ansible:
importance: Undecided → Medium
Changed in kolla-ansible:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (master)
Download full text (5.9 KiB)

Reviewed: https://review.opendev.org/670626
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=22a6223b1b0d56011a4ddf3662104280d370f4ee
Submitter: Zuul
Branch: master

commit 22a6223b1b0d56011a4ddf3662104280d370f4ee
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
    "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.
    ...

Read more...

Changed in kolla-ansible:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/kolla-ansible 9.0.0.0rc1

This issue was fixed in the openstack/kolla-ansible 9.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.