406 lines
19 KiB
YAML
Raw Normal View History

---
project_name: "monasca"
monasca_services:
monasca-api:
container_name: monasca_api
group: monasca-api
enabled: true
image: "{{ monasca_api_image_full }}"
volumes: "{{ monasca_api_default_volumes + monasca_api_extra_volumes }}"
dimensions: "{{ monasca_api_dimensions }}"
haproxy:
monasca_api:
enabled: "{{ enable_monasca }}"
mode: "http"
external: false
port: "{{ monasca_api_port }}"
monasca_api_external:
enabled: "{{ enable_monasca }}"
mode: "http"
external: true
port: "{{ monasca_api_port }}"
Remove Monasca Log Transformer Historically Monasca Log Transformer has been for log standardisation and processing. For example, logs from different sources may use slightly different error levels such as WARN, 5, or WARNING. Monasca Log Transformer is a place where these could be 'squashed' into a single error level to simplify log searches based on labels such as these. However, in Kolla Ansible, we do this processing in Fluentd so that the simpler Fluentd -> Elastic -> Kibana pipeline also benefits. This helps to avoid spreading out log parsing configuration over many services, with the Fluentd Monasca output plugin being yet another potential place for processing (which should be avoided). It therefore makes sense to remove this service entirely, and squash any existing configuration which can't be moved to Fluentd into the Log Perister service. I.e. by removing this pipeline, we don't loose any functionality, we encourage log processing to take place in Fluentd, or at least outside of Monasca, and we make significant gains in efficiency by removing a topic from Kafka which contains a copy of all logs in transit. Finally, users forwarding logs from outside the control plane, eg. from tenant instances, should be encouraged to process the logs at the point of sending using whichever framework they are forwarding them with. This makes sense, because all Logstash configuration in Monasca is only accessible by control plane admins. A user can't typically do any processing inside Monasca, with or without this change. Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c
2021-01-07 17:14:15 +00:00
# NOTE(dszumski): We can remove log_transformer and all other references after the
# Wallaby release
monasca-log-transformer:
container_name: monasca_log_transformer
group: monasca-log-transformer
Remove Monasca Log Transformer Historically Monasca Log Transformer has been for log standardisation and processing. For example, logs from different sources may use slightly different error levels such as WARN, 5, or WARNING. Monasca Log Transformer is a place where these could be 'squashed' into a single error level to simplify log searches based on labels such as these. However, in Kolla Ansible, we do this processing in Fluentd so that the simpler Fluentd -> Elastic -> Kibana pipeline also benefits. This helps to avoid spreading out log parsing configuration over many services, with the Fluentd Monasca output plugin being yet another potential place for processing (which should be avoided). It therefore makes sense to remove this service entirely, and squash any existing configuration which can't be moved to Fluentd into the Log Perister service. I.e. by removing this pipeline, we don't loose any functionality, we encourage log processing to take place in Fluentd, or at least outside of Monasca, and we make significant gains in efficiency by removing a topic from Kafka which contains a copy of all logs in transit. Finally, users forwarding logs from outside the control plane, eg. from tenant instances, should be encouraged to process the logs at the point of sending using whichever framework they are forwarding them with. This makes sense, because all Logstash configuration in Monasca is only accessible by control plane admins. A user can't typically do any processing inside Monasca, with or without this change. Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c
2021-01-07 17:14:15 +00:00
enabled: false
image: "{{ monasca_logstash_image_full }}"
volumes: "{{ monasca_log_transformer_default_volumes + monasca_log_transformer_extra_volumes }}"
dimensions: "{{ monasca_log_transformer_dimensions }}"
monasca-log-persister:
container_name: monasca_log_persister
group: monasca-log-persister
enabled: true
image: "{{ monasca_logstash_image_full }}"
volumes: "{{ monasca_log_persister_default_volumes + monasca_log_persister_extra_volumes }}"
dimensions: "{{ monasca_log_persister_dimensions }}"
monasca-log-metrics:
container_name: monasca_log_metrics
group: monasca-log-metrics
enabled: "{{ monasca_enable_log_metrics_service | bool }}"
image: "{{ monasca_logstash_image_full }}"
volumes: "{{ monasca_log_metrics_default_volumes + monasca_log_metrics_extra_volumes }}"
dimensions: "{{ monasca_log_metrics_dimensions }}"
monasca-thresh:
container_name: monasca_thresh
group: monasca-thresh
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
image: "{{ monasca_thresh_image_full }}"
volumes: "{{ monasca_thresh_default_volumes + monasca_thresh_extra_volumes }}"
dimensions: "{{ monasca_thresh_dimensions }}"
monasca-notification:
container_name: monasca_notification
group: monasca-notification
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
image: "{{ monasca_notification_image_full }}"
volumes: "{{ monasca_notification_default_volumes + monasca_notification_extra_volumes }}"
dimensions: "{{ monasca_notification_dimensions }}"
monasca-persister:
container_name: monasca_persister
group: monasca-persister
enabled: true
image: "{{ monasca_persister_image_full }}"
volumes: "{{ monasca_persister_default_volumes + monasca_persister_extra_volumes }}"
dimensions: "{{ monasca_persister_dimensions }}"
monasca-agent-collector:
container_name: monasca_agent_collector
group: monasca-agent-collector
enabled: true
image: "{{ monasca_agent_image_full }}"
pid_mode: "host"
volumes: "{{ monasca_agent_collector_default_volumes + monasca_agent_collector_extra_volumes }}"
dimensions: "{{ monasca_agent_dimensions }}"
monasca-agent-statsd:
container_name: monasca_agent_statsd
group: monasca-agent-statsd
enabled: true
image: "{{ monasca_agent_image_full }}"
volumes: "{{ monasca_agent_statsd_default_volumes + monasca_agent_statsd_extra_volumes }}"
dimensions: "{{ monasca_agent_dimensions }}"
monasca-agent-forwarder:
container_name: monasca_agent_forwarder
group: monasca-agent-forwarder
enabled: true
image: "{{ monasca_agent_image_full }}"
volumes: "{{ monasca_agent_forwarder_default_volumes + monasca_agent_forwarder_extra_volumes }}"
dimensions: "{{ monasca_agent_dimensions }}"
# TODO(dszumski): Remove monasca-grafana entry here and all other references after the
# Xena release. It exists here to support cleanup operations.
monasca-grafana:
container_name: monasca_grafana
group: monasca-grafana
enabled: false
image: "{{ monasca_grafana_image_full }}"
volumes: "{{ monasca_grafana_default_volumes + monasca_grafana_extra_volumes }}"
dimensions: "{{ monasca_grafana_dimensions }}"
haproxy:
monasca_grafana_server:
enabled: "{{ enable_monasca }}"
mode: "http"
external: false
port: "{{ monasca_grafana_server_port }}"
monasca_grafana_server_external:
enabled: "{{ enable_monasca }}"
mode: "http"
external: true
port: "{{ monasca_grafana_server_port }}"
####################
# Databases
####################
monasca_database_name: "monasca"
monasca_database_user: "{% if use_preconfigured_databases | bool and use_common_mariadb_user | bool %}{{ database_user }}{% else %}monasca{% endif %}"
monasca_database_address: "{{ database_address }}"
monasca_database_port: "{{ database_port }}"
monasca_influxdb_name: "monasca"
Cloudkitty InfluxDB Storage backend via Kolla-ansible This proposal will add support to Kolla-Ansible for Cloudkitty InfluxDB storage system deployment. The feature of InfluxDB as the storage backend for Cloudkitty was created with the following commit https://github.com/openstack/cloudkitty/commit/ c4758e78b49386145309a44623502f8095a2c7ee Problem Description =================== With the addition of support for InfluxDB in Cloudkitty, which is achieving general availability via Stein release, we need a method to easily configure/support this storage backend system via Kolla-ansible. Kolla-ansible is already able to deploy and configure an InfluxDB system. Therefore, this proposal will use the InfluxDB deployment configured via Kolla-ansible to connect to CloudKitty and use it as a storage backend. If we do not provide a method for users (operators) to manage Cloudkitty storage backend via Kolla-ansible, the user has to execute these changes/configurations manually (or via some other set of automated scripts), which creates distributed set of configuration files, "configurations" scripts that have different versioning schemas and life cycles. Proposed Change =============== Architecture ------------ We propose a flag that users can use to make Kolla-ansible configure CloudKitty to use InfluxDB as the storage backend system. When enabling this flag, Kolla-ansible will also enable the deployment of the InfluxDB via Kolla-ansible automatically. CloudKitty will be configured accordingly to [1] and [2]. We will also externalize the "retention_policy", "use_ssl", and "insecure", to allow fine granular configurations to operators. All of these configurations will only be used when configured; therefore, when they are not set, the default value/behavior defined in Cloudkitty will be used. Moreover, when we configure "use_ssl" to "true", the user will be able to set "cafile" to a custom trusted CA file. Again, if these variables are not set, the default ones in Cloudkitty will be used. Implementation -------------- We need to introduce a new variable called `cloudkitty_storage_backend`. Valid options are `sqlalchemy` or `influxdb`. The default value in Kolla-ansible is `sqlalchemy` for backward compatibility. Then, the first step is to change the definition for the following variable: `/ansible/group_vars/all.yml:enable_influxdb: "{{ enable_monasca | bool }}"` We also need to enable InfluxDB when CloudKitty is configured to use it as the storage backend. Afterwards, we need to create tasks in CloudKitty configurations to create the InfluxDB schema and configure the configuration files accordingly. Alternatives ------------ The alternative would be to execute the configurations manually or handle it via a different set of scripts and configurations files, which can become cumbersome with time. Security Impact --------------- None identified by the author of this spec Notifications Impact -------------------- Operators that are already deploying CloudKitty with InfluxDB as storage backend would need to convert their configurations to Kolla-ansible (if they wish to adopt Kolla-ansible to execute these tasks). Also, deployments (OpenStack environments) that were created with Cloudkitty using storage v1 will need to migrate all of their data to V2 before enabling InfluxDB as the storage system. Other End User Impact --------------------- None. Performance Impact ------------------ None. Other Deployer Impact --------------------- New configuration options will be available for CloudKitty. * cloudkitty_storage_backend * cloudkitty_influxdb_retention_policy * cloudkitty_influxdb_use_ssl * cloudkitty_influxdb_cafile * cloudkitty_influxdb_insecure_connections * cloudkitty_influxdb_name Developer Impact ---------------- None Implementation ============== Assignee -------- * `Rafael Weingärtner <rafaelweingartne>` Work Items ---------- * Extend InfluxDB "enable/disable" variable * Add new tasks to configure Cloudkitty accordingly to these new variables that are presented above * Write documentation and release notes Dependencies ============ None Documentation Impact ==================== New documentation for the feature. References ========== [1] `https://docs.openstack.org/cloudkitty/latest/admin/configuration/storage.html#influxdb-v2` [2] `https://docs.openstack.org/cloudkitty/latest/admin/configuration/collector.html#metric-collection` Change-Id: I65670cb827f8ca5f8529e1786ece635fe44475b0 Signed-off-by: Rafael Weingärtner <rafael@apache.org>
2019-05-10 13:40:46 -03:00
monasca_influxdb_address: "{{ influxdb_address }}"
monasca_influxdb_http_port: "{{ influxdb_http_port }}"
monasca_influxdb_retention_policy:
name: 'monasca_metrics'
duration: "1w"
replication_count: 1
####################
# Monasca
####################
# NOTE(dszumski): This can be removed in the Xena cycle when the
# log metrics service is removed
monasca_enable_log_metrics_service: False
Implement IPv6 support in the control plane Introduce kolla_address filter. Introduce put_address_in_context filter. Add AF config to vars. Address contexts: - raw (default): <ADDR> - memcache: inet6:[<ADDR>] - url: [<ADDR>] Other changes: globals.yml - mention just IP in comment prechecks/port_checks (api_intf) - kolla_address handles validation 3x interface conditional (swift configs: replication/storage) 2x interface variable definition with hostname (haproxy listens; api intf) 1x interface variable definition with hostname with bifrost exclusion (baremetal pre-install /etc/hosts; api intf) neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network basic multinode source CI job for IPv6 prechecks for rabbitmq and qdrouterd use proper NSS database now MariaDB Galera Cluster WSREP SST mariabackup workaround (socat and IPv6) Ceph naming workaround in CI TODO: probably needs documenting RabbitMQ IPv6-only proto_dist Ceph ms switch to IPv6 mode Remove neutron-server ml2_type_vxlan/vxlan_group setting as it is not used (let's avoid any confusion) and could break setups without proper multicast routing if it started working (also IPv4-only) haproxy upgrade checks for slaves based on ipv6 addresses TODO: ovs-dpdk grabs ipv4 network address (w/ prefix len / submask) not supported, invalid by default because neutron_external has no address No idea whether ovs-dpdk works at all atm. ml2 for xenapi Xen is not supported too well. This would require working with XenAPI facts. rp_filter setting This would require meddling with ip6tables (there is no sysctl param). By default nothing is dropped. Unlikely we really need it. ironic dnsmasq is configured IPv4-only dnsmasq needs DHCPv6 options and testing in vivo. KNOWN ISSUES (beyond us): One cannot use IPv6 address to reference the image for docker like we currently do, see: https://github.com/moby/moby/issues/39033 (docker_registry; docker API 400 - invalid reference format) workaround: use hostname/FQDN RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4. This is due to old RabbitMQ versions available in images. IPv4 is preferred by default and may fail in the IPv6-only scenario. This should be no problem in real life as IPv6-only is indeed IPv6-only. Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will no longer be relevant as we supply all the necessary config. See: https://github.com/rabbitmq/rabbitmq-server/pull/1982 For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed to work well). Older Ansible versions are known to miss IPv6 addresses in interface facts. This may affect redeploys, reconfigures and upgrades which run after VIP address is assigned. See: https://github.com/ansible/ansible/issues/63227 Bifrost Train does not support IPv6 deployments. See: https://storyboard.openstack.org/#!/story/2006689 Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c Implements: blueprint ipv6-control-plane Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
2019-09-11 20:47:00 +02:00
monasca_kafka_servers: "{% for host in groups['kafka'] %}{{ 'api' | kolla_address(host) | put_address_in_context('url') }}:{{ kafka_port }}{% if not loop.last %},{% endif %}{% endfor %}"
monasca_zookeeper_servers: "{% for host in groups['zookeeper'] %}{{ 'api' | kolla_address(host) | put_address_in_context('url') }}:{{ zookeeper_client_port }}{% if not loop.last %},{% endif %}{% endfor %}"
monasca_memcached_servers: "{% for host in groups['memcached'] %}{{ 'api' | kolla_address(host) | put_address_in_context('memcache') }}:{{ memcached_port }}{% if not loop.last %},{% endif %}{% endfor %}"
monasca_elasticsearch_servers: "{% for host in groups['elasticsearch'] %}'{{ internal_protocol }}://{{ 'api' | kolla_address(host) | put_address_in_context('url') }}:{{ elasticsearch_port }}'{% if not loop.last %},{% endif %}{% endfor %}"
monasca_storm_nimbus_servers: "{% for host in groups['storm-nimbus'] %}'{{ 'api' | kolla_address(host) }}'{% if not loop.last %},{% endif %}{% endfor %}"
# NOTE(dszumski): Only one NTP server is currently supported by the Monasca Agent plugin
monasca_ntp_server: "{{ external_ntp_servers | first }}"
# The default number of Kafka topic partitions. This effectively limits
# the maximum number of workers per topic, counted over all nodes in the
# Monasca deployment. For example, if you have a 3 node Monasca
# deployment, you will by default have 3 instances of Monasca Persister,
# with each instance having 2 workers by default for the metrics topic.
# In this case, each worker on the metrics topic will be assigned 5
# partitions of the metrics topic. If you increase the worker or instance
# count, you may need to increase the partition count to ensure that all
# workers can get a share of the work.
monasca_default_topic_partitions: 30
# The default number of topic replicas. Generally you should not change
# this.
monasca_default_topic_replication_factor: "{{ kafka_broker_count if kafka_broker_count|int < 3 else 3 }}"
# Kafka topic names used by Monasca services
monasca_metrics_topic: "metrics"
monasca_raw_logs_topic: "logs"
monasca_transformed_logs_topic: "transformed-logs"
monasca_events_topic: "events"
monasca_alarm_state_transitions_topic: "alarm-state-transitions"
monasca_alarm_notifications_topic: "alarm-notifications"
monasca_alarm_notifications_retry_topic: "retry-notifications"
monasca_periodic_notifications_topic: "60-seconds-notifications"
# Kafka topic configuration. Most users will not need to modify these
# settings, however for deployments where resources are tightly
# constrained, or very large deployments where there are many parallel
# workers, it is worth considering changing them. Note that if you do
# change these settings, then you will need to manually remove each
# topic from the Kafka deployment for the change to take effect when
# the Monasca service is reconfigured.
monasca_all_topics:
- name: "{{ monasca_metrics_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: True
- name: "{{ monasca_raw_logs_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: True
- name: "{{ monasca_transformed_logs_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
Remove Monasca Log Transformer Historically Monasca Log Transformer has been for log standardisation and processing. For example, logs from different sources may use slightly different error levels such as WARN, 5, or WARNING. Monasca Log Transformer is a place where these could be 'squashed' into a single error level to simplify log searches based on labels such as these. However, in Kolla Ansible, we do this processing in Fluentd so that the simpler Fluentd -> Elastic -> Kibana pipeline also benefits. This helps to avoid spreading out log parsing configuration over many services, with the Fluentd Monasca output plugin being yet another potential place for processing (which should be avoided). It therefore makes sense to remove this service entirely, and squash any existing configuration which can't be moved to Fluentd into the Log Perister service. I.e. by removing this pipeline, we don't loose any functionality, we encourage log processing to take place in Fluentd, or at least outside of Monasca, and we make significant gains in efficiency by removing a topic from Kafka which contains a copy of all logs in transit. Finally, users forwarding logs from outside the control plane, eg. from tenant instances, should be encouraged to process the logs at the point of sending using whichever framework they are forwarding them with. This makes sense, because all Logstash configuration in Monasca is only accessible by control plane admins. A user can't typically do any processing inside Monasca, with or without this change. Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c
2021-01-07 17:14:15 +00:00
enabled: False
- name: "{{ monasca_events_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
- name: "{{ monasca_alarm_state_transitions_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
- name: "{{ monasca_alarm_notifications_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
- name: "{{ monasca_alarm_notifications_retry_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
- name: "{{ monasca_periodic_notifications_topic }}"
partitions: "{{ monasca_default_topic_partitions }}"
replication_factor: "{{ monasca_default_topic_replication_factor }}"
enabled: "{{ monasca_enable_alerting_pipeline | bool }}"
# NOTE(dszumski): Due to the way monasca-notification is currently
# implemented it is not recommended to change this period.
monasca_periodic_notifications_period: 60
# Agent settings
monasca_agent_max_buffer_size: 1000
monasca_agent_backlog_send_rate: 1000
monasca_agent_max_batch_size: 1000
monasca_agent_check_frequency: 30
# Processing pipeline threads. In a large scale deployment you will likely
# want to tune these with finer precision. For example, if you have a very
# high log throughput, the log metrics service consumer may require a
# higher thread count than the producer. You will also want to ensure that
# the total number of threads across all instances of a service does not
# exceed the Kafka topic partition count.
monasca_log_pipeline_threads: 2
monasca_metric_pipeline_threads: 2
####################
# Docker
####################
# NOTE(dszumski): Binary support for Monasca images is not yet available in Kolla
monasca_install_type: "{{ kolla_install_type }}"
monasca_tag: "{{ openstack_tag }}"
monasca_agent_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ monasca_install_type }}-monasca-agent"
monasca_agent_tag: "{{ monasca_tag }}"
monasca_agent_image_full: "{{ monasca_agent_image }}:{{ monasca_agent_tag }}"
monasca_api_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ monasca_install_type }}-monasca-api"
monasca_api_tag: "{{ monasca_tag }}"
monasca_api_image_full: "{{ monasca_api_image }}:{{ monasca_api_tag }}"
monasca_logstash_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ kolla_install_type }}-logstash"
monasca_logstash_tag: "{{ monasca_tag }}"
monasca_logstash_image_full: "{{ monasca_logstash_image }}:{{ monasca_logstash_tag }}"
monasca_thresh_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ monasca_install_type }}-monasca-thresh"
monasca_thresh_tag: "{{ monasca_tag }}"
monasca_thresh_image_full: "{{ monasca_thresh_image }}:{{ monasca_thresh_tag }}"
monasca_notification_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ monasca_install_type }}-monasca-notification"
monasca_notification_tag: "{{ monasca_tag }}"
monasca_notification_image_full: "{{ monasca_notification_image }}:{{ monasca_notification_tag }}"
monasca_persister_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ monasca_install_type }}-monasca-persister"
monasca_persister_tag: "{{ monasca_tag }}"
monasca_persister_image_full: "{{ monasca_persister_image }}:{{ monasca_persister_tag }}"
monasca_grafana_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ kolla_base_distro }}-{{ monasca_install_type }}-monasca-grafana"
monasca_grafana_tag: "{{ monasca_tag }}"
monasca_grafana_image_full: "{{ monasca_grafana_image }}:{{ monasca_grafana_tag }}"
monasca_agent_dimensions: "{{ default_container_dimensions }}"
monasca_api_dimensions: "{{ default_container_dimensions }}"
monasca_log_api_dimensions: "{{ default_container_dimensions }}"
monasca_log_transformer_dimensions: "{{ default_container_dimensions }}"
monasca_log_persister_dimensions: "{{ default_container_dimensions }}"
monasca_log_metrics_dimensions: "{{ default_container_dimensions }}"
monasca_thresh_dimensions: "{{ default_container_dimensions }}"
monasca_notification_dimensions: "{{ default_container_dimensions }}"
monasca_persister_dimensions: "{{ default_container_dimensions }}"
monasca_grafana_dimensions: "{{ default_container_dimensions }}"
monasca_agent_collector_default_volumes:
- "{{ node_config_directory }}/monasca-agent-collector/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
- "/sys:/sys:ro"
- "/dev/disk/:/dev/disk:ro"
monasca_agent_statsd_default_volumes:
- "{{ node_config_directory }}/monasca-agent-statsd/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
monasca_agent_forwarder_default_volumes:
- "{{ node_config_directory }}/monasca-agent-forwarder/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
monasca_api_default_volumes:
- "{{ node_config_directory }}/monasca-api/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
monasca_log_transformer_default_volumes:
- "{{ node_config_directory }}/monasca-log-transformer/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
- "monasca_log_transformer_data:/var/lib/logstash"
monasca_log_persister_default_volumes:
- "{{ node_config_directory }}/monasca-log-persister/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
- "monasca_log_persister_data:/var/lib/logstash"
monasca_log_metrics_default_volumes:
- "{{ node_config_directory }}/monasca-log-metrics/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
- "monasca_log_metrics_data:/var/lib/logstash"
monasca_thresh_default_volumes:
- "{{ node_config_directory }}/monasca-thresh/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "monasca_thresh:/var/lib/monasca-thresh/"
- "kolla_logs:/var/log/kolla"
monasca_notification_default_volumes:
- "{{ node_config_directory }}/monasca-notification/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
monasca_persister_default_volumes:
- "{{ node_config_directory }}/monasca-persister/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla"
monasca_grafana_default_volumes:
- "{{ node_config_directory }}/monasca-grafana/:{{ container_config_directory }}/:ro"
- "/etc/localtime:/etc/localtime:ro"
- "{{ '/etc/timezone:/etc/timezone:ro' if ansible_os_family == 'Debian' else '' }}"
- "kolla_logs:/var/log/kolla/"
monasca_extra_volumes: "{{ default_extra_volumes }}"
monasca_agent_collector_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_agent_statsd_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_agent_forwarder_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_api_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_log_transformer_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_log_persister_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_log_metrics_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_thresh_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_notification_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_persister_extra_volumes: "{{ monasca_extra_volumes }}"
monasca_grafana_extra_volumes: "{{ monasca_extra_volumes }}"
####################
# OpenStack
####################
monasca_openstack_auth: "{{ openstack_auth }}"
monasca_keystone_user: "monasca"
monasca_default_authorized_roles:
- admin
monasca_read_only_authorized_roles:
- monasca-read-only-user
# NOTE(dszumski): The first role in this list is assigned to the monasca-agent
# user for monitoring the OpenStack deployment.
monasca_agent_authorized_roles:
- agent
monasca_delegate_authorized_roles:
- admin
Standardize use and construction of endpoint URLs The goal for this push request is to normalize the construction and use of internal, external, and admin URLs. While extending Kolla-ansible to enable a more flexible method to manage external URLs, we noticed that the same URL was constructed multiple times in different parts of the code. This can make it difficult for people that want to work with these URLs and create inconsistencies in a large code base with time. Therefore, we are proposing here the use of "single Kolla-ansible variable" per endpoint URL, which facilitates for people that are interested in overriding/extending these URLs. As an example, we extended Kolla-ansible to facilitate the "override" of public (external) URLs with the following standard "<component/serviceName>.<companyBaseUrl>". Therefore, the "NAT/redirect" in the SSL termination system (HAproxy, HTTPD or some other) is done via the service name, and not by the port. This allows operators to easily and automatically create more friendly URL names. To develop this feature, we first applied this patch that we are sending now to the community. We did that to reduce the surface of changes in Kolla-ansible. Another example is the integration of Kolla-ansible and Consul, which we also implemented internally, and also requires URLs changes. Therefore, this PR is essential to reduce code duplicity, and to facility users/developers to work/customize the services URLs. Change-Id: I73d483e01476e779a5155b2e18dd5ea25f514e93 Signed-off-by: Rafael Weingärtner <rafael@apache.org>
2020-06-16 16:03:31 -03:00
monasca_api_admin_endpoint: "{{ monasca_api_admin_base_endpoint }}/v2.0"
monasca_api_internal_endpoint: "{{ monasca_api_internal_base_endpoint }}/v2.0"
monasca_api_public_endpoint: "{{ monasca_api_public_base_endpoint }}/v2.0"
monasca_logging_debug: "{{ openstack_logging_debug }}"
####################
# Keystone
####################
monasca_ks_services:
- name: "monasca-api"
type: "monitoring"
description: "Monasca monitoring as a service"
endpoints:
- {'interface': 'admin', 'url': '{{ monasca_api_admin_endpoint }}'}
- {'interface': 'internal', 'url': '{{ monasca_api_internal_endpoint }}'}
- {'interface': 'public', 'url': '{{ monasca_api_public_endpoint }}'}
- name: "monasca-log-api"
type: "logging"
description: "Monasca logging as a service"
endpoints:
- {'interface': 'admin', 'url': '{{ monasca_log_api_admin_endpoint }}'}
- {'interface': 'internal', 'url': '{{ monasca_log_api_internal_endpoint }}'}
- {'interface': 'public', 'url': '{{ monasca_log_api_public_endpoint }}'}
monasca_ks_users:
- project: "service"
user: "{{ monasca_keystone_user }}"
password: "{{ monasca_keystone_password }}"
role: "admin"
- project: "{{ monasca_control_plane_project }}"
user: "{{ monasca_agent_user }}"
password: "{{ monasca_agent_password }}"
role: "{{ monasca_agent_authorized_roles | first }}"
monasca_ks_roles:
- "{{ monasca_default_authorized_roles }}"
- "{{ monasca_agent_authorized_roles }}"
- "{{ monasca_read_only_authorized_roles }}"
- "{{ monasca_delegate_authorized_roles }}"