2016-08-12 18:43:02 +00:00
|
|
|
[DEFAULT]
|
|
|
|
debug = {{ trove_logging_debug }}
|
|
|
|
|
|
|
|
log_dir = /var/log/kolla/trove
|
2016-12-20 08:01:13 +00:00
|
|
|
|
2017-04-18 07:10:44 +00:00
|
|
|
host = {{ api_interface_address }}
|
2016-12-20 08:01:13 +00:00
|
|
|
|
|
|
|
bind_port = {{ trove_api_port }}
|
2017-04-18 07:10:44 +00:00
|
|
|
bind_host = {{ api_interface_address }}
|
2016-08-12 18:43:02 +00:00
|
|
|
trove_api_workers = {{ openstack_service_workers }}
|
|
|
|
auth_strategy = keystone
|
|
|
|
|
2017-05-29 22:14:06 +00:00
|
|
|
transport_url = {{ rpc_transport_url }}
|
2016-08-12 18:43:02 +00:00
|
|
|
|
2018-12-18 18:36:18 +00:00
|
|
|
trove_auth_url = {{ keystone_internal_url }}/v3
|
2017-11-23 06:57:41 +00:00
|
|
|
|
2018-01-15 15:33:49 +00:00
|
|
|
os_region_name = {{ openstack_region_name }}
|
|
|
|
|
2017-11-23 06:57:41 +00:00
|
|
|
nova_compute_endpoint_type = internalURL
|
|
|
|
neutron_endpoint_type = internalURL
|
2018-01-17 07:02:20 +00:00
|
|
|
cinder_endpoint_type = internalURL
|
2017-11-23 06:57:41 +00:00
|
|
|
swift_endpoint_type = internalURL
|
|
|
|
glance_endpoint_type = internalURL
|
|
|
|
trove_endpoint_type = internalURL
|
|
|
|
|
|
|
|
network_driver = trove.network.neutron.NeutronDriver
|
|
|
|
|
|
|
|
network_label_regex = .*
|
2016-08-12 18:43:02 +00:00
|
|
|
|
|
|
|
[database]
|
|
|
|
connection = mysql+pymysql://{{ trove_database_user }}:{{ trove_database_password }}@{{ trove_database_address }}/{{ trove_database_name }}
|
|
|
|
|
|
|
|
[keystone_authtoken]
|
2018-12-18 18:36:18 +00:00
|
|
|
www_authenticate_uri = {{ keystone_internal_url }}
|
2017-06-30 12:24:23 +00:00
|
|
|
project_domain_name = {{ default_project_domain_name }}
|
2016-08-12 18:43:02 +00:00
|
|
|
project_name = service
|
2017-06-30 12:24:23 +00:00
|
|
|
user_domain_name = {{ default_user_domain_name }}
|
2016-08-12 18:43:02 +00:00
|
|
|
username = {{ trove_keystone_user }}
|
|
|
|
password = {{ trove_keystone_password }}
|
2018-12-18 18:36:18 +00:00
|
|
|
auth_url = {{ keystone_admin_url }}
|
2016-08-12 18:43:02 +00:00
|
|
|
auth_type = password
|
2020-04-03 13:49:08 +00:00
|
|
|
cafile = {{ openstack_cacert }}
|
2017-03-10 17:12:13 +00:00
|
|
|
|
|
|
|
[oslo_messaging_notifications]
|
2017-05-29 22:14:06 +00:00
|
|
|
transport_url = {{ notify_transport_url }}
|
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 <rafael@apache.org>
2019-07-26 12:25:25 +00:00
|
|
|
{% if trove_enabled_notification_topics %}
|
2017-03-10 17:12:13 +00:00
|
|
|
driver = messagingv2
|
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 <rafael@apache.org>
2019-07-26 12:25:25 +00:00
|
|
|
topics = {{ trove_enabled_notification_topics | map(attribute='name') | join(',') }}
|
2017-03-10 17:12:13 +00:00
|
|
|
{% else %}
|
|
|
|
driver = noop
|
|
|
|
{% endif %}
|
2017-04-10 14:31:41 +00:00
|
|
|
|
|
|
|
{% if enable_osprofiler | bool %}
|
|
|
|
[profiler]
|
|
|
|
enabled = true
|
|
|
|
trace_sqlalchemy = true
|
|
|
|
hmac_keys = {{ osprofiler_secret }}
|
2018-04-24 06:08:28 +00:00
|
|
|
connection_string = {{ osprofiler_backend_connection_string }}
|
2017-04-10 14:31:41 +00:00
|
|
|
{% endif %}
|
2018-08-13 08:12:00 +00:00
|
|
|
|
|
|
|
{% if trove_policy_file is defined %}
|
|
|
|
[oslo_policy]
|
|
|
|
policy_file = {{ trove_policy_file }}
|
|
|
|
{% endif %}
|