openstack/kolla-ansible
Code Issues Proposed changes
3dcb6ad809
kolla-ansible/ansible/site.yml

1121 lines
29 KiB
YAML
Raw Normal View History

Initial commit for adding ansible support This adds a very basic structure to begin supporting ansible in Kolla. Ansible can support complete idempotency, but wrapping docker-compose does not allow idempotency at this time. These playbooks will be extended to compensate for that in future patches. Change-Id: I1c9e8d32321e2733f5a9b752edf74b4fe90317ed
2015-03-28 17:16:24 -05:00
---
Fix fact gathering with --limit Prior to this change, when the --limit argument is used, each host in the limit gathers facts for every other host. This is clearly unnecessary, and can result in up to (N-1)^2 fact gathers. This change gathers facts for each host only once. Hosts that are not in the limit are divided between those that are in the limit, and facts are gathered via delegation. This change also factors out the fact gathering logic into a separate playbook that is imported where necessary. Change-Id: I923df5af41a7f1b7b0142d0da185a9a0979be543
2018-09-17 16:01:52 +01:00
- import_playbook: gather-facts.yml
Fix fact gathering when using --limit If an operator wants to deploy a single node (e.g. add an additional compute), they may want to use the --limit feature of Ansible to avoid waiting for every play across every node. The problem with this is that --limit will gather facts for that node only, causing template errors such as the infamous ('dict object' has no attribute u'ansible_eth0'"). Ansible has catered to this problem to an extent with it's "delegate_facts" mechanism. The only problem is that in the default 'all nodes' case, we end up with a storm of SSHs as each node SSHs to every other. I'm solving this with a separate task to only use this mechanism when a subset of nodes has been specified (see ansible_play_batch). Useful links on this subject: - https://medium.com/@george.shuklin/perfecting-forced-fact-gathering-in-ansible-1611f9c8d0d5#.tr5zs3e7x - http://docs.ansible.com/ansible/playbooks_delegation.html#delegated-facts Change-Id: Ibb691eae15cacd9e5129ae9280fd296f5ba95940 Closes-Bug: 1642004
2016-11-15 17:14:35 +00:00
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
# NOTE(mgoddard): In large environments, even tasks that are skipped can take a
# significant amount of time. This is an optimisation to prevent any tasks
# running in the subsequent plays for services that are disabled.
- name: Group hosts based on configuration
hosts: all
gather_facts: false
tasks:
- name: Group hosts based on Kolla action
group_by:
key: "kolla_action_{{ kolla_action }}"
Set changed_when to false for group_by tasks This trivial patch is just turning off ansible changed report for group_by tasks as it could be confusing for user. Change-Id: I7512af573782359a6f01290a55291ac7eb0de867
2021-03-10 18:06:02 +01:00
changed_when: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- name: Group hosts based on enabled services
group_by:
key: "{{ item }}"
Set changed_when to false for group_by tasks This trivial patch is just turning off ansible changed report for group_by tasks as it could be confusing for user. Change-Id: I7512af573782359a6f01290a55291ac7eb0de867
2021-03-10 18:06:02 +01:00
changed_when: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
with_items:
- enable_aodh_{{ enable_aodh | bool }}
- enable_barbican_{{ enable_barbican | bool }}
- enable_blazar_{{ enable_blazar | bool }}
- enable_ceilometer_{{ enable_ceilometer | bool }}
Add support for Ceph RadosGW integration * Register Swift-compatible endpoints in Keystone * Load balance across RadosGW API servers using HAProxy The support is exercised in the cephadm CI jobs, but since RGW is not currently enabled via cephadm, it is not yet tested. https://docs.ceph.com/en/latest/radosgw/keystone/ Implements: blueprint ceph-rgw Change-Id: I891c3ed4ed93512607afe65a42dd99596fd4dbf9
2021-02-19 13:39:06 +00:00
- enable_ceph_rgw_{{ enable_ceph_rgw | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_cinder_{{ enable_cinder | bool }}
- enable_cloudkitty_{{ enable_cloudkitty | bool }}
- enable_collectd_{{ enable_collectd | bool }}
Add cyborg to kolla-ansible Because kolla-ansible not have cyborg so should add it. Implements: blueprint add-cyborg-to-kolla-ansible Depend-On: I497e67e3a754fccfd2ef5a82f13ccfaf890a6fcd Change-Id: I6f7ae86f855c5c64697607356d0ff3161f91b239
2018-12-02 21:17:07 +08:00
- enable_cyborg_{{ enable_cyborg | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_designate_{{ enable_designate | bool }}
- enable_elasticsearch_{{ enable_elasticsearch | bool }}
- enable_etcd_{{ enable_etcd | bool }}
- enable_freezer_{{ enable_freezer | bool }}
- enable_glance_{{ enable_glance | bool }}
- enable_gnocchi_{{ enable_gnocchi | bool }}
- enable_grafana_{{ enable_grafana | bool }}
Add HAcluster Ansible role Adds HAcluster Ansible role. This role contains High Availability clustering solution composed of Corosync, Pacemaker and Pacemaker Remote. HAcluster is added as a helper role for Masakari which requires it for its host monitoring, allowing to provide HA to instances on a failed compute host. Kolla hacluster images merged in [1]. [1] https://review.opendev.org/#/c/668765/ Change-Id: I91e5c1840ace8f567daf462c4eb3ec1f0c503823 Implements: blueprint ansible-pacemaker-support Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com> Co-Authored-By: Mark Goddard <mark@stackhpc.com>
2019-07-10 11:38:14 -04:00
- enable_hacluster_{{ enable_hacluster | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_heat_{{ enable_heat | bool }}
- enable_horizon_{{ enable_horizon | bool }}
- enable_influxdb_{{ enable_influxdb | bool }}
- enable_ironic_{{ enable_ironic | bool }}
- enable_iscsid_{{ enable_iscsid | bool }}
- enable_kafka_{{ enable_kafka | bool }}
- enable_keystone_{{ enable_keystone | bool }}
- enable_kibana_{{ enable_kibana | bool }}
- enable_kuryr_{{ enable_kuryr | bool }}
Rename role haproxy to loadbalancer For now role haproxy is maintaining haproxy and keepalived. In follow-up changes there is also proxysql added. This patch is *only* renaming/moving stuff to more prominent role loadbalancer, and moving also specific templates to subdirectory. This was done only to better diff in follow-up changes. Change-Id: I1d39d5bcaefc4016983bf267a2736b742cc3a555
2021-01-13 13:19:25 +00:00
- enable_loadbalancer_{{ enable_loadbalancer | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_magnum_{{ enable_magnum | bool }}
- enable_manila_{{ enable_manila | bool }}
- enable_mariadb_{{ enable_mariadb | bool }}
Add Masakari Ansible role Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Depends-On: https://review.openstack.org/#/c/615469/ Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa Implements: blueprint ansible-masakari Co-Authored-By: Gaëtan Trellu <gaetan.trellu@incloudus.com>
2018-11-06 10:20:02 +07:00
- enable_masakari_{{ enable_masakari | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_memcached_{{ enable_memcached | bool }}
- enable_mistral_{{ enable_mistral | bool }}
- enable_monasca_{{ enable_monasca | bool }}
- enable_multipathd_{{ enable_multipathd | bool }}
- enable_murano_{{ enable_murano | bool }}
- enable_neutron_{{ enable_neutron | bool }}
- enable_nova_{{ enable_nova | bool }}
- enable_octavia_{{ enable_octavia | bool }}
- enable_openvswitch_{{ enable_openvswitch | bool }}_enable_ovs_dpdk_{{ enable_ovs_dpdk | bool }}
- enable_outward_rabbitmq_{{ enable_outward_rabbitmq | bool }}
OVN Support Implement OVN Ansible role. Implements: blueprint ovn-controller-neutron-ansible Depends-On: https://review.opendev.org/713422 Change-Id: Icd425dea85d58db49c838839d8f0b864b4a89a78
2019-12-20 11:35:35 +01:00
- enable_ovn_{{ enable_ovn | bool }}
Split placement from nova Depends-On: https://review.openstack.org/#/c/642958 Depends-On: https://review.openstack.org/642984 Change-Id: If795a9eb3ec92f75867ce3f755d6b832eba31af9
2018-10-26 18:13:48 +02:00
- enable_placement_{{ enable_placement | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_prometheus_{{ enable_prometheus | bool }}
- enable_qdrouterd_{{ enable_qdrouterd | bool }}
- enable_rabbitmq_{{ enable_rabbitmq | bool }}
- enable_redis_{{ enable_redis | bool }}
- enable_sahara_{{ enable_sahara | bool }}
- enable_senlin_{{ enable_senlin | bool }}
- enable_skydive_{{ enable_skydive | bool }}
- enable_solum_{{ enable_solum | bool }}
Skip storm play when not enabled Minor scalability improvement, not currently applied to storm. Change-Id: I928d362067c52c3113bc0fbd3ae4b9be1810b7e5 TrivialFix
2020-06-26 14:42:16 +01:00
- enable_storm_{{ enable_storm | bool }}
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- enable_swift_{{ enable_swift | bool }}
- enable_tacker_{{ enable_tacker | bool }}
- enable_telegraf_{{ enable_telegraf | bool }}
- enable_trove_{{ enable_trove | bool }}
- enable_vitrage_{{ enable_vitrage | bool }}
- enable_watcher_{{ enable_watcher | bool }}
- enable_zookeeper_{{ enable_zookeeper | bool }}
- enable_zun_{{ enable_zun | bool }}
tags: always
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role prechecks
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
# Apply only when kolla action is 'precheck'.
hosts: kolla_action_precheck
Move precheck into its own role * Merge prechecks.yml and site.yml playbook * Create empty precheck.yml into all roles. Change-Id: I8a138558a26c0a2a66c5fd48ed37be657c99c1dd Implements: blueprint condition-pre-check
2016-11-03 14:48:58 +08:00
roles:
- role: prechecks
Performance: Run common role in a separate play The common role was previously added as a dependency to all other roles. It would set a fact after running on a host to avoid running twice. This had the nice effect that deploying any service would automatically pull in the common services for that host. When using tags, any services with matching tags would also run the common role. This could be both surprising and sometimes useful. When using Ansible at large scale, there is a penalty associated with executing a task against a large number of hosts, even if it is skipped. The common role introduces some overhead, just in determining that it has already run. This change extracts the common role into a separate play, and removes the dependency on it from all other roles. New groups have been added for cron, fluentd, and kolla-toolbox, similar to other services. This changes the behaviour in the following ways: * The common role is now run for all hosts at the beginning, rather than prior to their first enabled service * Hosts must be in the necessary group for each of the common services in order to have that service deployed. This is mostly to avoid deploying on localhost or the deployment host * If tags are specified for another service e.g. nova, the common role will *not* automatically run for matching hosts. The common tag must be specified explicitly The last of these is probably the largest behaviour change. While it would be possible to determine which hosts should automatically run the common role, it would be quite complex, and would introduce some overhead that would probably negate the benefit of splitting out the common role. Partially-Implements: blueprint performance-improvements Change-Id: I6a4676bf6efeebc61383ec7a406db07c7a868b2a
2020-06-30 11:05:01 +01:00
- name: Apply role common
gather_facts: false
hosts:
- cron
- fluentd
- kolla-logs
- kolla-toolbox
serial: '{{ kolla_serial|default("0") }}'
tags:
- common
roles:
- role: common
Rename role haproxy to loadbalancer For now role haproxy is maintaining haproxy and keepalived. In follow-up changes there is also proxysql added. This patch is *only* renaming/moving stuff to more prominent role loadbalancer, and moving also specific templates to subdirectory. This was done only to better diff in follow-up changes. Change-Id: I1d39d5bcaefc4016983bf267a2736b742cc3a555
2021-01-13 13:19:25 +00:00
- name: Apply role loadbalancer
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
gather_facts: false
hosts:
Rename role haproxy to loadbalancer For now role haproxy is maintaining haproxy and keepalived. In follow-up changes there is also proxysql added. This patch is *only* renaming/moving stuff to more prominent role loadbalancer, and moving also specific templates to subdirectory. This was done only to better diff in follow-up changes. Change-Id: I1d39d5bcaefc4016983bf267a2736b742cc3a555
2021-01-13 13:19:25 +00:00
- loadbalancer
- '&enable_loadbalancer_True'
Add serial to haproxy in site.yml Change-Id: I2ddc8ce114ebc9754f53866cefbff50e63ed7c7d
2020-01-24 21:29:15 +01:00
serial: '{{ kolla_serial|default("0") }}'
Generate HAProxy configuration for all enabled servvices This change applys the HAProxy tag to the entire play, ensuring HAProxy configuration is generated for all services when the HAProxy tag is specified. Change-Id: I67f57c831a713142d38c6e7b70f814a9ee8e5aae Closes-Bug: #1855094
2019-12-04 11:31:45 +00:00
tags:
Remove haproxy,keepalived groups Haproxy was renamed in [1]. [1] https://review.opendev.org/c/openstack/kolla-ansible/+/770618 Change-Id: Ib2d7f0774fede570a8c4c315d83afd420c31da0b
2021-09-03 16:41:50 +02:00
- haproxy
- keepalived
Rename role haproxy to loadbalancer For now role haproxy is maintaining haproxy and keepalived. In follow-up changes there is also proxysql added. This patch is *only* renaming/moving stuff to more prominent role loadbalancer, and moving also specific templates to subdirectory. This was done only to better diff in follow-up changes. Change-Id: I1d39d5bcaefc4016983bf267a2736b742cc3a555
2021-01-13 13:19:25 +00:00
- loadbalancer
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
roles:
Rename role haproxy to loadbalancer For now role haproxy is maintaining haproxy and keepalived. In follow-up changes there is also proxysql added. This patch is *only* renaming/moving stuff to more prominent role loadbalancer, and moving also specific templates to subdirectory. This was done only to better diff in follow-up changes. Change-Id: I1d39d5bcaefc4016983bf267a2736b742cc3a555
2021-01-13 13:19:25 +00:00
- { role: loadbalancer,
when: enable_loadbalancer | bool }
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks:
- block:
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: aodh
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: aodh
when: enable_aodh | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: barbican
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: barbican
when: enable_barbican | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: blazar
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: blazar
when: enable_blazar | bool
Add support for Ceph RadosGW integration * Register Swift-compatible endpoints in Keystone * Load balance across RadosGW API servers using HAProxy The support is exercised in the cephadm CI jobs, but since RGW is not currently enabled via cephadm, it is not yet tested. https://docs.ceph.com/en/latest/radosgw/keystone/ Implements: blueprint ceph-rgw Change-Id: I891c3ed4ed93512607afe65a42dd99596fd4dbf9
2021-02-19 13:39:06 +00:00
- include_role:
name: ceph-rgw
tasks_from: loadbalancer
tags: ceph-rgw
when: enable_ceph_rgw | bool
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: cinder
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: cinder
when: enable_cinder | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: cloudkitty
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: cloudkitty
when: enable_cloudkitty | bool
Add cyborg to kolla-ansible Because kolla-ansible not have cyborg so should add it. Implements: blueprint add-cyborg-to-kolla-ansible Depend-On: I497e67e3a754fccfd2ef5a82f13ccfaf890a6fcd Change-Id: I6f7ae86f855c5c64697607356d0ff3161f91b239
2018-12-02 21:17:07 +08:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: cyborg
Add cyborg to kolla-ansible Because kolla-ansible not have cyborg so should add it. Implements: blueprint add-cyborg-to-kolla-ansible Depend-On: I497e67e3a754fccfd2ef5a82f13ccfaf890a6fcd Change-Id: I6f7ae86f855c5c64697607356d0ff3161f91b239
2018-12-02 21:17:07 +08:00
tasks_from: loadbalancer
tags: cyborg
when: enable_cyborg | bool
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: designate
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: designate
when: enable_designate | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: elasticsearch
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: elasticsearch
when: enable_elasticsearch | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: freezer
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: freezer
when: enable_freezer | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: glance
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: glance
when: enable_glance | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: gnocchi
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: gnocchi
when: enable_gnocchi | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: grafana
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: grafana
when: enable_grafana | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: heat
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: heat
when: enable_heat | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: horizon
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: horizon
when: enable_horizon | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: influxdb
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: influxdb
when: enable_influxdb | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: ironic
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: ironic
when: enable_ironic | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: keystone
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: keystone
when: enable_keystone | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: kibana
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: kibana
when: enable_kibana | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: magnum
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: magnum
when: enable_magnum | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: manila
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: manila
when: enable_manila | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: mariadb
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: mariadb
Fix haproxy deploy for external mariadb cluster Change-Id: I12fa6ae8dcec79485c30c4fea2977875aa8f4fae Closes-Bug: #1850792
2019-11-03 23:07:57 +03:00
when: enable_mariadb | bool or enable_external_mariadb_load_balancer | bool
Add Masakari Ansible role Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Depends-On: https://review.openstack.org/#/c/615469/ Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa Implements: blueprint ansible-masakari Co-Authored-By: Gaëtan Trellu <gaetan.trellu@incloudus.com>
2018-11-06 10:20:02 +07:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: masakari
Add Masakari Ansible role Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Depends-On: https://review.openstack.org/#/c/615469/ Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa Implements: blueprint ansible-masakari Co-Authored-By: Gaëtan Trellu <gaetan.trellu@incloudus.com>
2018-11-06 10:20:02 +07:00
tasks_from: loadbalancer
tags: masakari
when: enable_masakari | bool
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: memcached
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: memcached
when: enable_memcached | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: mistral
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: mistral
when: enable_mistral | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: monasca
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: monasca
when: enable_monasca | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: murano
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: murano
when: enable_murano | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: neutron
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: neutron
when: enable_neutron | bool
Split placement from nova Depends-On: https://review.openstack.org/#/c/642958 Depends-On: https://review.openstack.org/642984 Change-Id: If795a9eb3ec92f75867ce3f755d6b832eba31af9
2018-10-26 18:13:48 +02:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: placement
Split placement from nova Depends-On: https://review.openstack.org/#/c/642958 Depends-On: https://review.openstack.org/642984 Change-Id: If795a9eb3ec92f75867ce3f755d6b832eba31af9
2018-10-26 18:13:48 +02:00
tasks_from: loadbalancer
tags: placement
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: nova
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
Support multiple nova cells This patch adds initial support for deploying multiple Nova cells. Splitting a nova-cell role out from the Nova role allows a more granular approach to deploying and configuring Nova services. A new enable_cells flag has been added that enables the support of multiple cells via the introduction of a super conductor in addition to cell-specific conductors. When this flag is not set (the default), nova is configured in the same manner as before - with a single conductor. The nova role now deploys the global services: * nova-api * nova-scheduler * nova-super-conductor (if enable_cells is true) The nova-cell role handles services specific to a cell: * nova-compute * nova-compute-ironic * nova-conductor * nova-libvirt * nova-novncproxy * nova-serialproxy * nova-spicehtml5proxy * nova-ssh This patch does not support using a single cell controller for managing more than one cell. Support for sharing a cell controller will be added in a future patch. This patch should be backwards compatible and is tested by existing CI jobs. A new CI job has been added that tests a multi-cell environment. ceph-mon has been removed from the play hosts list as it is not necessary - delegate_to does not require the host to be in the play. Documentation will be added in a separate patch. Partially Implements: blueprint support-nova-cells Co-Authored-By: Mark Goddard <mark@stackhpc.com> Change-Id: I810aad7d49db3f5a7fd9a2f0f746fd912fe03917
2019-08-19 15:52:46 +01:00
tags:
- nova
- nova-api
when: enable_nova | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: nova-cell
Support multiple nova cells This patch adds initial support for deploying multiple Nova cells. Splitting a nova-cell role out from the Nova role allows a more granular approach to deploying and configuring Nova services. A new enable_cells flag has been added that enables the support of multiple cells via the introduction of a super conductor in addition to cell-specific conductors. When this flag is not set (the default), nova is configured in the same manner as before - with a single conductor. The nova role now deploys the global services: * nova-api * nova-scheduler * nova-super-conductor (if enable_cells is true) The nova-cell role handles services specific to a cell: * nova-compute * nova-compute-ironic * nova-conductor * nova-libvirt * nova-novncproxy * nova-serialproxy * nova-spicehtml5proxy * nova-ssh This patch does not support using a single cell controller for managing more than one cell. Support for sharing a cell controller will be added in a future patch. This patch should be backwards compatible and is tested by existing CI jobs. A new CI job has been added that tests a multi-cell environment. ceph-mon has been removed from the play hosts list as it is not necessary - delegate_to does not require the host to be in the play. Documentation will be added in a separate patch. Partially Implements: blueprint support-nova-cells Co-Authored-By: Mark Goddard <mark@stackhpc.com> Change-Id: I810aad7d49db3f5a7fd9a2f0f746fd912fe03917
2019-08-19 15:52:46 +01:00
tasks_from: loadbalancer
tags:
- nova
- nova-cell
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
when: enable_nova | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: octavia
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: octavia
when: enable_octavia | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: prometheus
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: prometheus
when: enable_prometheus | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: rabbitmq
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: rabbitmq
vars:
role_rabbitmq_cluster_cookie:
role_rabbitmq_groups:
when: enable_rabbitmq | bool or enable_outward_rabbitmq | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: sahara
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: sahara
when: enable_sahara | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: senlin
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: senlin
when: enable_senlin | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: skydive
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: skydive
when: enable_skydive | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: solum
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: solum
when: enable_solum | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: swift
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: swift
when: enable_swift | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: tacker
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: tacker
when: enable_tacker | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: trove
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: trove
when: enable_trove | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: vitrage
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: vitrage
when: enable_vitrage | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: watcher
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: watcher
when: enable_watcher | bool
- include_role:
Use "name:" instead of "role:" for *_role modules Both include_role and import_role expect role's name to be given via "name" param instead of "role". This worked but caused errors with ansible-lint. See: https://review.opendev.org/694779 Change-Id: I388d4ae27111e430d38df1abcb6c6127d90a06e0
2020-03-02 10:01:17 +01:00
name: zun
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
tasks_from: loadbalancer
tags: zun
when: enable_zun | bool
when:
- enable_haproxy | bool
- kolla_action in ['deploy', 'reconfigure', 'upgrade', 'config']
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role collectd
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- collectd
- '&enable_collectd_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Ansible roles for collectd Container Collectd-ceilometer-plugin is essential for further more detailed metrics collection, smarter scheduling and service assurance. Change-Id: I8da572980de370517ec120d745ad1d36e316b465 Implements: blueprint collectd-ceilometer-plugin
2016-09-09 10:20:18 +01:00
roles:
- { role: collectd,
tags: collectd,
when: enable_collectd | bool }
Add support for deploying ZooKeeper This picks up the abandoned review: https://review.openstack.org/#/c/412423 Co-Authored-By: Sam Yaple <sam@yaple.net> Partially-Implements: blueprint monasca-roles Change-Id: Idc01afcb125271181ee5e15d327d0929f07b49e9
2018-02-23 17:36:27 +00:00
- name: Apply role zookeeper
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- zookeeper
- '&enable_zookeeper_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add support for deploying ZooKeeper This picks up the abandoned review: https://review.openstack.org/#/c/412423 Co-Authored-By: Sam Yaple <sam@yaple.net> Partially-Implements: blueprint monasca-roles Change-Id: Idc01afcb125271181ee5e15d327d0929f07b49e9
2018-02-23 17:36:27 +00:00
roles:
- { role: zookeeper,
tags: zookeeper,
when: enable_zookeeper | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role influxdb
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- influxdb
- '&enable_influxdb_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Added influxdb role Added ansible role for influxdb Introduced host groups for monitoring and influxdb and assign role Monitoring is deployed on a separate node called monitoring01 by default Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: If2465a14b18c6c3fd657af587a0b85f6b7a0191a Partially-Implements: Blueprint performance-monitoring
2016-07-27 06:23:29 +00:00
roles:
- { role: influxdb,
tags: influxdb,
when: enable_influxdb | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role telegraf
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Added telegraf role Added ansible role to deploy telegraf Roll out telegraf to all nodes Introduce parameter to toggle deployment of performance monitoring Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: Ia09b20ce65bf557c1a1030eda99df5cc88debd01 Partially-Implements: Blueprint performance-monitoring
2016-07-23 17:34:03 +00:00
- telegraf
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_telegraf_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Added telegraf role Added ansible role to deploy telegraf Roll out telegraf to all nodes Introduce parameter to toggle deployment of performance monitoring Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: Ia09b20ce65bf557c1a1030eda99df5cc88debd01 Partially-Implements: Blueprint performance-monitoring
2016-07-23 17:34:03 +00:00
roles:
- { role: telegraf,
tags: telegraf,
when: enable_telegraf | bool }
Add Redis role Rollout redis container in master/slave configuration Deploy redis-sentinel and connect to redis cluster Redis is needed for mistral coordination backend. Partial-Bug: #1700591 Change-Id: Ic0269d0db10624925e7bcdbf0e33ae87b84a9cf2
2017-07-21 07:08:54 +00:00
- name: Apply role redis
gather_facts: false
hosts:
- redis
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_redis_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add Redis role Rollout redis container in master/slave configuration Deploy redis-sentinel and connect to redis cluster Redis is needed for mistral coordination backend. Partial-Bug: #1700591 Change-Id: Ic0269d0db10624925e7bcdbf0e33ae87b84a9cf2
2017-07-21 07:08:54 +00:00
roles:
- { role: redis,
tags: redis,
when: enable_redis | bool }
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
- name: Apply role mariadb
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- mariadb
- '&enable_mariadb_True'
Refactor haproxy config (split by service) V2.0 Having all services in one giant haproxy file makes altering configuration for a service both painful and dangerous. Each service should be configured with a simple set of variables and rendered with a single unified template. Available are two new templates: * haproxy_single_service_listen.cfg.j2: close to the original style, but only one service per file * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax for separated frontend and backend For now the default will be the single listen block, for ease of transition. Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
2018-06-19 00:43:35 -05:00
roles:
- { role: mariadb,
tags: mariadb,
when: enable_mariadb | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role memcached
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- memcached
- '&enable_memcached_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Use memcache for consoleauth and horizon Unfortunately there was no was to avoid memcache for consoleauth, so we might as well take advantage of it for Horizon as well. Change-Id: Idd338a025b031f6b50fe0c9f03c2c8d862f9d4c0 Closes-Bug: #1504606 Closes-Bug: #1504800
2015-10-15 08:54:36 +00:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: memcached,
tags: [memcache, memcached],
when: enable_memcached | bool }
Use memcache for consoleauth and horizon Unfortunately there was no was to avoid memcache for consoleauth, so we might as well take advantage of it for Horizon as well. Change-Id: Idd338a025b031f6b50fe0c9f03c2c8d862f9d4c0 Closes-Bug: #1504606 Closes-Bug: #1504800
2015-10-15 08:54:36 +00:00
Add role to deploy prometheus This patch adds the ansible role to deploy the prometheus service which can be used to collect performance metrics accross the environment Partially-Implements: blueprint prometheus Change-Id: I908b9c9dad63ab5c9b80be1e3a80a4fc8191cb9e
2017-07-17 15:59:05 +00:00
- name: Apply role prometheus
gather_facts: false
hosts:
- prometheus
- prometheus-node-exporter
- prometheus-mysqld-exporter
- prometheus-haproxy-exporter
Use the children group for site.yml 1. Use the children group for site.yml 2. Add some missing groups Change-Id: I01d686368b11a105a8965cf987d23772ecbf97de
2020-07-05 21:48:38 +08:00
- prometheus-memcached-exporter
Add cAdvisor for Prometheus monitoring cAdvisor (Container Advisor) provides metrics on resource usage and performance characteristics of running containers. This change deploys a cadvisor container and configures prometheus to scrape data from it. Change-Id: I55dd4fee954f9be68efda397746861ddaaa0a565 Partially-Implements: blueprint prometheus
2018-04-11 09:23:39 -04:00
- prometheus-cadvisor
[prometheus] Support the prometheus openstack exporter This patch implements the initial support for the openstack-exporter[0] in the kolla-ansible prometheus monitoring system. The configuration and prechecks are reused from the other exporters and a new template is provided for generating a os-client-config file required by the exporter. The default scrape interval is 60 seconds, but it can be extended via a configuration option. [0] https://github.com/Linaro/openstack-exporter Change-Id: I4a34c4bb56e74b5cd544972cbd6540d9acb6e4a1
2019-01-16 18:37:16 -03:00
- prometheus-alertmanager
- prometheus-openstack-exporter
Support the prometheus elasticsearch exporter This patch implements the support for the elasticsearch-exporter in kolla-ansible The configuration and prechecks are reused from the other exporters Depends-On: Id138f12e10102a6dd2cd8d84f2cc47aa29af3972 Change-Id: Iae0eac0179089f159804490bf71f1cf2c38dde54
2019-03-05 16:21:08 +03:00
- prometheus-elasticsearch-exporter
Adding Prometheus blackbox exporter This commit follows up the work in Kolla to provide deploy and configure the Prometheus blackbox exporter. An example blackbox-exporter module has been added (disabled by default) called os_endpoint. This allows for the probing of endpoints over HTTP and HTTPS. This can be used to monitor that OpenStack endpoints return a status code of either 200 or 300, and the word 'versions' in the payload. This change introduces a new variable `prometheus_blackbox_exporter_endpoints`. Currently no defaults are specified because the configuration is heavily dependent on the deployment. Co-authored-by: Jack Heskett <Jack.Heskett@gresearch.co.uk> Change-Id: I36ad4961078d90e2fd70c9a3368f5157d6fd89cd
2019-09-11 11:35:23 +01:00
- prometheus-blackbox-exporter
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_prometheus_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add role to deploy prometheus This patch adds the ansible role to deploy the prometheus service which can be used to collect performance metrics accross the environment Partially-Implements: blueprint prometheus Change-Id: I908b9c9dad63ab5c9b80be1e3a80a4fc8191cb9e
2017-07-17 15:59:05 +00:00
roles:
- { role: prometheus,
tags: prometheus,
when: enable_prometheus | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role iscsi
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add iscsid/tgtd specific parameters to Kolla infrastructure This partially implements iscsi and lvm2 support for cinder in Kolla. Add integration with Kolla infrastructure. Change-Id: I5b7d59163518080f38aec0c00617440de0763f1d Implements: blueprint iscsi-lvm2-docker
2016-03-31 10:40:55 -04:00
- iscsid
- tgtd
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_iscsid_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add iscsid/tgtd specific parameters to Kolla infrastructure This partially implements iscsi and lvm2 support for cinder in Kolla. Add integration with Kolla infrastructure. Change-Id: I5b7d59163518080f38aec0c00617440de0763f1d Implements: blueprint iscsi-lvm2-docker
2016-03-31 10:40:55 -04:00
roles:
- { role: iscsi,
tags: iscsi,
Cinder cannot use external non-LVM iSCSI storage Currently Cinder enables iscsid service only when LVM is choosen as backend. This fix will allow to specify external iSCSI storage via configuration add-on and to run iscsid independently of LVM settings. Change-Id: Iaae0f8025534e5ab1c5f9d5e812a7d41129915ef Closes-Bug: 1614125
2016-08-17 18:07:10 +03:00
when: enable_iscsid | bool }
Add iscsid/tgtd specific parameters to Kolla infrastructure This partially implements iscsi and lvm2 support for cinder in Kolla. Add integration with Kolla infrastructure. Change-Id: I5b7d59163518080f38aec0c00617440de0763f1d Implements: blueprint iscsi-lvm2-docker
2016-03-31 10:40:55 -04:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role multipathd
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add multipathing support to docker container Due some cinder drivers need multipathing support like this one http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html This PS will allow to run these additional drivers when using Kolla. Implements: blueprint multipath-support Change-Id: Id6cf29f984c92773bbfc2f95daea573a74701648
2016-07-08 13:34:04 -03:00
- multipathd
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_multipathd_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add multipathing support to docker container Due some cinder drivers need multipathing support like this one http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html This PS will allow to run these additional drivers when using Kolla. Implements: blueprint multipath-support Change-Id: Id6cf29f984c92773bbfc2f95daea573a74701648
2016-07-08 13:34:04 -03:00
roles:
- { role: multipathd,
tags: multipathd,
when: enable_multipathd | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role rabbitmq
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- rabbitmq
- '&enable_rabbitmq_True'
Initial commit for adding ansible support This adds a very basic structure to begin supporting ansible in Kolla. Ansible can support complete idempotency, but wrapping docker-compose does not allow idempotency at this time. These playbooks will be extended to compensate for that in future patches. Change-Id: I1c9e8d32321e2733f5a9b752edf74b4fe90317ed
2015-03-28 17:16:24 -05:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: rabbitmq,
tags: rabbitmq,
Add a new 'outward' rabbitmq instance Certain services such as Murano and trove require access to a rabbitmq instance from tenant networks. [0] Exposing the internal rabbitmq to end users is a security hole, hence there are two options, 1) use vhosts in the existing rabbitmq, or two a separate rabbitmq instances. Given the importance of rabbitmq to the OpenStack deployment, we have decided to go with a separate instance. Refer to [1] for more detail on the various options. This change makes the rabbitmq role generic so that it can be reused, in this case to start 'outward_rabbitmq'. It needs to be exposed via haproxy both for network isolation and also because this is what Murano configuration requires. Follow on patches will be added to add a vhost in this outward instance for Murano and other services which require access. Based on the original work by bdaca[2] [0] http://murano.readthedocs.io/en/stable-liberty/intro/architecture.html [1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109091.html [2] https://review.openstack.org/#/c/374525 Change-Id: Ib2bcc7ed4bf4f883a7cd1dfad3db89201e3cfd8d Partial-Bug: #1620374 Depends-On: I020eb6219f89a310451becde41f6f1c7f54baadd Co-Authored-By: Bartłomiej Daca <bartek.daca@gmail.com>
2017-04-05 16:57:35 +01:00
role_rabbitmq_cluster_cookie: '{{ rabbitmq_cluster_cookie }}',
role_rabbitmq_cluster_port: '{{ rabbitmq_cluster_port }}',
role_rabbitmq_epmd_port: '{{ rabbitmq_epmd_port }}',
role_rabbitmq_groups: rabbitmq,
role_rabbitmq_management_port: '{{ rabbitmq_management_port }}',
Add configurable rabbitmq monitoring user As an operator I want to be able to monitor the status of RabbitMQ by collecting metrics such as queue length, message rates (globally and per channel), and information about resource usage on the host, such as memory use, open file descriptors and the state of the cluster. Whilst it is possible to gather all of this information using the OpenStack RabbitMQ user configured by Kolla Ansible, this user has write access to the OpenStack vhost. This feature adds a monitoring user which has access to all of the information described above, but does not have write access. An example of a service which may use the monitoring user is the RabbitMQ plugin for the Monasca Agent. As not all users will configure monitoring, by default the monitoring user is disabled. To create it, the user should override the rabbitmq_monitoring_user variable. Implements: blueprint add-monitoring-user-for-rabbit Change-Id: Ie895ddc59dda1c38faab6305163d9bed6710ff9d
2017-11-02 13:32:49 +00:00
role_rabbitmq_monitoring_password: '{{ rabbitmq_monitoring_password }}',
role_rabbitmq_monitoring_user: '{{ rabbitmq_monitoring_user }}',
Add a new 'outward' rabbitmq instance Certain services such as Murano and trove require access to a rabbitmq instance from tenant networks. [0] Exposing the internal rabbitmq to end users is a security hole, hence there are two options, 1) use vhosts in the existing rabbitmq, or two a separate rabbitmq instances. Given the importance of rabbitmq to the OpenStack deployment, we have decided to go with a separate instance. Refer to [1] for more detail on the various options. This change makes the rabbitmq role generic so that it can be reused, in this case to start 'outward_rabbitmq'. It needs to be exposed via haproxy both for network isolation and also because this is what Murano configuration requires. Follow on patches will be added to add a vhost in this outward instance for Murano and other services which require access. Based on the original work by bdaca[2] [0] http://murano.readthedocs.io/en/stable-liberty/intro/architecture.html [1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109091.html [2] https://review.openstack.org/#/c/374525 Change-Id: Ib2bcc7ed4bf4f883a7cd1dfad3db89201e3cfd8d Partial-Bug: #1620374 Depends-On: I020eb6219f89a310451becde41f6f1c7f54baadd Co-Authored-By: Bartłomiej Daca <bartek.daca@gmail.com>
2017-04-05 16:57:35 +01:00
role_rabbitmq_password: '{{ rabbitmq_password }}',
role_rabbitmq_port: '{{ rabbitmq_port }}',
role_rabbitmq_user: '{{ rabbitmq_user }}',
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
when: enable_rabbitmq | bool }
Add auth role to ansible Add a auth role so ansible can deploy keystone. Change-Id: I3f41fe150654451aae6271cce59ddeb807945043
2015-05-02 22:45:36 +08:00
Add a new 'outward' rabbitmq instance Certain services such as Murano and trove require access to a rabbitmq instance from tenant networks. [0] Exposing the internal rabbitmq to end users is a security hole, hence there are two options, 1) use vhosts in the existing rabbitmq, or two a separate rabbitmq instances. Given the importance of rabbitmq to the OpenStack deployment, we have decided to go with a separate instance. Refer to [1] for more detail on the various options. This change makes the rabbitmq role generic so that it can be reused, in this case to start 'outward_rabbitmq'. It needs to be exposed via haproxy both for network isolation and also because this is what Murano configuration requires. Follow on patches will be added to add a vhost in this outward instance for Murano and other services which require access. Based on the original work by bdaca[2] [0] http://murano.readthedocs.io/en/stable-liberty/intro/architecture.html [1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109091.html [2] https://review.openstack.org/#/c/374525 Change-Id: Ib2bcc7ed4bf4f883a7cd1dfad3db89201e3cfd8d Partial-Bug: #1620374 Depends-On: I020eb6219f89a310451becde41f6f1c7f54baadd Co-Authored-By: Bartłomiej Daca <bartek.daca@gmail.com>
2017-04-05 16:57:35 +01:00
- name: Apply role rabbitmq (outward)
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- outward-rabbitmq
- '&enable_outward_rabbitmq_True'
Add a new 'outward' rabbitmq instance Certain services such as Murano and trove require access to a rabbitmq instance from tenant networks. [0] Exposing the internal rabbitmq to end users is a security hole, hence there are two options, 1) use vhosts in the existing rabbitmq, or two a separate rabbitmq instances. Given the importance of rabbitmq to the OpenStack deployment, we have decided to go with a separate instance. Refer to [1] for more detail on the various options. This change makes the rabbitmq role generic so that it can be reused, in this case to start 'outward_rabbitmq'. It needs to be exposed via haproxy both for network isolation and also because this is what Murano configuration requires. Follow on patches will be added to add a vhost in this outward instance for Murano and other services which require access. Based on the original work by bdaca[2] [0] http://murano.readthedocs.io/en/stable-liberty/intro/architecture.html [1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109091.html [2] https://review.openstack.org/#/c/374525 Change-Id: Ib2bcc7ed4bf4f883a7cd1dfad3db89201e3cfd8d Partial-Bug: #1620374 Depends-On: I020eb6219f89a310451becde41f6f1c7f54baadd Co-Authored-By: Bartłomiej Daca <bartek.daca@gmail.com>
2017-04-05 16:57:35 +01:00
roles:
- { role: rabbitmq,
tags: rabbitmq,
project_name: outward_rabbitmq,
role_rabbitmq_cluster_cookie: '{{ outward_rabbitmq_cluster_cookie }}',
role_rabbitmq_cluster_port: '{{ outward_rabbitmq_cluster_port }}',
role_rabbitmq_epmd_port: '{{ outward_rabbitmq_epmd_port }}',
role_rabbitmq_groups: outward-rabbitmq,
role_rabbitmq_management_port: '{{ outward_rabbitmq_management_port }}',
role_rabbitmq_password: '{{ outward_rabbitmq_password }}',
role_rabbitmq_port: '{{ outward_rabbitmq_port }}',
role_rabbitmq_user: '{{ outward_rabbitmq_user }}',
when: enable_outward_rabbitmq | bool }
Add qdrouterd role for messaging infrastructure component Adding the role needed to run the qdrouterd as an infrastructure component which provides a messaging backend for the oslo.messaging AMQP 1.0 driver. The qdrouterd will provide direct messaging capabilities for the RPC messaging pattern in support of hybrid messaging deployments. Implements: blueprint qdrouterd-role Change-Id: I74c654b3c70f61f81c2c7efa87f076a62a4a2dd8
2017-05-31 08:50:54 -04:00
- name: Apply role qdrouterd
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- qdrouterd
- '&enable_qdrouterd_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add qdrouterd role for messaging infrastructure component Adding the role needed to run the qdrouterd as an infrastructure component which provides a messaging backend for the oslo.messaging AMQP 1.0 driver. The qdrouterd will provide direct messaging capabilities for the RPC messaging pattern in support of hybrid messaging deployments. Implements: blueprint qdrouterd-role Change-Id: I74c654b3c70f61f81c2c7efa87f076a62a4a2dd8
2017-05-31 08:50:54 -04:00
roles:
- { role: qdrouterd,
tags: qdrouterd,
when: enable_qdrouterd | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role etcd
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- etcd
- '&enable_etcd_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add etcd ansible role Change-Id: If8351ab3000006323a05924e907f1e3745768304 Co-Authored-By: zhubingbing <zhubingbing10@gmail.com>> Partially-implements: bp kuryr-docker-plugin
2016-09-02 00:48:01 -04:00
roles:
- { role: etcd,
tags: etcd,
when: enable_etcd | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role keystone
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- keystone
- '&enable_keystone_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add auth role to ansible Add a auth role so ansible can deploy keystone. Change-Id: I3f41fe150654451aae6271cce59ddeb807945043
2015-05-02 22:45:36 +08:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: keystone,
tags: keystone,
when: enable_keystone | bool }
Ansible Glance support Adds support for glance in ansible Partially-Implements: blueprint ansible-service Change-Id: I2d162e79f85877116b0e33b1843de6ccb62a445a
2015-07-04 12:47:45 +00:00
Register Elasticsearch in Keystone This makes it possible for services to fetch the Elasticsearch endpoint from Keystone. It is useful for both operators and Monasca Tempest. Change-Id: Id60298582496a8959e82b970676669ca17e2e9d4
2020-07-31 09:28:15 +00:00
- name: Apply role elasticsearch
gather_facts: false
hosts:
- elasticsearch
- '&enable_elasticsearch_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: elasticsearch,
tags: elasticsearch,
when: enable_elasticsearch | bool }
- name: Apply role kibana
gather_facts: false
hosts:
- kibana
- '&enable_kibana_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: kibana,
tags: kibana,
when: enable_kibana | bool }
Add support for deploying Kafka Projects which may use Kafka include Monasca and Oslo messaging. Initially it will be possible to deploy a single Kafka cluster which may be shared among clients. Support for running multiple Kafka clusters may be added in a future change. This change also configures logging for Kafka server, state-change and controller logs. Partially-Implements: blueprint monasca-roles Change-Id: Iab8d200c2450238f3c0c708d1f4184490f6e6284
2018-02-26 12:02:19 +00:00
- name: Apply role kafka
gather_facts: false
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
hosts:
- kafka
- '&enable_kafka_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add support for deploying Kafka Projects which may use Kafka include Monasca and Oslo messaging. Initially it will be possible to deploy a single Kafka cluster which may be shared among clients. Support for running multiple Kafka clusters may be added in a future change. This change also configures logging for Kafka server, state-change and controller logs. Partially-Implements: blueprint monasca-roles Change-Id: Iab8d200c2450238f3c0c708d1f4184490f6e6284
2018-02-26 12:02:19 +00:00
roles:
- { role: kafka,
tags: kafka,
when: enable_kafka | bool }
Support deploying an Apache Storm cluster Storm is required for running the Monasca thresholder component for generating alerts. Change-Id: I5e1ef74dc55a787293abbb3e629b5ab1ce5f4bbb Partially-Implements: blueprint monasca-roles
2018-06-11 16:50:01 +01:00
- name: Apply role storm
update gather_facts to false for storm add gather_facts to false to avoid duplicated Change-Id: I633fc9042e7df24f5cdf3a62fd7ec619270469d5 Closes-Bug: #1806443
2018-11-17 14:42:38 -05:00
gather_facts: false
Support deploying storm worker and storm nimbus separately This allows storm worker and nimbus services to be deployed on separate hosts. Change-Id: Icb990d289fbfb4d8f782c255fc50d092964384f7
2018-11-06 14:54:20 +00:00
hosts:
- storm-worker
- storm-nimbus
Skip storm play when not enabled Minor scalability improvement, not currently applied to storm. Change-Id: I928d362067c52c3113bc0fbd3ae4b9be1810b7e5 TrivialFix
2020-06-26 14:42:16 +01:00
- '&enable_storm_True'
Support deploying an Apache Storm cluster Storm is required for running the Monasca thresholder component for generating alerts. Change-Id: I5e1ef74dc55a787293abbb3e629b5ab1ce5f4bbb Partially-Implements: blueprint monasca-roles
2018-06-11 16:50:01 +01:00
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: storm,
tags: storm,
when: enable_storm | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role swift
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Remove vip for rabbitmq Adjust all the configs to list all the rabbitmq hosts rather than running rabbitmq through the VIP. This is made possible by clusterer which has already merged. Change-Id: I5db48f5f10ec68f4c8863a29bc13984f6845a4f9 Partially-Implements: blueprint rabbitmq-clusterer
2015-10-16 07:58:34 +00:00
- swift-account-server
- swift-container-server
- swift-object-server
- swift-proxy-server
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_swift_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Implement Ansible role for Swift This currently deploys the core services for a working Swift which are account/container/object/proxy. I've included some basic docs in docs/swift-related.rst, which gives usage instructions and more context on this patch. These are really to give an overview of the state of Swift in Kolla as of now, so unless there's some major inaccuracy there please don't nitpick it. Change-Id: Id0c54be3e24c46459c40b16b7020f05bddbe1b19 Implements: blueprint ansible-swift
2015-08-18 14:05:54 +00:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: swift,
tags: swift,
when: enable_swift | bool }
Implement Ansible role for Swift This currently deploys the core services for a working Swift which are account/container/object/proxy. I've included some basic docs in docs/swift-related.rst, which gives usage instructions and more context on this patch. These are really to give an overview of the state of Swift in Kolla as of now, so unless there's some major inaccuracy there please don't nitpick it. Change-Id: Id0c54be3e24c46459c40b16b7020f05bddbe1b19 Implements: blueprint ansible-swift
2015-08-18 14:05:54 +00:00
Add support for Ceph RadosGW integration * Register Swift-compatible endpoints in Keystone * Load balance across RadosGW API servers using HAProxy The support is exercised in the cephadm CI jobs, but since RGW is not currently enabled via cephadm, it is not yet tested. https://docs.ceph.com/en/latest/radosgw/keystone/ Implements: blueprint ceph-rgw Change-Id: I891c3ed4ed93512607afe65a42dd99596fd4dbf9
2021-02-19 13:39:06 +00:00
- name: Apply role ceph-rgw
gather_facts: false
hosts:
# NOTE(mgoddard): This is only used to register Keystone services, and
# can run on any host running kolla-toolbox.
- kolla-toolbox
- '&enable_ceph_rgw_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: ceph-rgw,
tags: ceph-rgw,
when: enable_ceph_rgw | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role glance
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- glance-api
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_glance_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Ansible Glance support Adds support for glance in ansible Partially-Implements: blueprint ansible-service Change-Id: I2d162e79f85877116b0e33b1843de6ccb62a445a
2015-07-04 12:47:45 +00:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: glance,
tags: glance,
when: enable_glance | bool }
Ansible Nova w/ libvirt support Initial support for Nova in Ansible Partially-Implements: blueprint ansible-service Change-Id: I4b0a74bd3e5daa5664f5e1e622bfb40c3285949e
2015-07-12 03:02:33 +00:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role ironic
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Ironic should be started before nova-ironic-compute nova-ironic-compute will try to connect ironic-api service. So ironic should be started first. TrivialFix Change-Id: I23ba5724d86e3b7a06f7f7d112ee1ac84a2cda03
2016-10-18 10:58:48 +08:00
- ironic-api
- ironic-conductor
- ironic-inspector
- ironic-pxe
Fix play hosts for ironic, monasca, neutron, nova Some plays were not applied to all groups referenced by the services they deploy. In most cases this works fine, but if the default inventory is modified this may cause problems where containers are not deployed to hosts in the missing groups, if they are not a member of other groups that the play is targeted to. This change syncs up the play hosts for all services. Closes-Bug: #1889387 Change-Id: I6b92d8e53a29b06a065e0611840140d09c8a6695
2020-08-03 09:50:36 +01:00
- ironic-ipxe
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_ironic_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Ironic should be started before nova-ironic-compute nova-ironic-compute will try to connect ironic-api service. So ironic should be started first. TrivialFix Change-Id: I23ba5724d86e3b7a06f7f7d112ee1ac84a2cda03
2016-10-18 10:58:48 +08:00
roles:
- { role: ironic,
tags: ironic,
when: enable_ironic | bool }
Fix booting from volume failure Booting from volume require cinder's ceph client secret now. Move cinder before nova in site.yml, because nova depends on cinder ceph client key now. Change-Id: I01c9ed80843d98305b8963894c4917c21a35d3ac Closes-Bug: #1670676
2017-03-07 22:03:50 +08:00
- name: Apply role cinder
gather_facts: false
hosts:
- cinder-api
- cinder-backup
- cinder-scheduler
- cinder-volume
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_cinder_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Fix booting from volume failure Booting from volume require cinder's ceph client secret now. Move cinder before nova in site.yml, because nova depends on cinder ceph client key now. Change-Id: I01c9ed80843d98305b8963894c4917c21a35d3ac Closes-Bug: #1670676
2017-03-07 22:03:50 +08:00
roles:
- { role: cinder,
tags: cinder,
when: enable_cinder | bool }
Split placement from nova Depends-On: https://review.openstack.org/#/c/642958 Depends-On: https://review.openstack.org/642984 Change-Id: If795a9eb3ec92f75867ce3f755d6b832eba31af9
2018-10-26 18:13:48 +02:00
- name: Apply role placement
gather_facts: false
hosts:
- placement-api
- '&enable_placement_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: placement,
tags: placement,
when: enable_placement | bool }
Support multiple nova cells This patch adds initial support for deploying multiple Nova cells. Splitting a nova-cell role out from the Nova role allows a more granular approach to deploying and configuring Nova services. A new enable_cells flag has been added that enables the support of multiple cells via the introduction of a super conductor in addition to cell-specific conductors. When this flag is not set (the default), nova is configured in the same manner as before - with a single conductor. The nova role now deploys the global services: * nova-api * nova-scheduler * nova-super-conductor (if enable_cells is true) The nova-cell role handles services specific to a cell: * nova-compute * nova-compute-ironic * nova-conductor * nova-libvirt * nova-novncproxy * nova-serialproxy * nova-spicehtml5proxy * nova-ssh This patch does not support using a single cell controller for managing more than one cell. Support for sharing a cell controller will be added in a future patch. This patch should be backwards compatible and is tested by existing CI jobs. A new CI job has been added that tests a multi-cell environment. ceph-mon has been removed from the play hosts list as it is not necessary - delegate_to does not require the host to be in the play. Documentation will be added in a separate patch. Partially Implements: blueprint support-nova-cells Co-Authored-By: Mark Goddard <mark@stackhpc.com> Change-Id: I810aad7d49db3f5a7fd9a2f0f746fd912fe03917
2019-08-19 15:52:46 +01:00
# Nova deployment is more complicated than other services, so is covered in its
# own playbook.
- import_playbook: nova.yml
Ansible Neutron support Add initial Ansible support for Neutron Change-Id: Idad011945bff914535d1ac0eb09cc9d3b0882fbe Partially-Implements: blueprint ansible-service
2015-07-13 07:32:29 +00:00
Split Openvswitch into own role Creates Openvswitch role and splits openvswitch from Neutron role to enable third party networking solutions that use Openvswitch or customize Openvswitch. For example Openvswitch with dpdk or OpenDaylight. Change-Id: I5a41c42c5ec0a5e6999b2570ddac0f5efc3102ee Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-Implements: blueprint opendaylight-support
2017-03-31 10:42:02 -07:00
- name: Apply role openvswitch
Add gather_facts to ovs roles Add gather_facts: false to ovs roles to avoid Ansible gathering facts twice. Change-Id: I3a26ac40cd6e4a9c0e16b668bae577a795a1e100 Closes-Bug: #1746396
2018-01-31 10:56:57 +08:00
gather_facts: false
Split Openvswitch into own role Creates Openvswitch role and splits openvswitch from Neutron role to enable third party networking solutions that use Openvswitch or customize Openvswitch. For example Openvswitch with dpdk or OpenDaylight. Change-Id: I5a41c42c5ec0a5e6999b2570ddac0f5efc3102ee Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-Implements: blueprint opendaylight-support
2017-03-31 10:42:02 -07:00
hosts:
- openvswitch
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_openvswitch_True_enable_ovs_dpdk_False'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Split Openvswitch into own role Creates Openvswitch role and splits openvswitch from Neutron role to enable third party networking solutions that use Openvswitch or customize Openvswitch. For example Openvswitch with dpdk or OpenDaylight. Change-Id: I5a41c42c5ec0a5e6999b2570ddac0f5efc3102ee Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-Implements: blueprint opendaylight-support
2017-03-31 10:42:02 -07:00
roles:
- { role: openvswitch,
tags: openvswitch,
introduce playbook to ovs with dpdk - This change creates a new role to support deploying ovs with dpdk. - This change introduces an enable_ovs_dpdk variable to enable ovs with dpdk as part of the deploy action. - This change extends the ovs-dpdkctl.sh tool to correctly deploy ovs-dpdk on Ubuntu and CentOS hosts. - This change extends the cleanup-host tool to correctly uninstall ovs-dpdkctl.sh tool and its systemd files if present on the host. - This change automatically configures userspace kernel drivers. partial-implementes: bp/ovs-dpdk Change-Id: I55858d81df437e8258705b75426f61ab9b907c7d
2017-04-06 13:21:09 +00:00
when: "(enable_openvswitch | bool) and not (enable_ovs_dpdk | bool)"}
- name: Apply role ovs-dpdk
Add gather_facts to ovs roles Add gather_facts: false to ovs roles to avoid Ansible gathering facts twice. Change-Id: I3a26ac40cd6e4a9c0e16b668bae577a795a1e100 Closes-Bug: #1746396
2018-01-31 10:56:57 +08:00
gather_facts: false
introduce playbook to ovs with dpdk - This change creates a new role to support deploying ovs with dpdk. - This change introduces an enable_ovs_dpdk variable to enable ovs with dpdk as part of the deploy action. - This change extends the ovs-dpdkctl.sh tool to correctly deploy ovs-dpdk on Ubuntu and CentOS hosts. - This change extends the cleanup-host tool to correctly uninstall ovs-dpdkctl.sh tool and its systemd files if present on the host. - This change automatically configures userspace kernel drivers. partial-implementes: bp/ovs-dpdk Change-Id: I55858d81df437e8258705b75426f61ab9b907c7d
2017-04-06 13:21:09 +00:00
hosts:
- openvswitch
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_openvswitch_True_enable_ovs_dpdk_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
introduce playbook to ovs with dpdk - This change creates a new role to support deploying ovs with dpdk. - This change introduces an enable_ovs_dpdk variable to enable ovs with dpdk as part of the deploy action. - This change extends the ovs-dpdkctl.sh tool to correctly deploy ovs-dpdk on Ubuntu and CentOS hosts. - This change extends the cleanup-host tool to correctly uninstall ovs-dpdkctl.sh tool and its systemd files if present on the host. - This change automatically configures userspace kernel drivers. partial-implementes: bp/ovs-dpdk Change-Id: I55858d81df437e8258705b75426f61ab9b907c7d
2017-04-06 13:21:09 +00:00
roles:
- { role: ovs-dpdk,
tags: ovs-dpdk,
when: "(enable_openvswitch | bool) and (enable_ovs_dpdk | bool)"}
Split Openvswitch into own role Creates Openvswitch role and splits openvswitch from Neutron role to enable third party networking solutions that use Openvswitch or customize Openvswitch. For example Openvswitch with dpdk or OpenDaylight. Change-Id: I5a41c42c5ec0a5e6999b2570ddac0f5efc3102ee Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-Implements: blueprint opendaylight-support
2017-03-31 10:42:02 -07:00
OVN Support Implement OVN Ansible role. Implements: blueprint ovn-controller-neutron-ansible Depends-On: https://review.opendev.org/713422 Change-Id: Icd425dea85d58db49c838839d8f0b864b4a89a78
2019-12-20 11:35:35 +01:00
- name: Apply role ovn
gather_facts: false
hosts:
- ovn-controller
- ovn-nb-db
- ovn-northd
- ovn-sb-db
- '&enable_ovn_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: ovn,
tags: ovn,
when: enable_ovn | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role neutron
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Workaround ansible bug related to delegate_to Currently the delegate_to doesnt happen and the neutron role creation is attempted once on the first server and is skipped. The re-ordering of hosts in site.yml seems to make the first host to be one inside neutron-server group yielding the expected results. This patch needs to be re-visited as soon as a version of ansible is chosen that fixes the issues with delegate_to Co-Authored-By: Steven Dake <stdake@cisco.com> Co-Authored-By: Vikram Hosakote <vhosakot@cisco.com> Co-Authored-By: Nate Potter <nathaniel.potter@intel.com> Co-Authored-By: Ganesh Mahalingam <ganesh.mahalingam@intel.com> Change-Id: Ia712b323aa9d750d470a11ee899ab1b3054a903f Partial-Bug: #1546789
2016-03-31 04:04:27 -04:00
- neutron-server
Convert Neutron to thin containers *** Requires Docker 1.10 which is released *** Documentation will be in the next patch. You must set the following in your docker.service daemon control file for propogation to work: [Service] MountFlags=shared ====================================================================== Thanks to mount propagation in Docker 1.10 we can use thin containers finally! This is extremely useful to operators since now they can access the network namespaces from the hosts (outside the neutron container). But additionally it allows us to implement the VPN agent and other services easier. Neutron containers and the neutron role are brought into the standards of the new Kolla. Completely with drop-root and ansible formating updates. The ip_wrapper.py script was (thankfully) not needed so it has been removed from the repo. Partially-Implements: blueprint upgrade-neutron Change-Id: Iaf5555283240457e1912459f397a6393d886fba1
2016-01-26 19:50:43 +00:00
- neutron-dhcp-agent
- neutron-l3-agent
Add networking-baremetal configuration Partially-Implements: blueprint networking-baremetal Change-Id: I92b9505843f12692aef96764a314e5db49001a9b
2018-07-18 15:20:08 +00:00
- ironic-neutron-agent
Convert Neutron to thin containers *** Requires Docker 1.10 which is released *** Documentation will be in the next patch. You must set the following in your docker.service daemon control file for propogation to work: [Service] MountFlags=shared ====================================================================== Thanks to mount propagation in Docker 1.10 we can use thin containers finally! This is extremely useful to operators since now they can access the network namespaces from the hosts (outside the neutron container). But additionally it allows us to implement the VPN agent and other services easier. Neutron containers and the neutron role are brought into the standards of the new Kolla. Completely with drop-root and ansible formating updates. The ip_wrapper.py script was (thankfully) not needed so it has been removed from the repo. Partially-Implements: blueprint upgrade-neutron Change-Id: Iaf5555283240457e1912459f397a6393d886fba1
2016-01-26 19:50:43 +00:00
- neutron-metadata-agent
OVN Support Implement OVN Ansible role. Implements: blueprint ovn-controller-neutron-ansible Depends-On: https://review.opendev.org/713422 Change-Id: Icd425dea85d58db49c838839d8f0b864b4a89a78
2019-12-20 11:35:35 +01:00
- neutron-ovn-metadata-agent
Add neutron metering role into kolla-ansible Refer to neutron docs [1][2] [1]: https://docs.openstack.org/neutron/pike/admin/archives/adv-config.html#l3-metering-service-driver [2]: https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth Co-Authored-By: ZhijunWei <wzj334965317@outlook.com> Change-Id: I4a676d041bc2a86497cb139d9347365738b156df
2017-04-15 19:51:16 +08:00
- neutron-metering-agent
Fix play hosts for ironic, monasca, neutron, nova Some plays were not applied to all groups referenced by the services they deploy. In most cases this works fine, but if the default inventory is modified this may cause problems where containers are not deployed to hosts in the missing groups, if they are not a member of other groups that the play is targeted to. This change syncs up the play hosts for all services. Closes-Bug: #1889387 Change-Id: I6b92d8e53a29b06a065e0611840140d09c8a6695
2020-08-03 09:50:36 +01:00
- neutron-bgp-dragent
- neutron-infoblox-ipam-agent
Workaround ansible bug related to delegate_to Currently the delegate_to doesnt happen and the neutron role creation is attempted once on the first server and is skipped. The re-ordering of hosts in site.yml seems to make the first host to be one inside neutron-server group yielding the expected results. This patch needs to be re-visited as soon as a version of ansible is chosen that fixes the issues with delegate_to Co-Authored-By: Steven Dake <stdake@cisco.com> Co-Authored-By: Vikram Hosakote <vhosakot@cisco.com> Co-Authored-By: Nate Potter <nathaniel.potter@intel.com> Co-Authored-By: Ganesh Mahalingam <ganesh.mahalingam@intel.com> Change-Id: Ia712b323aa9d750d470a11ee899ab1b3054a903f Partial-Bug: #1546789
2016-03-31 04:04:27 -04:00
- compute
- manila-share
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_neutron_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Ansible Neutron support Add initial Ansible support for Neutron Change-Id: Idad011945bff914535d1ac0eb09cc9d3b0882fbe Partially-Implements: blueprint ansible-service
2015-07-13 07:32:29 +00:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: neutron,
tags: neutron,
when: enable_neutron | bool }
Add ansible support for Cinder Change-Id: I0694e5ad95aa7f924ebd3a29dff1f85e6307b7ae Partially-implements: blueprint ansible-cinder Partially-Implements: blueprint remove-abstraction-ansible Co-Authored-By: Ryan Hallisey <rhallise@redhat.com>
2015-08-04 07:39:22 +00:00
Move Kuryr to start after neutron has started ERROR kuryr EndpointNotFound: public endpoint for network service not found Closes-Bug: 1664351 Change-Id: I5dec28f42c362d2143a7e56f4187a28afa6e0142
2017-02-13 14:06:24 -08:00
- name: Apply role kuryr
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Move Kuryr to start after neutron has started ERROR kuryr EndpointNotFound: public endpoint for network service not found Closes-Bug: 1664351 Change-Id: I5dec28f42c362d2143a7e56f4187a28afa6e0142
2017-02-13 14:06:24 -08:00
hosts:
- compute
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_kuryr_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Move Kuryr to start after neutron has started ERROR kuryr EndpointNotFound: public endpoint for network service not found Closes-Bug: 1664351 Change-Id: I5dec28f42c362d2143a7e56f4187a28afa6e0142
2017-02-13 14:06:24 -08:00
roles:
- { role: kuryr,
tags: kuryr,
when: enable_kuryr | bool }
Add HAcluster Ansible role Adds HAcluster Ansible role. This role contains High Availability clustering solution composed of Corosync, Pacemaker and Pacemaker Remote. HAcluster is added as a helper role for Masakari which requires it for its host monitoring, allowing to provide HA to instances on a failed compute host. Kolla hacluster images merged in [1]. [1] https://review.opendev.org/#/c/668765/ Change-Id: I91e5c1840ace8f567daf462c4eb3ec1f0c503823 Implements: blueprint ansible-pacemaker-support Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com> Co-Authored-By: Mark Goddard <mark@stackhpc.com>
2019-07-10 11:38:14 -04:00
- name: Apply role hacluster
gather_facts: false
hosts:
- hacluster
- hacluster-remote
- '&enable_hacluster_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: hacluster,
tags: hacluster,
when: enable_hacluster | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role heat
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- heat-api
- heat-api-cfn
- heat-engine
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_heat_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add Ansible support for Heat This changes bootstrapping of the Heat container to bootstrap the Heat container with a heat domain user. This requires some work from bootstrap.yml to pass in several environment variables needed by the heat domain setup script. Co-Authored-By: Sam Yaple <sam@yaple.net> Change-Id: Iab05983754fa514835cb5ff54d775faa18773110 Partially-implements: blueprint ansible-heat
2015-08-02 12:26:30 -07:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: heat,
tags: heat,
when: enable_heat | bool }
Add Ansible support for Heat This changes bootstrapping of the Heat container to bootstrap the Heat container with a heat domain user. This requires some work from bootstrap.yml to pass in several environment variables needed by the heat domain setup script. Co-Authored-By: Sam Yaple <sam@yaple.net> Change-Id: Iab05983754fa514835cb5ff54d775faa18773110 Partially-implements: blueprint ansible-heat
2015-08-02 12:26:30 -07:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role horizon
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add memcached_servers to keystone_auth section The in-process cache for keystone tokens has been deprecated due to "incosistent results and high memory usage" with the expectation we switch to memcached_servers if we want to stay performant. Add memcache_servers [cache] section to the appropriate servers as the [DEFAULT]\memcache_servers options was deprecated. TrivialFix Related-Id: Ied2b88c8cefe5655a88d0c2f334de04e588fa75a Change-Id: Ic971bdddc0be3338b15924f7cc0f97d4a3ad2440
2016-03-19 16:42:26 +00:00
- horizon
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_horizon_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add ansible support for Horizon Change-Id: I6189ebd0151207b2e9807f1174c1f3eb4719d90a Implements: blueprint ansible-horizon Co-Authored-By: Harm Weites <harm@weites.com> Co-Authored-By: Sam Yaple <sam@yaple.net>
2015-08-10 14:08:59 -04:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: horizon,
tags: horizon,
when: enable_horizon | bool }
Add ansible support for Murano Deploy the core services for murano-api and murano-engine containers. Implements: bp ansible-murano Change-Id: Ibcc618665a3509465ba8f9249a417e8848087eef
2015-08-28 10:49:29 +01:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role murano
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- murano-api
- murano-engine
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_murano_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add ansible support for Murano Deploy the core services for murano-api and murano-engine containers. Implements: bp ansible-murano Change-Id: Ibcc618665a3509465ba8f9249a417e8848087eef
2015-08-28 10:49:29 +01:00
roles:
Small refactor for site.yml As the bug mentions this file is complex and has caused problems in the past. It will likely cause problems in the future. Change-Id: I28db6a38406ce0dd38340319eea7ef9134682007 Closes-Bug: #1512582
2015-11-03 05:47:47 +00:00
- { role: murano,
tags: murano,
when: enable_murano | bool }
Add Ansible support for Ironic Configuration based off upstream documentation here: http://docs.openstack.org/developer/ironic/deploy/install-guide.html A few notes: -ironic-api is not configured to use mod_wsgi -several places it's noted that discoverd is going away and needs to be replaced with ironic-inspector - (sqlite connection should be changed too) -currently enabling ironic reconfigures nova compute (driver and scheduler) as well as changes neutron network settings -a nice enhancement would be to configure the web console Required post-deployment configuration: Create the flat network to launch the instances: neutron net-create --tenant-id $TENANT_ID sharednet1 --shared \ --provider:network_type flat --provider:physical_network physnet1 neutron subnet-create sharednet1 $NETWORK_CIDR --name $SUBNET_NAME \ --ip-version=4 --gateway=$GATEWAY_IP --allocation-pool \ start=$START_IP,end=$END_IP --enable-dhcp And then the above ID is used to set cleaning_network_uuid in the neutron section of ironic.conf. Change-Id: I572e7ff1f23c4e57a2c50817cafe9269fd9950dd Implements: blueprint ironic-container
2015-08-28 11:26:40 -04:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role solum
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add solum ansible role Change-Id: I07f2df405574b55daa44fa381625e8be0c352607 Partially-implements: bp solum-ansible-role
2016-11-25 06:14:51 +08:00
- solum-api
- solum-worker
- solum-deployer
- solum-conductor
Use the children group for site.yml 1. Use the children group for site.yml 2. Add some missing groups Change-Id: I01d686368b11a105a8965cf987d23772ecbf97de
2020-07-05 21:48:38 +08:00
- solum-application-deployment
- solum-image-builder
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_solum_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add solum ansible role Change-Id: I07f2df405574b55daa44fa381625e8be0c352607 Partially-implements: bp solum-ansible-role
2016-11-25 06:14:51 +08:00
roles:
- { role: solum,
tags: solum,
when: enable_solum | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role magnum
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add Ansible support for Magnum Change-Id: Idb25ac4d3148c9b9400cf675ac2e47d35cce6224 Implements: blueprint ansible-magnum
2015-10-17 18:13:51 +02:00
- magnum-api
- magnum-conductor
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_magnum_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add Ansible support for Magnum Change-Id: Idb25ac4d3148c9b9400cf675ac2e47d35cce6224 Implements: blueprint ansible-magnum
2015-10-17 18:13:51 +02:00
roles:
- { role: magnum,
tags: magnum,
when: enable_magnum | bool }
Ansible files for mistral containers. Change-Id: Ifb55ff4a7ca70bc3d10fbb2ec067c245342d3288 Partially-implements: blueprint enable-mistral-container
2015-12-28 08:38:30 +09:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role mistral
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Ansible files for mistral containers. Change-Id: Ifb55ff4a7ca70bc3d10fbb2ec067c245342d3288 Partially-implements: blueprint enable-mistral-container
2015-12-28 08:38:30 +09:00
- mistral-api
- mistral-engine
- mistral-executor
Use the children group for site.yml 1. Use the children group for site.yml 2. Add some missing groups Change-Id: I01d686368b11a105a8965cf987d23772ecbf97de
2020-07-05 21:48:38 +08:00
- mistral-event-engine
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_mistral_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Ansible files for mistral containers. Change-Id: Ifb55ff4a7ca70bc3d10fbb2ec067c245342d3288 Partially-implements: blueprint enable-mistral-container
2015-12-28 08:38:30 +09:00
roles:
- { role: mistral,
tags: mistral,
when: enable_mistral | bool }
Add an ansible role for mongodb Change-Id: Ia6ac371845d1f2b545406d096b35a6d5f68be5f6 Implements: blueprint ansible-mongodb
2016-01-18 21:00:45 +00:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role sahara
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add sahara ansible role Change-Id: I75b58248bfc4e86cace75faa82526d55a9ebbdbf Partially-Implements: blueprint sahara-role
2016-08-04 17:20:20 +00:00
- sahara-api
- sahara-engine
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_sahara_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add sahara ansible role Change-Id: I75b58248bfc4e86cace75faa82526d55a9ebbdbf Partially-Implements: blueprint sahara-role
2016-08-04 17:20:20 +00:00
roles:
- { role: sahara,
tags: sahara,
when: enable_sahara | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role manila
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add ansible support for Manila Co-Authored-By: Marc Koderer <marc@koderer.com> Change-Id: I16bab281f2eca341b7a649f766bae5f2cf18a117 Partially-Implements: blueprint enable-manila-containers
2016-03-01 10:46:48 -05:00
- manila-api
Add manila-data service Change-Id: Ie82f1dd7773ef2cc2c6724ec0b5f78ebd79566ee Closes-Bug: #1635370
2016-10-20 17:19:47 -03:00
- manila-data
Add ansible support for Manila Co-Authored-By: Marc Koderer <marc@koderer.com> Change-Id: I16bab281f2eca341b7a649f766bae5f2cf18a117 Partially-Implements: blueprint enable-manila-containers
2016-03-01 10:46:48 -05:00
- manila-share
- manila-scheduler
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_manila_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add ansible support for Manila Co-Authored-By: Marc Koderer <marc@koderer.com> Change-Id: I16bab281f2eca341b7a649f766bae5f2cf18a117 Partially-Implements: blueprint enable-manila-containers
2016-03-01 10:46:48 -05:00
roles:
- { role: manila,
tags: manila,
when: enable_manila | bool }
Implement ceilometer ansible role Change-Id: I13c50a78b2dc7c98b720a4b2e7161104213bd295 Implements: bp ansible-ceilometer
2016-03-29 13:25:43 -04:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role gnocchi
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add gnocchi ansible role Partially-Implements: blueprint ansible-gnocchi Change-Id: I8dd0460bd21ac0a233fab0142ec7b6079459bdc2
2016-08-01 05:17:43 +00:00
- gnocchi-api
- gnocchi-metricd
- gnocchi-statsd
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_gnocchi_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add gnocchi ansible role Partially-Implements: blueprint ansible-gnocchi Change-Id: I8dd0460bd21ac0a233fab0142ec7b6079459bdc2
2016-08-01 05:17:43 +00:00
roles:
- { role: gnocchi,
tags: gnocchi,
when: enable_gnocchi | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role ceilometer
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Use its own host gruop for ceilometer Change-Id: I8dca3e04d12c7da97f23ff9a297b692f86bbc85b
2018-05-30 10:58:02 -04:00
- ceilometer-central
- ceilometer-notification
- ceilometer-compute
Add ceilometer_ipmi container into ceilometer role refer to [0] [0]: https://docs.openstack.org/ceilometer/latest/install/install-compute-rdo.html Co-Authored-By: zhulingjie <easyzlj@gmail.com> Change-Id: I4cda336dedb3d807b80d13bcc219268a8d667b4d
2018-04-29 13:15:02 +08:00
- ceilometer-ipmi
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_ceilometer_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Implement ceilometer ansible role Change-Id: I13c50a78b2dc7c98b720a4b2e7161104213bd295 Implements: bp ansible-ceilometer
2016-03-29 13:25:43 -04:00
roles:
- { role: ceilometer,
tags: ceilometer,
when: enable_ceilometer | bool }
implement Ansible Tempest role DocImpact Implments: blueprint ansible-tempest Change-Id: Iadd86d9d91438f056c433b9a2016f32587c92878
2016-05-26 20:58:03 +08:00
Support deploying the Monasca API Deploys the Monasca API with mod_wsgi + Apache. Co-Authored-By: Mark Goddard <mark@stackhpc.com> Partially-Implements: blueprint monasca-roles Change-Id: I3e03762217fbef1fb0cbff6239abb109cbec226b
2018-03-28 17:54:19 +01:00
- name: Apply role monasca
gather_facts: false
Support deploying the Monasca Agent The Monasca Agent collects metrics and in this change is deployed across the control plane. These metrics are collected into an OpenStack project. It supports configuring a small number of plugins, which can be extended in later commits. It also makes the Monasca Agent credentials available to other roles, such as the common role to allow forwarding logs to Monasca. Partially-Implements: blueprint monasca-roles Change-Id: I76b34fc5e1c76407a45fcf272268d5798b473ca2
2018-07-26 16:51:14 +01:00
hosts:
Fix play hosts for ironic, monasca, neutron, nova Some plays were not applied to all groups referenced by the services they deploy. In most cases this works fine, but if the default inventory is modified this may cause problems where containers are not deployed to hosts in the missing groups, if they are not a member of other groups that the play is targeted to. This change syncs up the play hosts for all services. Closes-Bug: #1889387 Change-Id: I6b92d8e53a29b06a065e0611840140d09c8a6695
2020-08-03 09:50:36 +01:00
- monasca-agent-collector
- monasca-agent-forwarder
- monasca-agent-statsd
Make the monasca support deploy separated Change-Id: I9fbde5e26c76d8fc78b51e12e7cb7baf66f8602a Closes-Bug: #1796366
2018-07-18 22:59:29 +08:00
- monasca-api
- monasca-grafana
- monasca-log-persister
- monasca-log-metrics
- monasca-thresh
- monasca-notification
- monasca-persister
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_monasca_True'
Support deploying the Monasca API Deploys the Monasca API with mod_wsgi + Apache. Co-Authored-By: Mark Goddard <mark@stackhpc.com> Partially-Implements: blueprint monasca-roles Change-Id: I3e03762217fbef1fb0cbff6239abb109cbec226b
2018-03-28 17:54:19 +01:00
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: monasca,
tags: monasca,
when: enable_monasca | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role aodh
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Make the aodh support deploy separated refer to [0] [0]: https://github.com/openstack/kolla-ansible/blob/master/ansible/inventory/multinode#L557 Change-Id: I17ac982ddcb6c63d5ca30623fc450464a69b9299 Closes-Bug: #1796366
2018-10-04 10:53:49 -04:00
- aodh-api
- aodh-evaluator
- aodh-listener
- aodh-notifier
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_aodh_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add aodh role Partially-Implements: blueprint ansible-aodh Change-Id: I9e20f4bf5e7d8f37f243ae15746e2b7bb49eb20c
2016-08-04 06:51:11 +00:00
roles:
- { role: aodh,
tags: aodh,
when: enable_aodh | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role barbican
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add Barbican ansible role Partially-Implements: blueprint barbican-ansible Change-Id: Id6be35b1d0527d5c38d4ea8576b233ebcc404718
2016-08-08 16:48:11 +00:00
- barbican-api
- barbican-keystone-listener
- barbican-worker
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_barbican_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add Barbican ansible role Partially-Implements: blueprint barbican-ansible Change-Id: Id6be35b1d0527d5c38d4ea8576b233ebcc404718
2016-08-08 16:48:11 +00:00
roles:
- { role: barbican,
tags: barbican,
when: enable_barbican | bool }
Add cyborg to kolla-ansible Because kolla-ansible not have cyborg so should add it. Implements: blueprint add-cyborg-to-kolla-ansible Depend-On: I497e67e3a754fccfd2ef5a82f13ccfaf890a6fcd Change-Id: I6f7ae86f855c5c64697607356d0ff3161f91b239
2018-12-02 21:17:07 +08:00
- name: Apply role cyborg
gather_facts: false
hosts:
Use the children group for site.yml 1. Use the children group for site.yml 2. Add some missing groups Change-Id: I01d686368b11a105a8965cf987d23772ecbf97de
2020-07-05 21:48:38 +08:00
- cyborg-api
- cyborg-agent
- cyborg-conductor
Add cyborg to kolla-ansible Because kolla-ansible not have cyborg so should add it. Implements: blueprint add-cyborg-to-kolla-ansible Depend-On: I497e67e3a754fccfd2ef5a82f13ccfaf890a6fcd Change-Id: I6f7ae86f855c5c64697607356d0ff3161f91b239
2018-12-02 21:17:07 +08:00
- '&enable_cyborg_True'
serial: '{{ serial|default("0") }}'
roles:
- { role: cyborg,
tags: cyborg,
when: enable_cyborg | bool }
Ansible-ize OpenStack Designate Implement ansible role to deploy designate and dependencies. The backend used is bind9. Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Co-Authored-By: Eduardo Gonzalez <dabarren@gmail.com> Depends-On: 6d0dc3e0f931c7c50b64a4659900cc50b0d860a2 Implements: blueprint ansible-designate Change-Id: I34d8126e0cd8d71d5ced9b62f3776cc354fbb549
2016-08-10 15:48:32 +10:00
- name: Apply role designate
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Ansible-ize OpenStack Designate Implement ansible role to deploy designate and dependencies. The backend used is bind9. Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Co-Authored-By: Eduardo Gonzalez <dabarren@gmail.com> Depends-On: 6d0dc3e0f931c7c50b64a4659900cc50b0d860a2 Implements: blueprint ansible-designate Change-Id: I34d8126e0cd8d71d5ced9b62f3776cc354fbb549
2016-08-10 15:48:32 +10:00
hosts:
- designate-api
- designate-central
Implement designate-producer service Depends-On: Ia22128e5ce4a717612af658d63258e78e52176ad Implements: blueprint designate-producer Change-Id: I98b5e99e8fcfe18fde442b317348ec261f4d2f99
2017-12-06 15:14:38 +08:00
- designate-producer
Ansible-ize OpenStack Designate Implement ansible role to deploy designate and dependencies. The backend used is bind9. Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Co-Authored-By: Eduardo Gonzalez <dabarren@gmail.com> Depends-On: 6d0dc3e0f931c7c50b64a4659900cc50b0d860a2 Implements: blueprint ansible-designate Change-Id: I34d8126e0cd8d71d5ced9b62f3776cc354fbb549
2016-08-10 15:48:32 +10:00
- designate-mdns
- designate-worker
- designate-sink
Add the missing hosts group for designate project refer to https://github.com/openstack/kolla-ansible/blob/master/ansible/inventory/multinode#L586 Change-Id: I3901c5c920b75879439f4945da59ea4288dd57a8 Co-Authored-By: chenqiaomin <chen.qiaomin@99cloud.net> Closes-Bug: #1736728
2017-12-06 21:52:38 +08:00
- designate-backend-bind9
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_designate_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Ansible-ize OpenStack Designate Implement ansible role to deploy designate and dependencies. The backend used is bind9. Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Co-Authored-By: Eduardo Gonzalez <dabarren@gmail.com> Depends-On: 6d0dc3e0f931c7c50b64a4659900cc50b0d860a2 Implements: blueprint ansible-designate Change-Id: I34d8126e0cd8d71d5ced9b62f3776cc354fbb549
2016-08-10 15:48:32 +10:00
roles:
- { role: designate,
tags: designate,
when: enable_designate | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role trove
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add trove role Add trove enable options and port configuration Add trove groups to ansible inventory Add defaults/main.yml Add bootstrap Ansible task Add config Ansible task Add deploy Ansible task Add pull Ansible task Add register Ansible task Add start Ansible task Add upgrade Ansible task Add reconfigure Ansible task Add templatized json and .conf files for trove Integrate trove with haproxy Reference installation configuration link:http://docs.openstack.org/mitaka/install-guide-rdo/trove-install.html Change-Id: I0bc6edbf2e495ce377f994f793bde979d5c55dbf Implements: blueprint ansible-trove
2016-08-12 18:43:02 +00:00
- trove-api
- trove-conductor
- trove-taskmanager
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_trove_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add trove role Add trove enable options and port configuration Add trove groups to ansible inventory Add defaults/main.yml Add bootstrap Ansible task Add config Ansible task Add deploy Ansible task Add pull Ansible task Add register Ansible task Add start Ansible task Add upgrade Ansible task Add reconfigure Ansible task Add templatized json and .conf files for trove Integrate trove with haproxy Reference installation configuration link:http://docs.openstack.org/mitaka/install-guide-rdo/trove-install.html Change-Id: I0bc6edbf2e495ce377f994f793bde979d5c55dbf Implements: blueprint ansible-trove
2016-08-12 18:43:02 +00:00
roles:
- { role: trove,
tags: trove,
when: enable_trove | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role watcher
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add Watcher ansible roles and templates Previous work on Watcher added the Docker images, this change adds the ansible configuration. There is support for HA, via haproxy to balance across the Watcher API hosts. There is also a hook into nova.conf to conditionally add Nova compute Host metrics via Ceilometer if Watcher is enabled. This defaults to enabled false. Change-Id: I8763528bb6ff12943b810212c71396d2d7cf6836 Partial-bug: #1598929 Partially-implements: bp watcher Signed-off-by: Dave Walker (Daviey) <email@daviey.com>
2016-07-05 09:47:21 +01:00
- watcher-api
- watcher-engine
- watcher-applier
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_watcher_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add Watcher ansible roles and templates Previous work on Watcher added the Docker images, this change adds the ansible configuration. There is support for HA, via haproxy to balance across the Watcher API hosts. There is also a hook into nova.conf to conditionally add Nova compute Host metrics via Ceilometer if Watcher is enabled. This defaults to enabled false. Change-Id: I8763528bb6ff12943b810212c71396d2d7cf6836 Partial-bug: #1598929 Partially-implements: bp watcher Signed-off-by: Dave Walker (Daviey) <email@daviey.com>
2016-07-05 09:47:21 +01:00
roles:
- { role: watcher,
tags: watcher,
when: enable_watcher | bool }
Add cloudkitty ansible role Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: Id83c852e32c3dd583e6128e888ac511634e8eabb Partially-Implements: blueprint cloudkitty
2016-08-01 02:27:39 +02:00
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role grafana
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Added grafana role Added ansible role to deploy grafana Added host group for grafana deployment Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: I3dec4e8586b6f65fa7de66a48506d1c79de2fe1e Partially-Implements: Blueprint performance-monitoring
2016-07-27 07:02:04 +00:00
- grafana
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_grafana_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Added grafana role Added ansible role to deploy grafana Added host group for grafana deployment Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: I3dec4e8586b6f65fa7de66a48506d1c79de2fe1e Partially-Implements: Blueprint performance-monitoring
2016-07-27 07:02:04 +00:00
roles:
- { role: grafana,
tags: grafana,
when: enable_grafana | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role cloudkitty
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add cloudkitty ansible role Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: Id83c852e32c3dd583e6128e888ac511634e8eabb Partially-Implements: blueprint cloudkitty
2016-08-01 02:27:39 +02:00
- cloudkitty-api
- cloudkitty-processor
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_cloudkitty_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add cloudkitty ansible role Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: Id83c852e32c3dd583e6128e888ac511634e8eabb Partially-Implements: blueprint cloudkitty
2016-08-01 02:27:39 +02:00
roles:
- { role: cloudkitty,
tags: cloudkitty,
when: enable_cloudkitty | bool }
Add Senlin Ansible role Change-Id: Ic941a396b5cd9abfb5e9941218e91b784f8bba0a Implements: bp senlin-container
2016-07-08 19:12:50 +02:00
Add freezer ansible role Co-Authored-By: caoyuan <cao.yuan@99cloud.net> Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: I419f7ceb219ea9643cfd225c130018f967ddd860 Partially-implements: bp freezer-ansible-role
2017-01-19 18:42:12 +08:00
- name: Apply role freezer
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Add freezer ansible role Co-Authored-By: caoyuan <cao.yuan@99cloud.net> Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: I419f7ceb219ea9643cfd225c130018f967ddd860 Partially-implements: bp freezer-ansible-role
2017-01-19 18:42:12 +08:00
hosts:
- freezer-api
Add freezer-scheduler hosts into site.yml freezer-scheduer container will run on freezer-scheduler hosts[0], but it missing in site.yml, when freezer-api and freezer-scheduler run on different hosts, it will failed. [0]: https://github.com/openstack/kolla-ansible/blob/master/ansible/inventory/multinode#L376 Change-Id: I1bd36c7c57345ee63cd153df8bd0603badf0d8a2
2018-05-30 10:30:33 -04:00
- freezer-scheduler
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_freezer_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add freezer ansible role Co-Authored-By: caoyuan <cao.yuan@99cloud.net> Co-Authored-By: zhubingbing <zhubingbing10@gmail.com> Change-Id: I419f7ceb219ea9643cfd225c130018f967ddd860 Partially-implements: bp freezer-ansible-role
2017-01-19 18:42:12 +08:00
roles:
- { role: freezer,
tags: freezer,
when: enable_freezer | bool }
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
- name: Apply role senlin
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Give plays in the playbooks a name Change-Id: I44c2668a8ebb6dd3201a6eb4e47284871380e6d7
2016-11-30 16:23:36 +01:00
hosts:
Add Senlin Ansible role Change-Id: Ic941a396b5cd9abfb5e9941218e91b784f8bba0a Implements: bp senlin-container
2016-07-08 19:12:50 +02:00
- senlin-api
Added senlin-conductor and senlin-health-manager Depends-On: https://review.opendev.org/692948/ Depends-On: https://review.opendev.org/692691/ Change-Id: I07827b896d36c3723697540fcff164224f6729af
2019-11-04 22:13:01 -08:00
- senlin-conductor
Add Senlin Ansible role Change-Id: Ic941a396b5cd9abfb5e9941218e91b784f8bba0a Implements: bp senlin-container
2016-07-08 19:12:50 +02:00
- senlin-engine
Added senlin-conductor and senlin-health-manager Depends-On: https://review.opendev.org/692948/ Depends-On: https://review.opendev.org/692691/ Change-Id: I07827b896d36c3723697540fcff164224f6729af
2019-11-04 22:13:01 -08:00
- senlin-health-manager
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_senlin_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add Senlin Ansible role Change-Id: Ic941a396b5cd9abfb5e9941218e91b784f8bba0a Implements: bp senlin-container
2016-07-08 19:12:50 +02:00
roles:
- { role: senlin,
tags: senlin,
when: enable_senlin | bool }
Support searchlight ansible role Searchlight is an Openstack search and index service, this patch implements the ansible role for searchlight. Implement blueprint: support-searchlight-deployment Change-Id: Ibf42d5b259a6740d6596041f896e1009657b7388
2016-10-18 16:36:05 +08:00
Add name for tacker playbook Change-Id: I5c9fc09097e061aef55dc92606be159b8bfa357e
2016-12-07 00:30:14 +08:00
- name: Apply role tacker
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Fix missing tacker-conductor service Tacker has included a new conductor service to manage mistral workflows for VIM monitoring. Without conductor, Tacker cannot create VIMs. This change reworks tacker to include tacker-conductor service. Depends-On: I52778e86e4f2c297ead8d4b09983e5e38ca88c70 Closes-Bug: #1710874 Change-Id: I6901e919887551bedc9dba8983ac904e8c48c9ce
2017-06-26 14:35:05 +02:00
hosts:
- tacker-server
- tacker-conductor
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_tacker_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Tacker NFV Ansible support Add Ansible configuration for Tacker NFV service Change-Id: I472d96e13a5270d1ee219c2f72f57d9c361f87a6 Partially-Implements: blueprint tacker-support
2016-11-15 18:51:52 +00:00
roles:
- { role: tacker,
tags: tacker,
when: enable_tacker | bool }
Implement octavia ansible role Change-Id: Ic72b49275627aff239b23e9862966923555a464f Implements: blueprint octavia-ansible-role
2016-11-30 16:45:00 +08:00
- name: Apply role octavia
Disable unneeded fact gathering We explicitly gather facts for all nodes up front in the playbook, so setup tasks for all other plays are unnecessary noise. Change-Id: I4bc152288752da780b5cb447b4ad3f7d49390dee
2017-02-24 11:59:15 +00:00
gather_facts: false
Implement octavia ansible role Change-Id: Ic72b49275627aff239b23e9862966923555a464f Implements: blueprint octavia-ansible-role
2016-11-30 16:45:00 +08:00
hosts:
- octavia-api
- octavia-health-manager
- octavia-housekeeping
- octavia-worker
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_octavia_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add lost roles field in octavia * the roles field is lost when implementing. This patch adds the field * add enable_octavia example in globas.yml file Change-Id: I94c33f78afafc903779c9f3bdb051fca39206211 Implements: blueprint octavia-ansible-role
2016-12-13 21:57:03 +08:00
roles:
- { role: octavia,
tags: octavia,
when: enable_octavia | bool }
Add zun ansible role Change-Id: I13cf03d6a97fb94dd7cb309e99a417ad101dc21a Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-implements: bp add-zun-ansible-role
2017-01-03 08:45:53 +00:00
- name: Apply role zun
gather_facts: false
hosts:
- zun-api
Fix the zun-wsproxy group missing in site.yml zun-wsproxy group is used in multinode[1], but it missing from site.yml this PS to fix this. [1]: https://github.com/openstack/kolla-ansible/blob/master/ansible/inventory/multinode#L676 Change-Id: I3b06f15dba5b6569202b038a28fb1a2728cffd25 Closes-Bug: #1799234
2018-10-22 22:16:43 +08:00
- zun-wsproxy
Add zun ansible role Change-Id: I13cf03d6a97fb94dd7cb309e99a417ad101dc21a Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-implements: bp add-zun-ansible-role
2017-01-03 08:45:53 +00:00
- zun-compute
Zun: Add zun-cni-daemon to compute node Zun has a new component "zun-cni-daemon" which should be deployed in every compute nodes. It is basically an implementation of CNI (Container Network Interface) that performs the neutron port binding. If users is using the capsule (pod) API, the recommended deployment option is using "cri" as capsule driver. This is basically to use a CRI runtime (i.e. CRI plugin for containerd) for supporting capsules (pods). A CRI runtime needs a CNI plugin which is what the "zun-cni-daemon" provides. The configuration is based on the Zun installation guide [1]. It consits of the following steps: * Configure the containerd daemon in the host. The "zun-compute" container will use grpc to communicate with this service. * Install the "zun-cni" binary at host. The containerd process will invoke this binary to call the CNI plugin. * Run a "zun-cni-daemon" container. The "zun-cni" binary will communicate with this container via HTTP. Relevant patches: Blueprint: https://blueprints.launchpad.net/zun/+spec/add-support-cri-runtime Install guide: https://review.opendev.org/#/c/707948/ Devstack plugin: https://review.opendev.org/#/c/705338/ Kolla image: https://review.opendev.org/#/c/708273/ [1] https://docs.openstack.org/zun/latest/install/index.html Depends-On: https://review.opendev.org/#/c/721044/ Change-Id: I9c361a99b355af27907cf80f5c88d97191193495
2020-02-17 16:45:33 +00:00
- zun-cni-daemon
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_zun_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add zun ansible role Change-Id: I13cf03d6a97fb94dd7cb309e99a417ad101dc21a Co-Authored-By: Mauricio Lima <mauriciolimab@gmail.com> Partially-implements: bp add-zun-ansible-role
2017-01-03 08:45:53 +00:00
roles:
- { role: zun,
tags: zun,
when: enable_zun | bool }
Add skydive service This patch introduces the ansible materials to deploy the skydive service, that can be used to monitor and troubleshoot networking in an openstack deployment. Implements: blueprint skydive-service Co-Authored-By: Nicolas Bouron <nicolas.bouron@gmail.com> Signed-off-by: Mathieu Rohon <mathieu.rohon@gmail.com> Change-Id: I53051a1b0c85380416288e17040a398b6efb62c0
2017-04-28 12:21:50 +02:00
- name: Apply role skydive
Skydive: fix facts retrieved two times Facts are retrieved a second time if skydive is enabled. This patch fix it. Change-Id: I4fc15daf59b093e4b29ff9f1fc703c8b2a65b238
2017-06-15 17:47:07 +02:00
gather_facts: false
Add skydive service This patch introduces the ansible materials to deploy the skydive service, that can be used to monitor and troubleshoot networking in an openstack deployment. Implements: blueprint skydive-service Co-Authored-By: Nicolas Bouron <nicolas.bouron@gmail.com> Signed-off-by: Mathieu Rohon <mathieu.rohon@gmail.com> Change-Id: I53051a1b0c85380416288e17040a398b6efb62c0
2017-04-28 12:21:50 +02:00
hosts:
- skydive-agent
- skydive-analyzer
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_skydive_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add skydive service This patch introduces the ansible materials to deploy the skydive service, that can be used to monitor and troubleshoot networking in an openstack deployment. Implements: blueprint skydive-service Co-Authored-By: Nicolas Bouron <nicolas.bouron@gmail.com> Signed-off-by: Mathieu Rohon <mathieu.rohon@gmail.com> Change-Id: I53051a1b0c85380416288e17040a398b6efb62c0
2017-04-28 12:21:50 +02:00
roles:
- { role: skydive,
tags: skydive,
when: enable_skydive | bool }
Add vitrage ansible role Co-Authored-By: caoyuan <cao.yuan@99cloud.net> Co-Authored-By: Eduardo Gonzalez <dabarren@gmail.com> Depends-on I7ffb991adbd05275e331401cd73fc84362084ebd Change-Id: I85afeb5dfce0bf6350a444000bdb885c6fe079c9 Partially-implements: blueprint vitrage-roles
2017-02-11 17:01:19 +00:00
- name: Apply role vitrage
gather_facts: false
hosts:
- vitrage-api
- vitrage-graph
- vitrage-notifier
- vitrage-ml
Add the missing hosts for vitrage refer to https://github.com/openstack/kolla-ansible/blob/master/ansible/inventory/multinode#L728 Change-Id: Ib6cd78cb2058a35f15b5affb98e0f63805b0edf3
2020-08-20 23:51:01 +08:00
- vitrage-persistor
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_vitrage_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Add vitrage ansible role Co-Authored-By: caoyuan <cao.yuan@99cloud.net> Co-Authored-By: Eduardo Gonzalez <dabarren@gmail.com> Depends-on I7ffb991adbd05275e331401cd73fc84362084ebd Change-Id: I85afeb5dfce0bf6350a444000bdb885c6fe079c9 Partially-implements: blueprint vitrage-roles
2017-02-11 17:01:19 +00:00
roles:
- { role: vitrage,
tags: vitrage,
when: enable_vitrage | bool }
Implement blazar ansible role Add ansible role to deploy blazar Add nova filters to allow use of blazar Change-Id: I6742ddc9a4736f256491dd0cfd31904fa8eb5652 Implements: blueprint blazar-ansible-role
2017-04-07 16:01:07 +01:00
- name: Apply role blazar
gather_facts: false
hosts:
- blazar-api
- blazar-manager
Scalability improvements for disabled services Currently, every service has a play in site.yml that is executed, and the role is skipped if the service is disabled. This can be slow, particularly with many hosts, since each play takes time to setup, and evaluate. This change creates various Ansible groups for hosts with services enabled at the beginning of the playbook. If a service is disabled, this new group will have no hosts, and the play for that service will be a noop. I have tested this on a laptop using an inventory with 12 hosts (each pointing to my laptop via SSH), and a config file that disables every service. Time taken to run 'kolla-ansible deploy': Before change: 2m30s After change: 0m14s During development I also tried an approach using an 'include_role' task for each service. This was not as good, taking 1m00s. The downsides to this patch are that there is a large number of tasks at the beginning of the playbook to perform the grouping, and every play for a disabled service now outputs this warning message: [WARNING]: Could not match supplied host pattern, ignoring: enable_foo_True This is because if the service is disabled, there are no hosts in the group. This seems like a reasonable tradeoff. Change-Id: Ie56c270b26926f1f53a9582d451f4bb2457fbb67
2018-09-14 16:51:56 -06:00
- '&enable_blazar_True'
Fix ansible warning - rename action and serial to kolla_ansible and kolla_serial - use become instead of "sudo <command>" in shell - Remove quota for failed_when and changed_when in rabbitmq tasks Change-Id: I78cb60168aaa40bb6439198283546b7faf33917c Implements: blueprint migrate-to-ansible-2-2-0
2018-01-25 11:30:32 +08:00
serial: '{{ kolla_serial|default("0") }}'
Implement blazar ansible role Add ansible role to deploy blazar Add nova filters to allow use of blazar Change-Id: I6742ddc9a4736f256491dd0cfd31904fa8eb5652 Implements: blueprint blazar-ansible-role
2017-04-07 16:01:07 +01:00
roles:
- { role: blazar,
tags: blazar,
when: enable_blazar | bool }
Add Masakari Ansible role Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Depends-On: https://review.openstack.org/#/c/615469/ Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa Implements: blueprint ansible-masakari Co-Authored-By: Gaëtan Trellu <gaetan.trellu@incloudus.com>
2018-11-06 10:20:02 +07:00
- name: Apply role masakari
gather_facts: false
hosts:
- masakari-api
- masakari-engine
masakari: support host monitor Change-Id: I3f43df7766c57622ab8d01a759fbeeef0a0c2b93 Implements: blueprint masakari-hostmonitor Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
2020-07-29 10:30:52 +00:00
- masakari-hostmonitor
- masakari-instancemonitor
Add Masakari Ansible role Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Depends-On: https://review.openstack.org/#/c/615469/ Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa Implements: blueprint ansible-masakari Co-Authored-By: Gaëtan Trellu <gaetan.trellu@incloudus.com>
2018-11-06 10:20:02 +07:00
- '&enable_masakari_True'
serial: '{{ kolla_serial|default("0") }}'
roles:
- { role: masakari,
tags: masakari,
when: enable_masakari | bool }
Copy Permalink