If I understand the OPs question correctly, he has an ordering problem:
some services aren't waiting for other services to come online before
starting themselves?
If that's the case, you handle this with dependencies and chaining, e.g.
service { fast_service: require => Service['slow_service']...}
If the real issue is that the initial startup of a service involves a long
initialization process, then you need to insert some kind of test in
between the two services that verifies the slow service is truly up and
running, e.g.
exec { slow_service_check: require => Service['slow_service'], command =>
"process that will wait for the slow service"...}
service { fast_service: require => Exec['slow_service_check']...}
If the real issue is that the slow service takes longer than puppet_timeout
to complete its startup, then you have an insurmountable problem without
either MCollective or multiple puppet runs.
One way to address this with multiple puppet runs involves having a
progression of environments (assuming this happens once on provisioning and
never again). Essentially, you have systems boot up into a "provisioning"
environment, where puppet runs, say, every 5 minutes. Then you have your
ENC set up such that when a provisioning run completes with no changes, it
switches to a "longterm" environment, which is generally much more
lightweight and runs puppet on a slower schedule (e.g. once a day outside
of business hours). This methodology can make the majority of your puppet
runs very lightweight and fast (which can matter if you are paying for CPU
cycles), but requires that everyone be good citizens who never change a
system without using Puppet.
On Wed, Jul 11, 2012 at 7:12 AM, Trevor Vaughan <tvaug...@onyxpoint.com>wrote:
> Hi Dave,
>
> This is definitely not a dumb question. I wrote a post on what I
> thought a puppet semaphore system should do quite some time ago.
> Unfortunately, you don't really want to hang an instance until the
> semaphore flips so you end up having to wait through puppet runs.
>
> If you've got a solid SSH infrastructure working, then I would suggest
> looking at something like Capistrano or Func to give you that one-off,
> lightweight punch that you need.
>
> The big thing to watch out for is that you need to make sure that your
> manifests work properly even if they don't run in order since your
> nodes will be calling in over time.
>
> One way of doing this is to use a custom fact and drop a file onto the
> system when you're ready for that extra bit to run or have it based on
> hitting the remote system to see if your target service is actually
> functional.
>
> Ideally though, the startup scripts for the different services would
> be smart enough to figure out if the environment is ready for them to
> run. The puppet can do what it does best and the services can merrily
> go on their way trying to come up until they succeed (or ultimately
> fail).
>
> Trevor
>
> On Tue, Jul 10, 2012 at 2:39 PM, Dave Anderson <dave.ander...@ammeon.com>
> wrote:
> > Hi
> >
> > I have a resource that is slow to come into service and I have other
> resources that are dependent on the service in order to be configured. I've
> been searching for the "puppet way" to do this, but all the options I've
> found don't seem optimal, so I'm assuming there is a better way that I'm
> missing.
> >
> > I have several instances, so I want puppet to kick them off in parallel.
> And I want the reliant services to be configured as soon as possible when
> the slow services are ready
> >
> > So I don't really want to use long timeout/multiple retry because I
> believe that won't be executed in parallel - and anyway, it's not a retry I
> want, it's a wait
> >
> > I don't want to have Mcollective/AMQP just for this one problem, it
> feels like a sledgehammer to crack a nut
> >
> > I don't want some external process to repeatedly kick puppet repeatedly
> until the dependency is resolved and the reliant service can be configured
> >
> > I'm imagining something like a semaphore, puppet sleeps and wakes up
> when the semaphore is flipped (the slow resource is available)
> >
> > Sorry if this is a dumb question, first post etc ...
> >
> > Thanks
> >
> > Dave
> > --
> > This email and any files transmitted with it are confidential and
> intended
> > solely for the use of the individual or entity to whom they are
> addressed.
> > If you have received this email in error please notify the system
> manager.
> > This message contains confidential information and is intended only for
> the
> > individual named. If you are not the named addressee you should not
> > disseminate, distribute or copy this e-mail.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> > To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/zZfbu37DrsQJ.
> > To post to this group, send email to puppet-users@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.
> >
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaug...@onyxpoint.com
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
