Zaza could expand bundles via variable insertion before deploy

[ChrisMacNaughton]

Given the following bundle.yaml and tests.yaml example, we could use the variables defined in the tests.yaml to build our test matrix, reducing the repetition in our charms.

bundle.yaml:

series: *series
applications:
  ceph-osd:
    charm: ceph-osd
    options:
      source: *source
  ceph-mon:
    charm: cs:ceph-mon
    options:
      source: *source
relations:
  - - ceph-mon
    - ceph-osd

tests.yaml:

charm_name: ceph-osd
base_bundle:
  - bundle
# gate_bundles:
#   --snip--
# smoke_bundles:
#   --snip--
# dev_bundles:
#   --snip--
configure: []
tests:
  - zaza.openstack.charm_tests.ceph.tests.CephTest

# The below section is entirely optional and will be used as a transform
# on the {gate,smoke,dev}_bundles sections at the beginning. The matrix below
# would transform into, basically: 
# gate_bundles:
#   - bionic-stein
#   - bionic-rocky
#   - bionic-queens
#   - xenial-queens
#   - xenial-pike
#   - xenial-ocata
#   - xenial-mitaka
#   - trusty-mitaka
# smoke_bundles:
#   - bionic-queens
# dev_bundles:
#   - cosmic-rocky
#   - disco-stein
matrix:
  series:
    - disco:
        -  source|openstack-origin:
            - stein:
                - dev: true
                - gate: false
    - cosmic:
        -  source|openstack-origin:
            - rocky:
                - dev: true
                - gate: false
    - bionic:
        -  source|openstack-origin:
            - stein
            - rocky
            - queens:
              - smoke: true
    - xenial:
        -  source|openstack-origin:
            - queens
            - pike
            - ocata
            - mitaka
    - trusty:
        -  source|openstack-origin:
            - mitaka

An alternate method for mapping in the matrix section to the *-bundle section could be:

base-bundle:
  bundle
# The mode_map key would be used as a replace map to identify
# the pattern to transform the matrix variables into the bundle
# mappings for dev/smoke/gate
mode_map: "*series-*openstack-origin"
gate_bundles:
  - bionic-stein
  - bionic-rocky
  - bionic-queens
smoke_bundles:
  - bionic-queens
dev_bundles:
  - cosmic-rocky
  - disco-stein
matrix:
  series:
    - disco:
        -  source|openstack-origin:
            - stein
    - cosmic:
        -  source|openstack-origin:
            - rocky
    - bionic:
        -  source|openstack-origin:
            - stein
            - rocky
            - queens

In addition to mapping the bundles to be run, the above would additionally add the following section to the bundle.yaml (bundle.yaml in the above config):

variables:
  series: &series disco
  source: &source stein
  openstack-origin: &openstack-origin stein

Where the [disco / stein] combination is an entry generated by the matrix values in tests.yaml.

While this method would increase the length of the tests.yaml (potentially considerably), It would almost entirely remove the repetition mapping each U-OS combination to a new bundle.

It is also possible that the base-bundle section could be extended to allow for mapping different base bundles depending on the variables in the matrix section. I think that this would be valuable when considering bundles that change deployed applications per release, or for restricting some applications to a subset of releases.

After combining these variables in their "base" bundle, we could render the base bundle in addition to overlays as the primary bundle to deploy.

[ChrisMacNaughton]

I have created a new RFC branch, and associated Pull Request for this into that branch at #235