On 16/12/11 19:48, Tim Mooney wrote:
> In regard to: Re: [Puppet Users] new user: need Conditional statement...:
>
>>> Obviously I had a syntax error here because case statement is not
>>> happy within the resource.
>>
>> That's why the documentation says to use a selector.
>>
>>> So, what's a recommended puppet way to do something like this? thx in
>>> advance.
>>
>> file {
>> "somefile" :
>> ensure => $hasfile ? {
>> "true" => present,
>> default => absent
>> },
>> source => "puppet:///somefile",
>> owner => "root",
>> }
>>
>> Please note that "true" is not strictly equivalent to the bareword true
>> in the puppet language :)
>
> Ah, perfect segue. I had been meaning to follow up to John Bollinger
> when he earlier posted something similar that also had 'true' quoted.
>
> I've been through the style guide and several other areas in the
> documentation and I can't find any recommendations on whether it's better
> to use bare
>
> true
> false
>
> or whether it's better to quote them. This is specifically for use in
> parameterized classes. For example:
>
> foo.bar.edu.pp:
>
> node 'foo.bar.edu' {
>
> class {'rhel':
> version => '5',
> ipv6_enabled => true,
> }
> }
>
> rhel/manifests/init.pp:
>
> class rhel($version, $ipv6_enabled='default') {
> include rhel::common
>
> case $ipv6_enabled {
> true: {
> class {'network': ipv6 => true }
> }
> false: {
> class {'network': ipv6 => false }
> }
> default: {
> case $version {
> '5': {
> class {'network': ipv6 => false }
> }
> '6': {
> class {'network': ipv6 => true }
> }
> default: { fail("only version 5 and 6 of rhel are currently
> supported")}
> }
> }
> }
> }
>
>
> In other words, our default for RHEL 5 is ipv6 disabled, on RHEL 6 it's
> ipv6 enabled, but the default can be overridden for either.
>
> The problem is that we had to be very careful to make certain that we
> didn't quote true or false in some places and leave them as barewords
> elsewhere, or it just wouldn't work. Mixing quoted & nonquoted gave us
> unreliable and unexpected results.
Exactly. If you intend your options to be boolean use the barewords true
and false.
> This brings me back to the questions: where in the docs is this covered,
> and what are the recommendations for whether we should (or shouldn't) be
> quoting true & false when passing them around into parameterized classes
> and testing them in selectors?
I don't know if it's covered in the documentation.
Puppet has the notion of true/false (ie the boolean). Any puppet
conditional expression can evaluate to either true or false.
On the other hande "true" is a string containing the word true. "false"
is a string containing the word false. It is not a boolean.
But that's where things get difficult:
if "false" {
notice("false is true")
}
This will print "false is true".
The same for
$str = "false"
if $str {
notice("false is true")
}
But,
case $str {
true: { notice("true") }
false: { notice("false as bool") }
"false": { notice("false as str") }
}
will print "false as str". So "false" != false and is not == to true.
But when converted as a boolean any strings becomes true, and that's
what happen in our if example.
We track this issue in the following ticket:
http://projects.puppetlabs.com/issues/5648
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
