On Mon, Dec 12, 2011 at 11:33:37AM -0800, Daniel Pittman wrote:
> On Fri, Dec 9, 2011 at 22:20, Jo Rhett <[email protected]> wrote:
> >> On Dec 8, 1:07 pm, Jo Rhett <[email protected]> wrote:
> >>> I've found some problems due to the extremely random ordering puppet 
> >>> does.  It is necessary for some of these items to all happen together, 
> >>> with no other random resources executed in between.
> >
> > On Dec 8, 2011, at 1:55 PM, jcbollinger wrote:
> >> That's rather unusual.  I'll discuss in a minute how you might address
> >> this requirement, but are you sure you really need to do so?  Would
> >> you care to satisfy my curiosity as to why?  Are you also going to
> >> have a problem if some other process (that is, not the Puppet agent)
> >> does any work between?
> >
> > I'm not worried about normal multitasking.  I'm just seeing problems where 
> > puppet does step 1 (which causes a small but acceptable outage with a 
> > service) then steps aside and does dozens of other operations from other 
> > modules, like package security checks, log handling, etc.  Then it comes 
> > back to finish the changes to the service.  What should have been a minute 
> > outage (5-10 seconds when they occur in order) to happen with 12-15 minutes 
> > in between.
> 
> So, I want to be clear up front: this is the absolute opposite of a
> promise.  I want to understand what people expect here, and there is
> *nothing* resembling a hint that we are changing the model of Puppet.
> 
> So, Jo, if we wanted to solve this, would it work for you if we
> strongly prefer to process resources in the same class at the same
> time, rather than separating them over time?
> 
> Would you need that to work between multiple classes?  How would you
> like that to be specified, or just do it in the general case?
> 
> Would it work for you if we treated the relationship arrow as
> something that tried to bind as close as possible?
> 
> Is there a situation where that wouldn't work?

Lots of debian packages restart services as the debs are upgraded. That might 
de-atomic any process.
 
> Other folks, what do you think, in your environments?

I appreciate the semi-random ordering, because that shows up manifest mistakes. 
I also want to know more specifics about what prompted the request.

This conversation sounds like the request for "atomicbefore" and 
"atomicrequires", or at least an "atomicdefine". Any problems would be the 
user's responsibility to sort out, much like what happens when we point a 
dependency forward across run stages.

(It's obviously not a bug that we can't do that, and adding a bad 
require/before combo to something crossing the atomic boundary would sensibly 
also cause problems. Like "Cannot require into an atomicdefine" and "Cannot 
happen between atomically defined resources".)
 
> Daniel
> -- 
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ♲ Made with 100 percent post-consumer electrons
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to