tripleo-heat-templates/puppet/services
Zuul 1c46d1850a Merge "step3: flatten nova service configuration" 2019-02-15 10:17:56 +00:00
..
database Merge "TLS everywhere: Set post-save command for redis" 2019-02-01 13:12:23 +00:00
messaging Flatten rabbitmq service - step 1 2019-02-05 15:44:40 +01:00
metrics Merge "Include cpu plugin in default collect plugins" 2019-01-03 05:43:12 +00:00
pacemaker Flatten rabbitmq service - step 1 2019-02-05 15:44:40 +01:00
releasenotes/notes Sets ODL OVSDB inactivity probe timer 2018-10-24 11:43:20 -04:00
README.rst Remove workflow_tasks 2019-01-24 11:08:53 +01:00
aide.yaml ansible: replace yum module by package module when possible 2018-07-21 00:17:25 +00:00
apache.j2.yaml TLS everywhere: Set post-save command for httpd 2019-01-29 05:51:29 +00:00
auditd.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
barbican-api.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
barbican-backend-dogtag.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
barbican-backend-kmip.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
barbican-backend-pkcs11-crypto.yaml Added Barbican option BarbicanPkcs11AlwaysSetCkaSensitive 2019-01-17 08:50:24 -06:00
barbican-backend-simple-crypto.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
ca-certs.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
ceilometer-agent-central.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
ceilometer-agent-compute.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
ceilometer-agent-ipmi.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
ceilometer-agent-notification.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
ceilometer-base.yaml Switch debug to use logging classes 2018-12-10 08:32:28 -07:00
certmonger-user.yaml Add support for native TLS encryption on NBD for disk migration 2019-01-18 10:52:35 +00:00
congress.yaml Merge "Switch debug to use logging classes" 2018-12-14 05:06:23 +00:00
designate-api.yaml Designate: Use keystone v3 internal endpoint instead of admin 2019-01-22 18:27:30 +02:00
designate-base.yaml Switch debug to use logging classes 2018-12-10 08:32:28 -07:00
designate-central.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
designate-mdns.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
designate-producer.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
designate-sink.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
designate-worker.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
ec2-api.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
external-swift-proxy.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
gnocchi-api.yaml Prevent service bootstrap node facts from colliding with each other 2019-01-03 17:27:27 +01:00
gnocchi-base.yaml Switch debug to use logging classes 2018-12-10 08:32:28 -07:00
gnocchi-metricd.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
gnocchi-statsd.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
liquidio-compute-config.yaml Implements: liquidio-containerization 2018-10-09 12:10:02 +05:30
manila-backend-cephfs.yaml Unify the Manila HA and non-HA docker configurations 2018-07-12 11:23:39 -04:00
manila-backend-isilon.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
manila-backend-netapp.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
manila-backend-unity.yaml Fix for the manila backend configuration errors 2018-05-14 13:43:04 -05:00
manila-backend-vmax.yaml Fix for the manila backend configuration errors 2018-05-14 13:43:04 -05:00
manila-backend-vnx.yaml Fix for the manila backend configuration errors 2018-05-14 13:43:04 -05:00
masquerade-networks.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-base.yaml TLS everywhere: Set post-save command for neutron dhcpd 2019-02-01 17:07:02 +01:00
neutron-bgpvpn-api.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-bgpvpn-bagpipe.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-bigswitch-agent.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-compute-plugin-midonet.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-compute-plugin-nuage.yaml Merge "Introducing Nuage Neutron VRS resource." 2019-02-02 02:47:55 +00:00
neutron-compute-plugin-plumgrid.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-controller-plugin-nuage.yaml Introducing Nuage Neutron VRS resource. 2018-10-11 10:56:30 -04:00
neutron-l2gw-agent.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
neutron-l2gw-api.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-l3-compute-dvr.yaml Merge "Remove external_network_bridge Neutron option" 2019-01-29 15:20:24 +00:00
neutron-lbaas-agent.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-lbaas-api.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-linuxbridge-agent.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-midonet.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-ml2-ansible.yaml Add networking-ansible ML2 plugin support 2018-07-02 13:22:04 +05:30
neutron-plugin-ml2-cisco-vts.yaml Add site id parameter to cisco vts ml2 template 2018-05-30 10:01:48 +00:00
neutron-plugin-ml2-fujitsu-cfab.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-ml2-fujitsu-fossw.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-ml2-mlnx-sdn-assist.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-ml2-nuage.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-ml2-odl.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-ml2-ovn.yaml Add VLAN as a supported network type for OVN 2019-01-25 10:36:02 +00:00
neutron-plugin-ml2.yaml Allow setting physical network MTU via heat template 2018-07-23 15:31:29 +02:00
neutron-plugin-nsx.yaml Add more NSX config parameters 2018-10-30 03:28:12 +00:00
neutron-plugin-nuage.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-plugin-plumgrid.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-sfc-api.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-sriov-agent.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
neutron-sriov-host-config.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
neutron-vpp-agent.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
nova-base.yaml Move [neutron] auth_url to KeystoneV3Internal 2018-12-14 14:37:11 +01:00
octavia-api.yaml Fix Octavia hieradata keys 2018-11-27 08:49:58 +01:00
octavia-base.yaml Switch debug to use logging classes 2018-12-10 08:32:28 -07:00
octavia-controller.yaml update datatype for "OctaviaFlavorId" 2019-01-03 16:34:31 +00:00
octavia-health-manager.yaml Merge "Fix Octavia hieradata keys" 2019-01-03 05:46:11 +00:00
octavia-housekeeping.yaml Fix Octavia hieradata keys 2018-11-27 08:49:58 +01:00
octavia-worker.yaml Fix Octavia hieradata keys 2018-11-27 08:49:58 +01:00
opendaylight-api.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
opendaylight-ovs.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
openstack-clients.yaml Add OpenStack clients service 2018-10-26 16:25:35 -06:00
openvswitch.yaml Handle LP openvswitch meta-package on upgrade 2018-11-08 14:54:28 -03:30
ovn-controller.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
ovn-dbs.yaml upgrade: remove tasks that stop and disable services 2018-12-10 09:19:59 -05:00
ovn-metadata.yaml Drop unused puppet/services parameters 2019-01-21 07:55:08 -05:00
pacemaker.yaml minor update: move VIP before stopping pacemaker on a node 2019-02-08 14:19:12 +00:00
pacemaker_remote.yaml Convert dynamic lookups to use colon notation 2018-11-12 21:21:49 -07:00
qdr.yaml Convert dynamic lookups to use colon notation 2018-11-12 21:21:49 -07:00
tripleo-validations.yaml Implement TripleoValidations composable service 2018-06-13 11:35:49 -07:00
veritas-hyperscale-controller.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00
vpp.yaml Change template names to rocky 2018-05-09 08:28:42 +02:00

