[RFE] Make the configuration of quickstart variable-centric

Bug #1818503 reported by Gabriele Cerami
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Incomplete
Wishlist
Gabriele Cerami

Bug Description

Current configuration model follow the standard way to pass variables to ansible
playbooks. All the variables that end up in a run have been grouped in files
that represent their classification. Variables that turn on or off a feature
(e.g. ssl or ipv6) are grouped in featuresets, file with values that depend on
where the run will be launched are put in environment files, variables that
configure the overcloud node configuration are put in nodes files and so on.
Different values for the same variable are put in different variation of the
same group.

For more specific information see the configuration overview in
tripleo-quickstart docs.

All the different groups of variables are then combined together to assemble the
final configuration of the test we want to run. E.g. we combine featureset001
with ovb environemnt file, and a 3 controller,1 compute nodes configuration to
get a very important test in our pipeline.

To pass all these variables to ansible playbook, the list of files is then
passed using multiple --extra-vars. The position of the file with variables in
the list of multiple --extra-vars determine the priority of the value. If a
variable is present on a file that is passed last, its value will override every
other value (I see this model as a chain of overrides.)

There are two aspect in this process that usually represent a big challenge:

- A new variable must be classified uniquely on the classes that are available.
  There is not easy way to create a new class. There is a limited set of group
  in which you may place the variable, and it's not always straightforward. Also
  classification is not futureproof, there is no way to classify variable you
  don't know they exist yet, so future requirements will need to adapt to an
  obsolete design
- When the correct placement for the variable has been found, or for an already
  existing variable, we may want to present a specific value for that variable
  to a particular run, and it may prove very hard to find the right combination
  of group files and position in the override chain, so that value end up in all
  the jobs that we want, and not show in all other jobs.

Over time, different strategies have been put in place to overcome these
challenges. For example the release specification is a factor that may affect
many variables, but we don't group variables by release. The same featureset
file can be use to serve different releases, and jinja code has been put in the
featureset to change the value of the same variable depending on different
releases.

This further complicates the variables management, as the group files are now
multidimensional, the same file can provide different values for the same
variable under certain conditions.

To prevent having to control extensively the chain of overrides and try to
understand which values wins and from which file in the chain the value that
wins is taken, we used strict classification. One variable can be placed only on
a single group. A variable in featureset cannot be specified also in a
environment file. Unfortunately this is completely arbitrary, nothing
technically forbids this behaviour and it proved to be difficult to enforce, and
sometimes very limiting in our choices.

We should investigate different models that follow the growth and direction of
operations of variables.

Tags: ci quickstart
summary: - Make the configuration of quickstart variable-centric
+ [RFE] Make the configuration of quickstart variable-centric
Changed in tripleo:
milestone: train-1 → train-2
Changed in tripleo:
status: New → Triaged
Changed in tripleo:
milestone: train-2 → train-3
Changed in tripleo:
milestone: train-3 → ussuri-1
Changed in tripleo:
milestone: ussuri-1 → ussuri-2
wes hayutin (weshayutin)
Changed in tripleo:
milestone: ussuri-2 → ussuri-3
wes hayutin (weshayutin)
Changed in tripleo:
milestone: ussuri-3 → ussuri-rc3
wes hayutin (weshayutin)
Changed in tripleo:
milestone: ussuri-rc3 → victoria-1
Changed in tripleo:
milestone: victoria-1 → victoria-3
Changed in tripleo:
milestone: victoria-3 → wallaby-1
Changed in tripleo:
milestone: wallaby-1 → wallaby-2
Changed in tripleo:
milestone: wallaby-2 → wallaby-3
Revision history for this message
Marios Andreou (marios-b) wrote :

This is an automated action. Bug status has been set to 'Incomplete' and target milestone has been removed due to inactivity. If you disagree please re-set these values and reach out to us on freenode #tripleo

Changed in tripleo:
milestone: wallaby-3 → none
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers