TripleO/TuskarJunoPlanning/TemplateBackend
Contents
Overview
The purpose of this page is to describe a change in architecture to use Heat templates and environments as the data store for Tuskar.
This design assumes the completion of the Juno changes to the TripleO Heat templates to use provider resources.
Format
There are two main types of information that are needed when configuring an overcloud:
- The selection and count of what services will be run in the cloud.
- The configuration for those services.
The Icehouse release for Tuskar uses a database to store both pieces of information. For Juno, the goal is to move that information directly into the Heat templates themselves. This will be accomplished using two recently added features of Heat: provider resources and environments. Provider resources allow for fine-grained stacks to be defined and built up into a larger Heat stack. Environments are a way to capture the selection of which provider resources to use and their configuration values.
Using these features, Tuskar will be able to choose a subset of the TripleO Heat templates to include in the overcloud. Those templates remain static and unedited by Tuskar. Tuskar is then responsible for generating the overall cloud template that includes each of the provider resources and the environment file for saving the configuration.
The following series of diagrams shows the relationships between the provider resource templates and the Tuskar-generated files that will use them for configuring a cloud. Note: Discussion on where these files are stored is elsewhere on this page; what follows is a description of the interplay between the TripleO templates and the Tuskar-generated files.
Step 1: Create a Cloud
When a cloud is initially created in Tuskar, it is comprised of two files: the deployment plan which is the overarching Heat template that configures the cloud's stack and the environment file which contains the provider resource mappings and cloud's configuration values. Note: The names of these files as depicted in the diagram are not final.
The files listed on the left are provider resource templates from TripleO. They are not edited by Tuskar and are used as building blocks for the cloud's stack.
Step 2: Select Roles
The Icehouse release of Tuskar uses the term "role" to describe an individual function of the cloud. For the purposes of this discussion, they are considered to map 1:1 with provider resource template files. Note: This is likely not 100% accurate but is a sufficient abstraction for now.
In the diagram above, the user has selected both alpha and beta for inclusion in the cloud. At this point, Tuskar makes the following changes to its generated files:
- A reference to the template file is added to the environment. The example simply names them X and Y; a better naming scheme will be determined in the future. More details on what this reference looks like are discussed below.
- A resource for each provider resource is added to the plan template.
Step 3: Configuration Consolidation
The plan template needs to expose the configurable parameters of each provider resource. The example in the diagram is intentionally simplistic; there is no overlap in parameter names between provider resources. Resolving conflicts is potentially complicated. There are a few scenarios to consider:
- The same value should be used across multiple resources. For instance, if both alpha and beta expose a value called "key_name" for the SSH keypair and the same keypair should be used for each resource.
- Multiple provider resources use the same name for a parameter but will need separate values. For instance, if alpha and beta both simply use "image_id", however the likely usage is that they will be created from different images.
- A single provider resource, used multiple times and configured differently in each case. For instance, two uses of the provider resource that use a different flavor.
Further discussion on possible solutions can be found in the Open Questions section.