README.rst

services

A TripleO nested stack Heat template that encapsulates generic configuration data to configure a specific service. This generally includes everything needed to configure the service excluding the local bind ports which are still managed in the per-node role templates directly (controller.yaml, compute.yaml, etc.). All other (global) service settings go into the puppet/service templates.

Input Parameters

Each service may define its own input parameters and defaults. Operators will use the parameter_defaults section of any Heat environment to set per service parameters.

Apart from sevice specific inputs, there are few default parameters for all the services. Following are the list of default parameters:

  • ServiceData: Mapping of service specific data. It is used to encapsulate all the service specific data. As of now, it contains net_cidr_map, which contains the CIDR map for all the networks. Additional data will be added as and when required.

  • ServiceNetMap: Mapping of service_name -> network name. Default mappings for service to network names are defined in ../network/service_net_map.j2.yaml, which may be overridden via ServiceNetMap values added to a user environment file via parameter_defaults.

  • EndpointMap: Mapping of service endpoint -> protocol. Contains a mapping of endpoint data generated for all services, based on the data included in ../network/endpoints/endpoint_data.yaml.

  • DefaultPasswords: Mapping of service -> default password. Used to pass some passwords from the parent templates, this is a legacy interface and should not be used by new services.

  • RoleName: Name of the role on which this service is deployed. A service can be deployed in multiple roles. This is an internal parameter (should not be set via environment file), which is fetched from the name attribute of the roles_data.yaml template.

  • RoleParameters: Parameter specific to a role on which the service is applied. Using the format "<RoleName>Parameters" in the parameter_defaults of user environment file, parameters can be provided for a specific role. For example, in order to provide a parameter specific to "Compute" role, below is the format:

    parameter_defaults:
      ComputeParameters:
        Param1: value

