Puppet users - Nov 2007 - How to keep several puppetd in sync at the same time ?

Hi,

I''m still writing my djbdns module, I came to the following design
issue
with master and slave tinydns.

Normally there is no such master and slave distinction in djbdns: all
tinydns instance are equal. Usually one instance on one host is
considered the master on, which the RR are changed, and when you need to
propagate them, you rsync the datas to the other hosts, where they will
be picked up.

Now, when porting this scheme to puppet I also use the rsync way of
doing things (but automate the distribution of ssh key from master to
slave''s authorized_keys with the help of exported resources), something
along the line of this puppet pseudo code:

class djbdns {
  # creates a tinydns instance listening on $ip
  define master($ip, $data) {
    ...
    file { "/path/to/data": source => $data }
    ...
    exec { "propagate-${name}":
      command => "rsync to slaves",
      subscribe => File["/path/to/data]
    }
    ...
  }

  # creates a tinydns instance listening on $ip
  define slave($ip) {
    ... same def as master but without the above file and exec...
  }
}

I find this scheme overly complex to maintain (especially if I have to
export masters ssh public keys to slaves and export slaves ip to their
belonging masters)...

I first thought to have all the tinydns instance equals (all master
using the same data file), but since I don''t know when each puppetd
will
synchronize to the puppetmaster, my instances could well serve stale
data for as most as the time between two synchronize run. (Is there any
documentation somewhere that explains the synchronization process?)

Can you think about a more puppet-like way of doing things which
guarantees each puppetd can see the same data file at about the same
time ?

Thanks,
-- 
Brice Figureau <brice+puppet@daysofwonder.com>

On 11/12/2007 3:19 AM, Brice Figureau wrote:
> Can you think about a more puppet-like way of doing things which
> guarantees each puppetd can see the same data file at about the same
> time ?
Schedule: http://reductivelabs.com/trac/puppet/wiki/TypeReference#id41

schedule { veryoften:
     period => hourly,
     repeat => 6
}

exec { "someupdater":
     schedule => veryoften
}

The above will run "someupdater" up to 6 times per hour, which if the 
update procedure is quick enough, would mean nobody is more than 10 
minutes out of sync with anyone else.

-- 
Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

From the link,
"The important thing to understand about how schedules are currently
implemented in Puppet is that they can only be used to stop an element
from being applied, they never guarantee that it is applied."

A schedule does not say this will happen this often, it says this can
not happen more than this often.  Thus with the default half hour
updates the proposed schedule would not have any effect and the
maximum out of date time would be 30 minutes.  You can however
increase the poll time for puppetd by configuring the runinterval
(http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference).
Then you could use schedules to limit how often less volatile
resources are checked.

Another option for triggering a sync would be to use puppetrun,
however this would require you to have the appropriate ssl certs
distributed.

Thanks
Brian

On Nov 12, 2007 8:31 AM, Mike Renfro <renfro@tntech.edu>
wrote:
> On 11/12/2007 3:19 AM, Brice Figureau wrote:
> > Can you think about a more puppet-like way of doing things which
> > guarantees each puppetd can see the same data file at about the same
> > time ?
>
> Schedule: http://reductivelabs.com/trac/puppet/wiki/TypeReference#id41
>
> schedule { veryoften:
>      period => hourly,
>      repeat => 6
> }
>
> exec { "someupdater":
>      schedule => veryoften
> }
>
> The above will run "someupdater" up to 6 times per hour, which if
the
> update procedure is quick enough, would mean nobody is more than 10
> minutes out of sync with anyone else.
>
> --
> Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
> 931 372-3601 / Tennessee Technological University
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>