On Apr 18, 2010, at 1:17 AM, Mayank wrote:
> On Sun, Apr 18, 2010 at 8:45 AM, Nigel Kersten <nig...@google.com> wrote:
> On Sat, Apr 17, 2010 at 6:21 PM, Douglas Garstang
> <doug.garst...@gmail.com> wrote:
> > On Thu, Apr 15, 2010 at 8:44 AM, Jim Bala <usr...@gmail.com> wrote:
> >> On Apr 15, 2010, at 1:30 AM, Mayank wrote:
> >>
> >>> Hi,
> >>> I'm trying to manage some hosts using a single puppetmaster. I
> >>> don't know why but puppet on clients seems to be executing the recipes
> >>> hosted on puppetmaster in a random order which is breaking apart
> >>> dependencies and resulting in a failed run of puppet for first time.
> >>> If I do multiple run of puppet thru puppetd --test, everything gets
> >>> installed and configured properly. However it's very rare that on
> >>> first run I can see puppet managing the configuration and installation
> >>> without fail.
> >>> Is there any way I can bring about serial execution of puppet
> >>> recipes. What I mean by serial execution is that suppose I've a
> >>> site.pp with following content:
> >>>
> >>> package {"ruby-devel": ensure=>latest}
> >>> package {"rubygems": ensure=>latest}
> >>> exec {"install-mysql-gem":
> >>> command=>'gem install mysql',
> >>> path=>"/bin:/usr/bin:/usr/sbin:/sbin",
> >>> require=>[ Package["ruby-devel"], Package["rubygems"]]
> >>> }
> >>>
> >>> Now in many cases puppet tries to execute Exec["install-mysql-gem"]
> >>> before Package["ruby-devel"] or Package["rubygems"] or both.
> >>>
> >>> Is there a way that I can ensure that puppet renders the file in order
> >>> the script is written ?
> >>>
> >>> BTW I'm using CentOS 5.4 with puppet-server-0.24.5-1.el5 and
> >>> puppet-0.24.5-1.el5.
> >
> > Keep at it. You'll get it all working with requires=> eventually. It
> > will take forever, your head will hurt, and by the time your done,
> > you'll have a god-aweful dependency mess that will make you totally
> > afraid to touch any of it ever again, but you'll get it eventually if
> > you keep at it! I did!
>
> So we went there with the more complicated parts of our config, and
> then I came back to sanity, with enforcing this really really simple
> rule on all our commits. As intra-class require/before statements can
> only refer to individual resources. (by definition), the rule is that:
>
> Inter-class require/before statements can only refer to whole classes,
> never ever individual resources within those classes.
>
>
> I mean this is all good programming practice, but it's not something
> people always keep in mind when putting out an ops fire and checking
> fixes in, but it really makes your dependency situation so much
> cleaner. You have well defined interfaces between objects, and you're
> free to change internal behavior as you need to without being afraid
> to touch stuff.
>
>
> >
> > Doug.
> >
> >
> >
>
>
>
> --
> nigel
>
>
> I can't take chances with re running puppet as what I am trying to accomplish
> is complete automation of a setup on EC2. I've a script which fires up new
> instances on EC2. These instances are built using custom AMI (machine images)
> which have entry for puppetmaster in /etc/hosts and have puppet installed on
> 'em. I am running puppetd --test thru rc.local and since my puppetmaster is
> configured to autosign, hence I need this first run of puppetd --test to get
> the job done. As entire setup is automated so I can't wait for multiple runs
> of puppet before everything gets installed properly. I've tried to make a
> dependency tree which should work out for me and will be testing it in next
> 20 min .... Will revert back with any updates in case something fails this
> time... I need this first run of puppet to run without fail for me... Praying
> to God this time to make it a success :)
If you need it to work that bad, you could probably put more than one run in
your initialization script. Also, if you send the second log somewhere, you
can improve it over time. You'll probably want to make it runs with the cache
though if you're worried about performance. Remember that "--test" removes
caching. I use "puppetd --onetime --verbose --no-daemonize".
-Patrick Mohr
--
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.
