As we are about to make Puppet optional we’ve hit a discussion about Puppet environments being quite often abused for other purposes and I’d like to propose a global environment concept being kept in Foreman core.
I’d like to hear if it would make sense and at the same time hear how to go about it.
My thinking is leaving the Environmnets in Foreman, just extracting the puppet relations, that would be added from Puppet plugin.
This is implying puppet environment == puppet environment. Only change would be to stop removing environments from puppet imports when there are no puppet classes mapped to such environment and we would allow environments to get assigned to Hosts without Puppet proxy.
But there are two other major ways to go about it:
Get rid of global environments
Introduce new environment and add mapping 1:N for puppet environments
Please share your opinions, what would be the most usefull for us going forward.
If you have completely different solution, feel free to share it as well obviously
Best approach to global environments
Global = puppet environment
No global environment
Global independent of puppet environment
I don’t care about environments, stop asking me boring questions in polls
I would say for a system using Puppet it should be that Global environment is the Puppet environment and they are imported exactly (or at least) similar to now.
If I remember correctly we already discussed similar to this in Brno in 2019 and came to the conclusion that also Ansible which does not have the concept of environments would benefit if Foreman adds this to it so you can stage and test Ansible roles/collections in your environment.
Another environment we have is the Lifecycle environment in Katello while I prefer it to be the same like Puppet, so others prefer to stage Puppet code independently from Software installed and regardless of which concept you prefer at least for testing there will be more Puppet environments than Lifecycle ones.
So having a Global one which will be default for the others could be nice and clean up the UI for normal users, but advanced users will likely need to override sub-environments.
Before I vote, what would be the value of global environment object? What use cases it would solve outside of puppet? What is the relation to lifecycle enviornment of Katello? If that’s meant for labelling a host as production vs testing and allowing me to search by that, perhaps we should finally implement a simple tagging instead.
Unfortunatelly I do not have clear answers here, I can present some.
Lifecycle environment should benefit by being able to rely on such environments as it can be created without worying puppet is going to remove them later.
Today we have possibility to have different provisioning templates per environment and thus provisioning can completely differ for each env (due to templates combinations) but that could probably rely on tags instead.
Most of other usecases is indeed achievable by having tagged hosts as well.
The main advantage of environment is that it is much more clear concept to users IMHO - meaning user can more easily imagine what could environment be used to.
On the contrary for Foreman and its users the term environment has already quite a historical baggage.
Ondrej reminded me host group based provisioning (aka template combinations) feature we still have, that depends on environments. I think for people who still rely on it, they can use pure host groups for that, no need for puppet environment. I would lean towards first extracting everything related to existing environment to a plugin, because it is puppet environment. If we see a good usecase for something that’s not a tagging and would benefit from first class citizen object, I’m all in. But I think cleanup of (old, puppet) environment from the codebase, API is a good first step. Only then we should introduce a new object of (probably) the same name but with a different meaning.
What is ‘global environment’ going to be used for?
In a modern puppet workflow, puppet ‘environments’ are no longer used for ‘server environments’ (prod, test, qa etc.) Instead, they just represent a branch of puppet code, (usually short a lived branch where new puppet code is developed/tested). Some people still use them to mean ‘server environment’, but that’s not so common, or just a newbie ‘misktake’ caused by the terminology implying that that’s what you should use them for.
When I say ‘modern puppet workflow’, I should probably point out that it’s not that modern anymore. This 6 year old post sums up why ‘environments’ was a bad name for ‘puppet environments’ very well. http://garylarizza.com/blog/2014/03/26/random-r10k-workflow-ideas/
FWIW, I voted for ‘Global independent of Puppet environment’, but actually, I think ‘No global environment’ also works for me. In this scenario, if you didn’t install the puppet plugin, there would be no concept of environments in Foreman at all?
That is my understanding. If you have a good use case of general purpose environments which couldn’t be achieved through tagging or some other object we already have (host group, parameter, organization, location), we’d like to hear it.
I’m not sure if we have enought to state anything clearly from this, but I believe that the best way is what @Marek_Hulan is mentioning - remove the Environment we currently have to a plugin to remove its historical baggage it has and to define new (global) Environment once we are set on what that Environment should stand for.
It seems to me, that althoug easiest way from developers perspective would be to keep it, we should remove it from core for now first no matter what we end up doing in the future.
