On Tuesday, October 27, 2015 at 4:03:33 AM UTC-5, Aurélien Degrémont wrote:
>
> Hello
>
> When using class parameters I often face the same issue regarding undef
> usage.
> Let's say I got this simple class:
>
> class foo (
> $service_ensure = 'running',
> ) {
> service { 'foo':
> ensure => $service_ensure;
> }
> }
>
>
> include foo # will set the service running
>
>
> class { 'foo':
> service_ensure => 'stopped'; # will set the service stopped
> }
>
>
> And now, I would like to say 'do not care about ensure'. Do not touch it.
>
> For that, I need that ensure is set to 'undef'
>
The easiest way to approach the problem is to default to not managing
whether the service foo is running, or else to avoid declaring class foo at
all on machines where you don't care about the state of the resources it
manages.
>
> But I cannot use:
>
> class { 'foo':
> service_ensure => undef;
> }
>
> because in this case, Puppet will use the default value of the
> parameter, in this case: running.
>
> I have this problem for a lot of different modules and I looking for a
> simple way to do this.
> I would like to avoid adding an if/else in all my classes.
>
>
Bad news: undef is not a value, so you cannot pass it or assign it.
Accepted forms that look like assigning or passing undef have the effect of
undefining an existing definition or affirming that none is given. If you
want such behavior to be available, but not to be the default, then you
pretty much need conditional logic. The traditional form of this usually
goes the other way, but here's how you could apply it to your situation:
class foo ($service_ensure = 'running') {
service { 'foo':
ensure => $service_ensure ? { 'UNDEF' => undef, default =>
$service_ensure }
}
}
On the other hand, there are ways to shift around the location of the
conditionality. The forms most likely to suit you involve overriding
resource properties
<https://docs.puppetlabs.com/puppet/4.2/reference/lang_resources_advanced.html#adding-or-modifying-attributes>.
You can do that anywhere, for any resource, via a resource collector, but
I'm a fan employing a bit of discipline and using classification to control
such things. That requires using class inheritance (and this is the
original and most appropriate use case for class inheritance). To approach
the problem that way, you would add a class alongside to your original one:
class foo (
$service_ensure = 'running',
) {
service { 'foo':
ensure => $service_ensure;
}
}
class foo::unmanaged inherits foo {
Service['foo'] {
ensure => undef
}
}
Declaring class foo::unmanaged either instead of or in addition to class foo
will then have all the effects of declaring class foo, except that the
ensure property of Service['foo'] will be as if never declared. In this
case, the conditionality is pulled up to wherever you decide whether to
declare class foo::unmanaged, and that can be all the way to the ENC / node
block selector, so that it does not correspond to any explicit conditional
in your DSL code.
There are other ways to approach the problem as well, mostly revolving
around using Hiera for binding data to your class parameters (which is
absolutely the only way you should *ever* assign non-default parameters to
your modules' public classes). It's not straightforward in Hiera, however,
because as far as I know, Hiera does not provide a means to override a
property mapping with absence of any mapping.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5543f502-4498-436c-80af-0bf695eaab4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
