perhaps not puppet but facter which I think always returns things as strings -
definitely a point of confusion but understandable when you think about it.
Craig
On Dec 16, 2011, at 1:15 PM, Trevor Vaughan wrote:
> I tend to quote all used of 'false' and 'true' mainly because
> sometimes the guts of puppet seem to give me back a string no matter
> what I want and a bareword won't work.
>
> I don't have examples offhand and it's possible that this was fixed
> some time in the past.
>
> Trevor
>
> On Fri, Dec 16, 2011 at 2:16 PM, Brice Figureau
> <brice-pup...@daysofwonder.com> wrote:
>> 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.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaug...@onyxpoint.com
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> 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.
>
--
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.wh...@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com
Need help communicating between generations at work to achieve your desired
success? Let us help!
--
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.
