We have several puppet files involved:
- openstack::cloudrepo modules/openstack/manifests/cloudrepo.pp
- openstack::clientrepo modules/openstack/manifests/clientrepo.pp
- openstack::clientlib modules/openstack/manifests/clientlib.pp
- openstack::jessie_mitaka_client_pinning modules/openstack/manifests/jessie_mitaka_client_pinning.pp
These classes are called from Openstack profiles (base, which is in turn main, eqiad1, labtest, labtestn).
In each file, we have a lot of if/else pollution to match different openstack/operating system combinations.
This makes these files complex to maintain.
I propose we rearrange according to our actual needs:
- server software repo + apt pinning per Openstack/OS combination
- client software repo + apt pinning per Openstack/OS combination
An improved model could be something like this:
- profile::openstack::base::serverpackages <-- do if/else for Openstack version here (server packages aren't installed in this branch, but in component-specific profiles/classes)
- profile::openstack::base::serverpackages::mitaka <-- do if/else for OperatingSystem here
- openstack::serverpackages::mitaka::trusty (conditionally included above) install repo
- openstack::serverpackages::mitaka::jessie (conditionally included above) install repo (in this concrete case, is just jessie-backports)
- profile::openstack::base::serverpackages::mitaka <-- do if/else for OperatingSystem here
- profile::openstack::base::clientpackages <--- do if/else for Openstack version here
- profile::openstack::base::clientpackages::mitaka <-- do if/else for OperatingSystem here
- openstack::clientpackages::mitaka::trusty (conditionally included above) install repo + packages + apt pinning
- openstack::clientpackages::mitaka::jessie (conditionally included above) install repo + packages + apt pinning
- openstack::clientpackages::mitaka::stretch (conditionally included above) install repo + packages + apt pinning
- profile::openstack::base::clientpackages::mitaka <-- do if/else for OperatingSystem here