Instead of adding filters to ‘/usr/share/foreman/config/ignored_environments.yml’.
My suggestion is to update the ‘Configure’ -> ‘Classes’ page to give better control over the classes.
Under the ‘Actions’ column add two extra actions ‘active’ and ‘passive’.
By default when a Puppet module is added to Foreman all classes in that module are added as ‘active’. I.e. Available to be managed by Foreman. Helper classes (not to be manages by Foreman) can then be set to ‘passive’. In the example in 4.2.2. git::install, git::params & git::repo would be set to ‘passive’.
For the GUI - gray out the ‘passive’ classes and add a button/ icon to show/hide the passive classes.
It should be considered an ERROR if the user tries to make a class ‘passive’ if any Smart Variables or Smart Class Parameters have been given a value or an override. This could save a debug nightmare! Can you imagine trying to debug a class value change when the class is hidden?
If for example the users have a module from the Puppet forge that needs parameters changed for their environment I recommend that they update the code for the module or use hiera.
With this setup I believe that Foreman will not have to process any ‘passive’ classes to display and manage the classes or each run of the puppet agent. As this takes the ‘passive’ classes out of the view of Foreman I believe you will see a bit of a performance improvement!
If the user was to set a ‘passive’ class to ‘active’ then I believe Foreman should scan the class as if it has just been imported.
You’re right that this is way too hidden. I have thought about moving this configuration to the smart-proxy. Recently I had a discussion about this and someone suggested that the Puppetserver API could exposed the puppet-strings’ @api private marker. It’d shift responsibility to the module authors but IMHO that’s the right thing to do. This is not possible now.
What do you think about having this setting in /etc/foreman-proxy/settings.d/puppet.yml instead of /usr/share/foreman/config/ignored_environments.yml?
Could the proxy be configured somehow from Foreman? I can imagine proxy would read the ignore list from Foreman. That way, all puppet proxies share the same configuration. And it’s much nicer from user point of view I think.
My reasoning was that there might be differences in how environments are operated. Ideally, you can trust the module owners to indicate what’s private. Then the environment owner might indicate how that environment is arranged. For example, they only want to use profile_* where a different department might want to use profile::*. The only thing that sort of has an idea about these concepts is IMHO the proxy. Another benefit is that the proxy doesn’t have to send everything over to the Foreman server itself.
The configuration could be interesting though. We could extend the Proxy Puppet API to accept a filter. That would allow central configuration if we wanted to.
My question to @mikehurn and @Dirk (and others) is: where would you expect this sort of configuration?
Most environments I know have similar style guides for all users, so one global option would be enough and one per environment or Smart Proxy is perhaps to much. Also having the setting near to the import like @mikehurn mentioned is where more people will recognize it.