Bug #17435
open
hooks: allow hooks to define hiera values
Description
When hooking into a kafo-based installer (e.g. foreman-installer) it would be nice, if I would be able to define parameters for puppet classes not directly included as "module". That would allow to change class paramters that are included as part of an installation but not directly parametrized as 'module'.
I had a possible use case, when I wanted to change postgresql listen_addresses to include a certain interface address, which requires to set the corresponding parameter on postgresql::server which is included by foreman::database::postgresql.
I'd be willing to work on this and thought about this implementation:
- Add a new attribute custom_hiera_values to Kafo::Configuration
- Extend HieraConfigure
- include a new hierarchy layer kafo_custom before kafo_answers
- let write_configs write that file with the contents of kafo.config.custom_hiera_values
- Add methods to kafo/hook_context store_custom_hiera_value and get_custom_hiera_value
Seems straightforward and is improving flexibility. What do you think? Anything I miss, any comments about the possible implementation?
Updated by Ewoud Kohl van Wijngaarden almost 8 years ago
We already provide all the answers to Puppet through Hiera. For example in https://github.com/theforeman/foreman-installer/commit/9df10e1bae8039039ada50ada01b7df5915c9fd2 we added options to Apache. What you are proposing is allowing hooks to do this dynamically, correct? Without looking at the implementation that is a good idea.
Updated by Patrick Schönfeld almost 8 years ago
Ewoud Kohl van Wijngaarden wrote:
We already provide all the answers to Puppet through Hiera. For example in https://github.com/theforeman/foreman-installer/commit/9df10e1bae8039039ada50ada01b7df5915c9fd2 we added options to Apache. What you are proposing is allowing hooks to do this dynamically, correct? Without looking at the implementation that is a good idea.
Yes, this is basically what I'm proposing.
In the meanwhile I started working on it :) My initial (yet untested) implementation isn in my github fork https://github.com/aptituz/kafo. No pull request yet, since I couldn't test it so far, but it's probably less abstract to talk about when there is something too look at.
Btw. since I've never worked on kafo itself before: What's the best way to kafo changes out of a source tree?