chicken and the egg.. pushing custom facter plugins for use within puppet..

[Michael Dodwell]

Hi,

I've created a number of custom facts that i've added to manifests. If
i add the custom fact, have puppet push the custom fact file to the
host, then after it's pushed it add it to the templates everything
works fine. However if i try and use the module on a fresh host
without the custom facter it fails. When it looks at the templates it
isn't aware of the custom fact yet and errors out.

How can i get it to pull down the facter plugin before it tries to
read the template file?

I have tried:

file {
"/etc/somefile":
owner => root,
group => root,
mode => 644,
require => File["/usr/lib/ruby/1.8/facter/custom_fact.rb"],
content => template("module/etc/somefile");
}

Any suggestions? I'd prefer not to have to add the custom facter to
the kickstart/jumpstart enviroment.

--MD

[Nan Liu]

This is solved with pluginsync option. Puppet will download any custom
facts/providers, so you should not distribute them to the agent as
file resources.

Thanks,

Nan

[Disconnect]

Although good advice (pluginsync is win) that still doesn't solve the chicken/egg problem - puppet won't evaluate the new facts on the first run.

We work around it by checking the existence of the fact/value before using it. Not ideal but it works. (And on brand new hosts, we run puppetd -t --tags no_such_tag to get the sync done. We actually do it twice, so that the new values are pushed up to the puppetmaster before the 'real' run, but that probably isn't strictly necessary.)

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Nan Liu]

On Wed, May 4, 2011 at 10:01 AM, Disconnect <dc.dis...@gmail.com> wrote:
> Although good advice (pluginsync is win) that still doesn't solve the
> chicken/egg problem - puppet won't evaluate the new facts on the first run.

Pluginsync should occur before facter executes and facts get submitted
to the server, so it should not be necessary to run puppet twice. Any
more info about your puppet version and system setup?

[Michael Dodwell]

> We work around it by checking the existence of the fact/value before using it

Is this done in the template file or somewhere else? Can you please
supply dummy code as an example?

Thanks

[Disconnect]

Couple quick examples. In the dpkg/apt module:
if ($lsbdistcodename == '') {
        err("LsbDistCodename not set on $fqdn. Not configuring apt!")
} else {

Or use '': in a case statement, eg:
case $foo {
  '1': { foo }
  '': { undefined }
  default: { other }
}

I'm having trouble finding specific examples in our current setup - I've been moving away from it in favor of running with pluginsync and --tags no_such_tag (so the problem doesn't come up as often.)

We used to have at least one template example but I can't find it.. :/

[Nan Liu]

On Tue, May 10, 2011 at 3:16 PM, Disconnect <dc.dis...@gmail.com> wrote:
> Couple quick examples. In the dpkg/apt module:
> if ($lsbdistcodename == '') {
>         err("LsbDistCodename not set on $fqdn. Not configuring apt!")
> } else {
>
> Or use '': in a case statement, eg:
> case $foo {
>   '1': { foo }
>   '': { undefined }
>   default: { other }
> }

Ah, in this case lsbdistcodename is dependent on lsb packages. Yeah,
unfortunately this can't be solved with pluginsync, since pluginsync
doesn't install packages. This is one package I would suggest
including in the base image.

Pluginsync takes care of facts written purely in Ruby, so I did not
consider these other cases and I don't have a good solution for facts
with external dependency. Maybe tag resources required for facts and
run puppet agent -t --tags plugins. Definitely open for other better
solutions.

Thanks,

Nan