[Feature] crio config handling

[SimonHoenscheid]

What are you seeing

I saw this module supports crio as a container engine by default. I checked the code and did not find a piece of code handling the crio related configs /etc/crio/crio.conf and /etc/containers/storage.conf. I just wanted to ask, Is there a specific reason not to manage these files? Maybe @ananace knows

What behaviour did you expect instead

These files are managed

[ananace]

It's partly a legacy thing, that particular design was grandfathered in from an earlier hyperkube module written before CRI-O switched to using built-in defaults and user-specified (/etc/crio/crio.conf.d/) overrides. So managing the main config in the module would've been a bit too fragile and version/setup -dependent, as it would've either needed to have all settings specified at the correct values for all possible versions and OSes, or only managing the existence of the file - which would've broken some earlier upgrades where creating an empty settings file would've meant that CRI-O couldn't launch to finish migrating its config.

Managing /etc/containers/storage.conf also showed similar issues between the systems I was developing against at the time, so that ended up being solved with file_line resources in profile classes instead, acting off of whatever default configuration the distribution packages deployed.

[SimonHoenscheid]

@ananace Thanks for explaining.

My suggestion would be to add $manage_crio_config and $manage_storage_config variables and manage the configs by default. Would that be a good solution? It would also be possible to give the user an option to decide between /etc/crio/crio.conf and /etc/crio/crio.conf.d/. Storage has no override directory AFAIK, but can take an alternative config location.

[ananace]

Managing the CRI-O configuration nowadays is probably reasonably easy; just ensure that the main config file and override directory exist along with a friendly comment about being Puppet-managed, might be interesting to include a purge option to also remove all unmanaged override files - probably along with a defined type (and hiera-friendly parameter) to add configuration data. Managing the storage config might be a little more complex though, since it seems that you need to have a few options set in it - some of which also seem to differ between platforms and versions. (A quick check - with comments removed - across my three clusters shows at least four different versions of that file, though I've not done a deeper dive into the exact differences in the values)

[ananace]

With the latest changes merged, the crio configuration management should now be entirely done conf.d-style, but I've not had a chance to dig all that much deeper into storage.conf yet.