Make the Inventory Structure Configurable

[srueg]

Background

Currently the inventory structure is hard coded into Commodore:

• global.common
• global.cloud.<cloud-provider>
• global.cloud.<cloud-provider>.<cloud-region>
• global.distribution.<k8s-distribution>
• <customer>.<cluster>

This limits the flexibility of different setups and makes changes to this hierarchy more difficult.

Similar to Puppet Hiera, this structure should be configurable outside of Commodore.

Proposal

Implement a config file which can define the inventory structure. This config file should be created in the global config Git repo with a specific name (e.g. syn.yml). It should allow to use facts as placeholders for names in the structure. The leaf of an entry is always a class (i.e. .yml file).

The referenced classes should be optional and if they don't exist they should be skipped. I.e. if a cloud doesn't have a region, no cloud/${cloud}/${region}.yml file needs to exist.

Possible example:

hierarchy:
  - global/common
  - global/cloud/${cloud}
  - global/cloud/${cloud}/${region}
  - global/distribution/${distribution}
  - global/lieutenant-instance/${lieutenant-instance}
  - ${tenant}/common
  - ${tenant}/${cluster}

References

• Puppet Hiera config: https://puppet.com/docs/hiera/3.3/configuring.html

[simu]

The referenced classes should be optional and if they don't exist they should be skipped. I.e. if a cloud doesn't have a region, no cloud/${cloud}/${region}.yml file needs to exist.

How would you determine which parts of the externally specified hierarchy are optional and which aren't? Or is the idea to make everything optional?

I like the overall idea though, :+1:

[srueg]

Yes, everything would be optional (like in Puppet).

I guess Commodore would need to implement this logic, since in reclass all classes are required to exist, correct?

[simu]

Yes, Commodore will need to implement logic to ensure the resulting Kapitan (really reclass) inventory only references classes which actually exist as .yml files under inventory/.

[srueg]

This could be implemented using the "references in class names" feature of reclass: https://github.com/salt-formulas/reclass/blob/develop/README-extensions.rst#use-references-in-class-names

The global.yml could use references to include the proper cloud/distribution/cluster classes:

classes:
- global.distribution.${cluster:dist}
- global.cloud.${cloud:provider}
- global.cloud.${cloud:provider}.${cloud:region}
- ${customer:name}.${cluster:name}

With this the hierarchy itself defines the hierarch and there's no need to introduce this in a separate mechanism like a commodore.yml file.

[srueg]

To make this work, we'd need to include the required parameters (cloud provider, region, cluster name, tenant name, etc.) in a class before using them. Instead of adding these parameters to the generated targets/cluster.yml they would need to go into a class which is included first.

[srueg]

Possible solutions to prevent facts override:

1. Use constant parameters for the facts
2. Set the facts again in the cluster.yml target to enforce them
3. Allow overriding of facts (comes with some caveats)

[srueg]

To make this work, we'd need to include the required parameters (cloud provider, region, cluster name, tenant name, etc.) in a class before using them. Instead of adding these parameters to the generated targets/cluster.yml they would need to go into a class which is included first.

This is probably solved by https://github.com/kapicorp/reclass/pull/2

[srueg]

PoC: https://git.vshn.net/syn/commodore-defaults/-/merge_requests/21/