This is going to be really hard to explain but in the environment that I am
working we distribute puppet classes and use the foreman API to set almost
all parameters to be override-able by default. Since the defaults are
potentially different for different versions of our classes we create a
catch-all matcher when we say that the class is overridable, based on the
environment.
The trouble is that our users need to be able to override this matcher on a
per environment basis and not lose their changes the next time our API
script runs.
TLDR: we need to have matchers based on the environment twice. Once for the
defaults for the environment and once for user-set parameters for the
environment.
The way this has been done until now is a dirty custom fact generated by
looking for the environment in puppet.conf. This has worked but can cause
issues if the environment of a host changes so I'd like to improve things.
The simplest way that I can see would be to use the foreman_env server-side
fact (which is essentially a duplicate of 'environment') but I cannot get
the override value to work with either 'foreman_env' or
parameters["foreman_env"].
Is the foreman_env variable available to use as a matcher? Or a better way
to duplicate the environment fact?
···
On Tuesday, 4 November 2014 15:49:06 UTC, Jeff wrote:
>
> This is going to be really hard to explain but in the environment that I
> am working we distribute puppet classes and use the foreman API to set
> almost all parameters to be override-able by default. Since the defaults
> are potentially different for different versions of our classes we create a
> catch-all matcher when we say that the class is overridable, based on the
> environment.
>
> The trouble is that our users need to be able to override this matcher on
> a per environment basis and not lose their changes the next time our API
> script runs.
>
> TLDR: we need to have matchers based on the environment twice. Once for
> the defaults for the environment and once for user-set parameters for the
> environment.
>
> The way this has been done until now is a dirty custom fact generated by
> looking for the environment in puppet.conf. This has worked but can cause
> issues if the environment of a host changes so I'd like to improve things.
> The simplest way that I can see would be to use the foreman_env server-side
> fact (which is essentially a duplicate of 'environment') but I cannot get
> the override value to work with either 'foreman_env' or
> parameters["foreman_env"].
>
> Is the foreman_env variable available to use as a matcher? Or a better way
> to duplicate the environment fact?
>
> Thanks
> Jeff
>
overriding at the pure 'environment' level works but if i create a matcher
(all_environments=true) i get the value from the
'environment,all_environments' matcher. Without the 'all_environments'
matcher it all works as expected
Thanks again
Jeff
···
On Friday, 7 November 2014 10:03:51 UTC, ohad wrote:
>
> Would a double matcher work?
> E.g.
> Order:
> Environment, something else
> Environment
>
> And then on your matchers you can create on or more based on the env or
> env, something else?
>
···
On Friday, 7 November 2014 11:08:28 UTC, Jeff wrote:
>
> Ah, didnt realise that was possible. It should work but I'm seeing some
> odd behaviour.
>
> First question - does the matchers support wildcards (eg environment=*)? I
> couldnt get it to work so assume not.
>
> I have created a custom fact called 'all_environments' which is always
> true. My matcher order is...
>
> fqdn
> hostgroup
> environment
> all_environments
> environment,all_environments
>
> overriding at the pure 'environment' level works but if i create a matcher
> (all_environments=true) i get the value from the
> 'environment,all_environments' matcher. Without the 'all_environments'
> matcher it all works as expected
>
> Thanks again
> Jeff
>
> On Friday, 7 November 2014 10:03:51 UTC, ohad wrote:
>>
>> Would a double matcher work?
>> E.g.
>> Order:
>> Environment, something else
>> Environment
>>
>> And then on your matchers you can create on or more based on the env or
>> env, something else?
>>
>
> Ah, didnt realise that was possible. It should work but I'm seeing some
> odd behaviour.
>
> First question - does the matchers support wildcards (eg environment=*)? I
> couldnt get it to work so assume not.
>
no, but there is an open issue for that.
>
> I have created a custom fact called 'all_environments' which is always
> true. My matcher order is…
>
> fqdn
> hostgroup
> environment
> all_environments
> environment,all_environments
>
> overriding at the pure 'environment' level works but if i create a matcher
> (all_environments=true) i get the value from the
> 'environment,all_environments' matcher. Without the 'all_environments'
> matcher it all works as expected
>
hmm… this should work, are you sure your facts are uploaded prior to the
enc request?
···
On Monday, 10 November 2014 09:45:01 UTC, ohad wrote:
>
>
>
> On Fri, Nov 7, 2014 at 1:08 PM, Jeff <je...@potchin.co.uk > > wrote:
>
>> Ah, didnt realise that was possible. It should work but I'm seeing some
>> odd behaviour.
>>
>> First question - does the matchers support wildcards (eg environment=*)?
>> I couldnt get it to work so assume not.
>>
> no, but there is an open issue for that.
>
>>
>> I have created a custom fact called 'all_environments' which is always
>> true. My matcher order is...
>>
>> fqdn
>> hostgroup
>> environment
>> all_environments
>> environment,all_environments
>>
>> overriding at the pure 'environment' level works but if i create a
>> matcher (all_environments=true) i get the value from the
>> 'environment,all_environments' matcher. Without the 'all_environments'
>> matcher it all works as expected
>>
>
> hmm.. this should work, are you sure your facts are uploaded prior to the
> enc request?
>
> if it is, please open a bug.
>
>
>
