search

unibonn / puppet-cobald

Puppet module for COBalD/TARDIS based opportunistic resource management
Apache License 2.0
1 stars 7 forks source link

Add support for a wider range of RHEL clones #16

Open wiene opened 2 years ago

wiene commented 2 years ago

Given the developments in the CentOS Project we should support a wider range of RHEL clones.

wiene commented 2 years ago

@olifre proposed to use $facts['os']['family'] == 'RedHat' rather than $facts['os']['name'] == 'CentOS' in the manifest/params.pp code.

A potential loophole is that Fedora hosts would probably also belong to the RedHat family and the code will not work on ancient Fedora Linux 7 and Fedora Linux 8 (according to this page, they were released before the publication of Python 3). But probably this is rather a theoretical than a practical problem.

Apart from this, the proposed solution is definitely nicer than maintaining a list of RHEL clone names.

@olifre what do you think?

olifre commented 2 years ago

Fedora hosts would probably also belong to the RedHat family

That does indeed seem to be true: https://github.com/puppetlabs/facter/blob/dfbfd3b88ea433b4ace69e0cd192226ff9f1dfeb/acceptance/lib/facter/acceptance/base_fact_utils.rb#L297-L301

But probably this is rather a theoretical than a practical problem.

I agree, effectively, this means we are not supporting ancient Fedora releases ;-).

Given the currently known rebuilds (AlmaLinux, Rocky Linux) and also other related RedHat family distros (Oracle Linux, Amazon Linux, Scientific Linux) and the rate at which these change, going for the RedHat family seems to be the only maintainable option. We could (later on) add the list of tested distributions to our metadata.json and add unit tests to communicate more clearly which distros we have tested things on.

Further down the road, we may want to migrate to the hiera-based approach which modules like puppet-systemd are using to provide OS-specific defaults (this also allows to get rid of params.pp altogether and use a yaml-based syntax instead).

@wiene what do you think?