Currently the Puppet setting 'remove_classes_not_in_environment' defaults to false.
I suggest that it should default to true and submitted a PR
I discovered this issue while working on PR #1217 for Config groups. Since Config groups are not linked to an environment, I was trying to show in the UI which classes belongs in the environment and which ones don't. Then I discovered that the inherited classes on the UI don't take into account environment. However, the ENC output does take into account using Setting['remove_classes_not_in_environment']. I felt the UI should match the ENC output.
For example, let's say
postgres is in production and development environments
postgres::devel is only in development environment
hostgroup: Base
environment: development
puppetclasses: postgres, postgres::devel
hostgroup: Base/db-server
environment: production
puppetclasses: postgres
The currently UI implementation would show postgres, postgres::devel for Base/db-server even though postgres::devel is not available in production environment
AFAIR, this was added when we added class parameters.
in the old ENC format (pre puppet 2.6.5) puppet would not complain if you
had a class that did not exist (in your env or otherwise).
we've added this functionality, as we didnt want to break (read "change")
anything to existing enc output people had.
However, when using the new ENC format (needed if you use param classes)
then puppet would fail on a missing class.
Normally, this would not be a problem, and the only cases this would
happen is if you have a host and a hostgroup not in the same environment
(or a hostgroup and a parent hostgroup in different envs), with config
groups this is even more visible, therefor I Suggest to turn on this
feature, and even consider removing the setting at all (back then, it was
easier to introduce a new setting then to force a change).
Ohad
···
On Tue, Apr 8, 2014 at 6:23 PM, Joseph Magen wrote:
Currently the Puppet setting ‘remove_classes_not_in_environment’ defaults
to false.
I discovered this issue while working on PR #1217 for Config groups. Since
Config groups are not linked to an environment, I was trying to show in the
UI which classes belongs in the environment and which ones don’t. Then I
discovered that the inherited classes on the UI don’t take into account
environment. However, the ENC output does take into account using
Setting[‘remove_classes_not_in_environment’]. I felt the UI should match
the ENC output.
For example, let’s say
postgres is in production and development environments
postgres::devel is only in development environment
hostgroup: Base
environment: development
puppetclasses: postgres, postgres::devel
hostgroup: Base/db-server
environment: production
puppetclasses: postgres
The currently UI implementation would show postgres, postgres::devel for
Base/db-server even though postgres::devel is not available in production
environment
+1 to forcing it, I don't see any use case where you would want to
include unavailable classes in the ENC.
···
On 9 April 2014 09:20, Ohad Levy wrote:
>I Suggest to turn on this feature, and even
> consider removing the setting at all (back then, it was easier to introduce
> a new setting then to force a change).
