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>
73 lines
2.2 KiB
Django/Jinja
73 lines
2.2 KiB
Django/Jinja
[DEFAULT]
|
|
debug = {{ keystone_logging_debug }}
|
|
|
|
transport_url = {{ rpc_transport_url }}
|
|
|
|
# NOTE(elemoine) log_dir alone does not work for Keystone
|
|
log_file = /var/log/kolla/keystone/keystone.log
|
|
use_stderr = True
|
|
|
|
[oslo_middleware]
|
|
enable_proxy_headers_parsing = True
|
|
|
|
{% if keystone_policy_file is defined %}
|
|
[oslo_policy]
|
|
policy_file = {{ keystone_policy_file }}
|
|
{% endif %}
|
|
|
|
[database]
|
|
connection = mysql+pymysql://{{ keystone_database_user }}:{{ keystone_database_password }}@{{ keystone_database_address }}/{{ keystone_database_name }}
|
|
max_retries = -1
|
|
|
|
{% if keystone_domain_directory.stat.exists %}
|
|
[identity]
|
|
domain_specific_drivers_enabled = true
|
|
domain_config_dir = /etc/keystone/domains
|
|
{% endif %}
|
|
|
|
[token]
|
|
revoke_by_id = False
|
|
provider = {{ keystone_token_provider }}
|
|
expiration = {{ fernet_token_expiry }}
|
|
allow_expired_window = {{ fernet_token_allow_expired_window }}
|
|
|
|
[fernet_tokens]
|
|
# Keystone docs note:
|
|
# max_active_keys =
|
|
# ((token_expiration + allow_expired_window) / rotation_frequency) + 2
|
|
# https://docs.openstack.org/keystone/stein/admin/fernet-token-faq.html
|
|
#
|
|
# Use (x + y - 1) / y to round up integer division.
|
|
max_active_keys = {{ ((fernet_token_expiry | int +
|
|
fernet_token_allow_expired_window | int +
|
|
fernet_key_rotation_interval | int - 1) //
|
|
fernet_key_rotation_interval | int) + 2 }}
|
|
|
|
[cache]
|
|
backend = oslo_cache.memcache_pool
|
|
enabled = True
|
|
memcache_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 keystone_enabled_notification_topics %}
|
|
driver = messagingv2
|
|
topics = {{ keystone_enabled_notification_topics | map(attribute='name') | join(',') }}
|
|
{% else %}
|
|
driver = noop
|
|
{% endif %}
|
|
|
|
|
|
{% if enable_osprofiler | bool %}
|
|
[profiler]
|
|
enabled = true
|
|
trace_sqlalchemy = true
|
|
hmac_keys = {{ osprofiler_secret }}
|
|
connection_string = {{ osprofiler_backend_connection_string }}
|
|
{% endif %}
|
|
|
|
{% if enable_grafana | bool %}
|
|
[cors]
|
|
allowed_origin = {{ public_protocol }}://{{ kolla_external_fqdn }}:{{ grafana_server_port }}
|
|
{% endif %}
|