Comment 1 for bug 1838985

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.

    * 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 <email address hidden>