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?
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Wed, Nov 17, 2010 at 1:05 PM, byron appelt <byron.appelt@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.
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-users@googlegroups.com.
> > To unsubscribe from this group, send email to
puppet-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Thu, Nov 18, 2010 at 6:46 AM, byron appelt <byron.appelt@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-users@googlegroups.com. >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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) root@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. -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-users@googlegroups.com. > >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Nov 18, 2010 at 10:04 AM, byron appelt <byron.appelt@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) > > root@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-users@googlegroups.com. >> >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I figured it out. I do not see the facts being synced on the bootstrap run and I no know why. Since I am using puppet to configure itself, there is no puppet.conf on the bootstrap run and therefore no pluginsync=true. I just have to do the bootstrap run with the -- pluginsync option and all is well now. Thanks for all your help Nigel, I would not have figured it out alone. -Byron On Nov 18, 1:03 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:> 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) > > > root@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-users@googlegroups.com. > >> >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Nov 18, 2010 at 12:21 PM, byron appelt <byron.appelt@gmail.com> wrote:> I figured it out. I do not see the facts being synced on the bootstrap > run and I no know why. Since I am using puppet to configure itself, > there is no puppet.conf on the bootstrap run and therefore no > pluginsync=true. I just have to do the bootstrap run with the -- > pluginsync option and all is well now. > > Thanks for all your help Nigel, I would not have figured it out alone.No worries. Glad you worked it out. Ideally we''d like to be able to move to pluginsync by default, but there are a few issues around this that need to be resolved before we can do that.> > -Byron > > On Nov 18, 1:03 pm, Nigel Kersten <ni...@puppetlabs.com> wrote: >> 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) >> >> > root@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-users@googlegroups.com. >> >> >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. >> >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.