The Road to Making Puppet Optional

Correct, but I’m not sure if it’s implemented today and must be verified.

Not with our current implementation. This could be fixed (if it needs fixing) by proxying the requests via smart-proxy as we’ve already discussed.

It works as I’ve used it for foreman_omaha. If you want to verify it yourself:

Hi everyone,
I have been working on Hammer and the V2 API of the new Foreman Puppet plugin, and I am looking for a more concrete direction to go:

Users of Puppet should not see a deterioration in their workflows - ideally, some workflows would even see an improvement.

Taking this quote from @tbrisker, I would assume that the main objective is to keep the new Puppet Plugin API as similar to the old one as possible. Ideally, it has exactly the same interface and the user will never notice a difference.

Advantages:

  1. No changes for Hammer-related interface
  2. No changes for FAM
  3. No changes for Foreman users that use the API directly.

Disadvantages:

  1. Implementation is a little bit messy for Foreman 2.X as functionality from Foreman core needs to be overwritten by the plugin.
  2. Changes to the API might bring advantages for the new hammer-cli-foreman-puppet plugin.
  3. We might miss a chance to clean up the API (in case this is necessary).

As of now, the implementation aims to go somewhere in between by prepending the current API commands with foreman_puppet, e.g. foreman_puppet/api/.... This is done in other Foreman plugins as well. As consequence, people using the API directly are the ones eventually “suffering”.

Please correct me if anything I wrote is not correct.

So the remaining question is:

  1. Continue with the current implementation?
  2. Move towards a complete copy of the current Foreman core API?
  3. Add any other changes to the new API?

Thank you for your thoughts!

2 Likes

Thanks for raising the concern @nadjaheitmann !
Currently, the new plugin still supports the old API endpoints as well, only logging a deprecation warning when users use them instead of the namespaced ones:

This means that users will have time to update any scripts or tools to use the new endpoints instead of the old ones and will not have a breaking change until we actually drop support for the non-namespaced endpoints.
We can certainly consider making changes to the API in the future if we feel it is needed, but I would suggest to avoid any breaking changes right now as the move to the plugin is a big enough change already.

2 Likes

I was already hitting issues with these smart varibles and them over riding anything in hiera. Is the hostgroup way of selecting classes staying?

We have started to move away from setting hostgroup varibles via foreman and redesigned the Hiera a little have an extra lyer for hostgroups

extract here , this is getting hostgroup fact, will this still be around in the newer versions.

" - name: “Hostgroup level settings/overrides YAML”
data_hash: yaml_data
paths:
- “environment/%{::environment}/roles/%{::hostgroup}.yaml”

We put this just before any node over ride and after env , default

I test and build foreman a lot with my dev platform, we also use it in prod rather extensivily.

steve