22a6223b1b
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 <rafael@apache.org>
67 lines
2.0 KiB
Django/Jinja
67 lines
2.0 KiB
Django/Jinja
[DEFAULT]
|
|
debug = {{ senlin_logging_debug }}
|
|
|
|
log_dir = /var/log/kolla/senlin
|
|
|
|
{% if service_name == 'senlin-engine' %}
|
|
num_engine_workers = {{ openstack_service_workers }}
|
|
{% endif %}
|
|
|
|
transport_url = {{ rpc_transport_url }}
|
|
|
|
{% if service_name == 'senlin-api' %}
|
|
[senlin_api]
|
|
bind_host = {{ api_interface_address }}
|
|
bind_port = {{ senlin_api_listen_port }}
|
|
workers = {{ openstack_service_workers }}
|
|
{% endif %}
|
|
|
|
[authentication]
|
|
auth_url = {{ keystone_admin_url }}
|
|
service_username = {{ senlin_keystone_user }}
|
|
service_password = {{ senlin_keystone_password }}
|
|
service_project_name = service
|
|
service_user_domain = default
|
|
service_project_domain = default
|
|
|
|
[database]
|
|
connection = mysql+pymysql://{{ senlin_database_user }}:{{ senlin_database_password }}@{{ senlin_database_address }}/{{ senlin_database_name }}
|
|
max_retries = -1
|
|
|
|
[keystone_authtoken]
|
|
www_authenticate_uri = {{ keystone_internal_url }}
|
|
auth_url = {{ keystone_admin_url }}
|
|
auth_type = password
|
|
project_domain_id = {{ default_project_domain_id }}
|
|
user_domain_id = {{ default_user_domain_id }}
|
|
project_name = service
|
|
username = {{ senlin_keystone_user }}
|
|
password = {{ senlin_keystone_password }}
|
|
service_token_roles_required = False
|
|
|
|
memcache_security_strategy = ENCRYPT
|
|
memcache_secret_key = {{ memcache_secret_key }}
|
|
memcached_servers = {% for host in groups['memcached'] %}{{ hostvars[host]['ansible_' + hostvars[host]['api_interface']]['ipv4']['address'] }}:{{ memcached_port }}{% if not loop.last %},{% endif %}{% endfor %}
|
|
|
|
[oslo_messaging_notifications]
|
|
transport_url = {{ notify_transport_url }}
|
|
{% if senlin_enabled_notification_topics %}
|
|
driver = messagingv2
|
|
topics = {{ senlin_enabled_notification_topics | map(attribute='name') | join(',') }}
|
|
{% else %}
|
|
driver = noop
|
|
{% endif %}
|
|
|
|
{% if senlin_policy_file is defined %}
|
|
[oslo_policy]
|
|
policy_file = {{ senlin_policy_file }}
|
|
{% endif %}
|
|
|
|
{% if enable_osprofiler | bool %}
|
|
[profiler]
|
|
enabled = true
|
|
trace_sqlalchemy = true
|
|
hmac_keys = {{ osprofiler_secret }}
|
|
connection_string = {{ osprofiler_backend_connection_string }}
|
|
{% endif %}
|