Appendix A. Composable service parameters The following parameters are used for the outputs in all composable services: service_name config_settings service_config_settings global_config_settings step_config upgrade_tasks upgrade_batch_tasks The following parameters are used for the outputs specifically for containerized composable services: puppet_config kolla_config docker_config container_puppet_tasks host_prep_tasks fast_forward_upgrade_tasks A.1. All composable services The following parameters apply to all composable services. service_name The name of your service. You can use this to apply configuration from other composable services with service_config_settings . config_settings Custom hieradata settings for your service. service_config_settings Custom hieradata settings for another service. For example, your service might require its endpoints registered in OpenStack Identity ( keystone ). This provides parameters from one service to another and provide a method of cross-service configuration, even if the services are on different roles. global_config_settings Custom hieradata settings distributed to all roles. step_config A Puppet snippet to configure the service. This snippet is added to a combined manifest created and run at each step of the service configuration process. These steps are: Step 1 - Load balancer configuration Step 2 - Core high availability and general services (Database, RabbitMQ, NTP) Step 3 - Early OpenStack Platform Service setup (Storage, Ring Building) Step 4 - General OpenStack Platform services Step 5 - Service activation (Pacemaker) and OpenStack Identity (keystone) role and user creation In any referenced puppet manifest, you can use the step hieradata (using hiera('step') ) to define specific actions at specific steps during the deployment process. upgrade_tasks Ansible snippet to help with upgrading the service. The snippet is added to a combined playbook. Each operation uses a tag to define a step , which includes: common - Applies to all steps step0 - Validation step1 - Stop all OpenStack services. step2 - Stop all Pacemaker-controlled services step3 - Package update and new package installation step4 - Start OpenStack service required for database upgrade step5 - Upgrade database upgrade_batch_tasks Performs a similar function to upgrade_tasks but only executes batch set of Ansible tasks in order they are listed. The default is 1 , but you can change this per role using the upgrade_batch_size parameter in a roles_data.yaml file. A.2. Containerized composable services The following parameters apply to all containerized composable services. puppet_config This section is a nested set of key value pairs that drive the creation of configuration files using puppet. Required parameters include: puppet_tags Puppet resource tag names that are used to generate configuration files with Puppet. Only the named configuration resources are used to generate a file. Any service that specifies tags will have the default tags of file,concat,file_line,augeas,cron appended to the setting. Example: keystone_config config_volume The name of the volume (directory) where the configuration files are generated for this service. Use this as the location to bind mount into the running Kolla container for configuration. config_image The name of the container image that will be used for generating configuration files. This is often the same container that the runtime service uses. Some services share a common set of configuration files which are generated in a common base container. step_config This setting controls the manifest that is used to create configuration files with Puppet. Use the following Puppet tags together with the manifest to generate a configuration directory for this container. kolla_config Creates a map of the the kolla configuration in the container. The format begins with the absolute path of the configuration file and then uses for following sub-parameters: command The command to run when the container starts. config_files The location of the service configuration files ( source ) and the destination on the container ( dest ) before the service starts. Also includes options to either merge or replace these files on the container ( merge ), whether to preserve the file permissions and other properties ( preserve_properties ). permissions Set permissions for certain directories on the containers. Requires a path and an owner (and group). You can also apply the permissions recursively ( recurse ). The following is an example of the kolla_config paramaeter for the keystone service: docker_config Data passed to the paunch command to configure containers at each step. step_0 - Containers configuration files generated per hiera settings. step_1 - Load Balancer configuration Baremetal configuration Container configuration step_2 - Core Services (Database/Rabbit/NTP/etc.) Baremetal configuration Container configuration step_3 - Early OpenStack Service setup (Ringbuilder, etc.) Baremetal configuration Container configuration step_4 - General OpenStack Services Baremetal configuration Container configuration Keystone container post initialization (tenant, service, endpoint creation) step_5 - Service activation (Pacemaker) Baremetal configuration Container configuration The YAML uses a set of parameters to define the container container to run at each step and the podman settings associated with each container. For example: This creates a keystone container and uses the respective parameters to define details like the image to use, the networking type, and environment variables. container_puppet_tasks Provides data to drive the container-puppet.py tool directly. The task is executed only once within the cluster (not on each node) and is useful for several Puppet snippets required for initialization of things like keystone endpoints and database users. For example: host_prep_tasks Ansible snippet to execute on the node host to prepare it for containerized services. For example, you might need to create a specific directory to mount to the container during its creation. fast_forward_upgrade_tasks Ansible snippet to help with the fast forward upgrade process. This snippet is added to a combined playbook. Each operation uses tags to define step and release The step usually follows these stages: step=0 - Check running services step=1 - Stop the service step=2 - Stop the cluster step=3 - Update repositories step=4 - Database backups step=5 - Pre-package update commands step=6 - Package updates step=7 - Post-package update commands step=8 - Database updates step=9 - Verification The tag corresponds to a release: tag=ocata - OpenStack Platform 11 tag=pike - OpenStack Platform 12 tag=queens - OpenStack Platform 13

Commands:
kolla_config: /var/lib/kolla/config_files/keystone.json: command: /usr/sbin/httpd -DFOREGROUND config_files: - source: "/var/lib/kolla/config_files/src/*" dest: "/" merge: true preserve_properties: true /var/lib/kolla/config_files/keystone_cron.json: command: /usr/sbin/crond -n config_files: - source: "/var/lib/kolla/config_files/src/*" dest: "/" merge: true preserve_properties: true permissions: - path: /var/log/keystone owner: keystone:keystone recurse: true
docker_config: step_3: keystone: start_order: 2 image: *keystone_image net: host privileged: false restart: always healthcheck: test: /openstack/healthcheck volumes: *keystone_volumes environment: - KOLLA_CONFIG_STRATEGY=COPY_ALWAYS
container_puppet_tasks: # Keystone endpoint creation occurs only on single node step_3: config_volume: 'keystone_init_tasks' puppet_tags: 'keystone_config,keystone_domain_config,keystone_endpoint,keystone_identity_provider,keystone_paste_ini,keystone_role,keystone_service,keystone_tenant,keystone_user,keystone_user_role,keystone_domain' step_config: 'include ::tripleo::profile::base::keystone' config_image: *keystone_config_image