On Thu, Nov 18, 2010 at 10:04 AM, byron appelt <byron.app...@gmail.com> wrote:
> I'm sure I don't understand something here, but when I look at the
> value of the facts on the puppetmaster, they are strings and some of
> them are false. I know the fact is coded to return a boolean, but I
> assumed there is a to_s occurring somewhere along the way. See below
> (hostnames altered to protect the innocent)
>
> r...@puppetmaster:/var/lib/puppet/yaml/facts# grep init *
>
> xxx1.numerexfast.com.yaml: gw_init_script_exists: "true"
> xxx2.numerexfast.com.yaml: gw_init_script_exists: "true"
> xxx3.numerexfast.com.yaml: gw_init_script_exists: "false"
> xxx4.numerexfast.com.yaml: gw_init_script_exists: "true"
> xxx5.numerex.com.yaml: gw_init_script_exists: "false"
>
> Doesn't this mean that the fact has a value even if the file does not
> exist? I will try your suggestion of returning a string explicitly to
> see if that is in fact the problem.
I've just been informed that we did at some point start converting all
facts to strings, but that there have been some edge cases where this
didn't necessarily happen.
It looks like you're not suffering that, so I must have pointed you in
the wrong direction.
When you run the client in debug/verbose mode, are you seeing the
custom fact get synced down at the start of the run, and then sent up
to the server?
>
> -Byron
>
> On Nov 18, 10:59 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
>> On Thu, Nov 18, 2010 at 6:46 AM, byron appelt <byron.app...@gmail.com> wrote:
>> > I am delivering the fact with pluginsync, but that will not have
>> > occurred yet on bootstrap because puppet has yet to run for the first
>> > time and deliver the fact. At least that is what I think is happening.
>> > If I do a run that does not include the class referencing the fact
>> > first, it will work fine on subsequent runs.
>>
>> That's not the case Byron.
>>
>> When the client starts a run, it does a pluginsync, which will bring
>> down facts, types and providers.
>>
>> The facts are then evaluated, and sent to the server in the same run.
>>
>> Are you delivering the file "/etc/init.d/ublipgw.sh" with Puppet?
>>
>> Something that may not be obvious is that your current fact returns a
>> boolean. Right now I suggest to people that they make all their facts
>> strings, and for booleans, return the strings "true" or "false".
>>
>> If that file doesn't exist, $gw_init_script_exists will not have a
>> value, thus the template will error. Until Facter supports rich data
>> types, you should return a string.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > Here is the fact, in case it is relevant:
>>
>> > Facter.add("gw_init_script_exists") do
>> > setcode do
>> > FileTest.exist?("/etc/init.d/ublipgw.sh")
>> > end
>> > end
>>
>> > On Nov 17, 8:48 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:
>> >> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt <byron.app...@gmail.com>
>> >> wrote:
>> >> > I am using a fact inside of a template. The problem I am running into
>> >> > is that the bootstrap run of puppet fails with the following error:
>>
>> >> > err: Could not retrieve catalog from remote server: Error 400 on
>> >> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
>> >> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
>> >> > manifests/classes/base_gateway/manifests/init.pp:35
>>
>> >> > because the facts do not exist yet. I have worked around this by
>> >> > placing an if statement around the resource that renders the template
>> >> > like so:
>>
>> >> > if $gw_init_script_exists {
>>
>> >> > file { "/etc/monit.d/ublip_gw.monitrc":
>> >> > content => template("base_gateway/ublip_gw.monitrc.erb"),
>> >> > }
>>
>> >> > }
>>
>> >> > While this works it is not a very elegant solution. Is there a better
>> >> > way of dealing with this situation?
>>
>> >> Why doesn't the fact exist yet?
>>
>> >> Are you delivering a fact via pluginsync, but that fact itself relies
>> >> upon an executable script that you're delivering with Puppet ?
>>
>> >> Can you post the fact itself?
>>
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "Puppet Users" group.
>> >> > To post to this group, send email to puppet-us...@googlegroups.com.
>> >> > To unsubscribe from this group, send email to
>> >> > puppet-users+unsubscr...@googlegroups.com.
>> >> > For more options, visit this group
>> >> > athttp://groups.google.com/group/puppet-users?hl=en.
>>
>> >> --
>> >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Puppet Users" group.
>> > To post to this group, send email to puppet-us...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > puppet-users+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/puppet-users?hl=en.
>>
>> --
>> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>
--
Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