Config Settings

Each service may define three ways in which to output variables to configure Hiera settings on the nodes.

  • config_settings: the hiera keys will be pushed on all roles of which the service is a part of.
  • global_config_settings: the hiera keys will be distributed to all roles
  • service_config_settings: Takes an extra key to wire in values that are defined for a service that need to be consumed by some other service. For example: service_config_settings: haproxy: foo: bar This will set the hiera key 'foo' on all roles where haproxy is included.

Deployment Steps

Each service may define an output variable which returns a puppet manifest snippet that will run at each of the following steps. Earlier manifests are re-asserted when applying latter ones.

  • config_settings: Custom hiera settings for this service.

  • global_config_settings: Additional hiera settings distributed to all roles.

  • step_config: A puppet manifest that is used to step through the deployment sequence. Each sequence is given a "step" (via hiera('step') that provides information for when puppet classes should activate themselves.

    Steps correlate to the following:

    1. Load Balancer configuration
    2. Core Services (Database/Rabbit/NTP/etc.)
    3. Early Openstack Service setup (Ringbuilder, etc.)
    4. General OpenStack Services
    5. Service activation (Pacemaker)

Batch Upgrade Steps (deprecated)

Note: the upgrade_batch_tasks are no longer used and deprecated for Queens. The information below applies to upgrade_batch_tasks as they were used for the Ocata major upgrade. The upgrade_batch_tasks were used exclusively by the ceph services and for Pike ceph is now configured by ceph-ansible.

Each service template may optionally define a upgrade_batch_tasks key, which is a list of ansible tasks to be performed during the upgrade process.

Similar to the step_config, we allow a series of steps for the per-service upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first step, "step2" for the second, etc (currently only two steps are supported, but more may be added when required as additional services get converted to batched upgrades).

Note that each step is performed in batches, then we move on to the next step which is also performed in batches (we don't perform all steps on one node, then move on to the next one which means you can sequence rolling upgrades of dependent services via the step value).

The tasks performed at each step is service specific, but note that all batch upgrade steps are performed before the upgrade_tasks described below. This means that all services that support rolling upgrades can be upgraded without downtime during upgrade_batch_tasks, then any remaining services are stopped and upgraded during upgrade_tasks

The default batch size is 1, but this can be overridden for each role via the upgrade_batch_size option in roles_data.yaml

Update Steps

Each service template may optionally define a update_tasks key, which is a list of ansible tasks to be performed during the minor update process. These are executed in a rolling manner node-by-node.

We allow a series of steps for the per-service update sequence via conditionals referencing a step variable e.g when: step|int == 2.

Pre-upgrade Rolling Steps

Each service template may optionally define a pre_upgrade_rolling_tasks key, which is a list of ansible tasks to be performed before the main upgrade phase, and these tasks are executed in a node-by-node rolling manner on the overcloud, similarly as update_tasks.

Upgrade Steps

Each service template may optionally define a upgrade_tasks key, which is a list of ansible tasks to be performed during the upgrade process.

Similar to the update_tasks, we allow a series of steps for the per-service upgrade sequence, defined as ansible tasks with a "when: step|int == 1" for the first step, "== 2" for the second, etc.

Steps correlate to the following:

  1. Perform any pre-upgrade validations.
  2. Stop the control-plane services, e.g disable LoadBalancer, stop pacemaker cluster and stop any managed resources. The exact order is controlled by the cluster constraints.
  3. Perform a package update and install new packages: A general upgrade is done, and only new package should go into service ansible tasks.
  4. Start services needed for migration tasks (e.g DB)
  5. Perform any migration tasks, e.g DB sync commands

Note that the services are not started in the upgrade tasks - we instead re-run puppet which does any reconfiguration required for the new version, then starts the services.

Nova Server Metadata Settings

One can use the hook of type OS::TripleO::ServiceServerMetadataHook to pass entries to the nova instances' metadata. It is, however, disabled by default. In order to overwrite it one needs to define it in the resource registry. An implementation of this hook needs to conform to the following:

  • It needs to define an input called RoleData of json type. This gets as input the contents of the role_data for each role's ServiceChain.
  • This needs to define an output called metadata which will be given to the Nova Server resource as the instance's metadata.