On Dec 10, 12:20 am, 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 you are using one or more Execs in your command grouping? If you were relying on the Service resource alone then I don't see how the lengthy outage you describe would happen. > Now, I would prefer to use tags to do this, but because tags are inclusive > but not exclusive I can't prevent this change from being done during a normal > run. > > > Puppet's resource model assumes that each resource is atomic. If > > multiple resources really must all be applied one after another, with > > no others in between, then they oughtn't really to be modeled as > > separate resources. Rather, they are a single composite resource, and > > the right way to handle the situation is therefore to write a custom > > type (and provider) to handle the situation. > > That seems fairly extreme for a simple enough ordering issue. All we really > need here is the basic idea of a closure. I submit that you are looking at it from the wrong perspective and struggling to make Puppet work contrary to its designed mode of operation. It is a basic premise of Puppet's design that native resources are atomic as far as Puppet is concerned. It follows that the right way to compose an atomic resource is as a native type. That's not extreme, it's the Puppet way. Furthermore, if I have deduced correctly that your command group includes one or more Execs, then that is further confirmation that you are really looking for a native type. Most individual execs are stand- ins for for-purpose native resources anyway, but if indeed your group of resources includes Execs then that's a siren and flashing light telling you that you want a native type. Depending on the exact nature of your problem, however, it may be that you don't need to write a custom type. If you take a high-level view, then you can interpret the built-in Package resource type as representing a collection of files and scripts to be applied in a concerted manner. That seems at least close to what you are looking for, so perhaps you can approach your problem by building packages and having Puppet manage those. > > There is also a quick and dirty solution: use run stages. Assign all > > the resources that need to be applied consecutively to one run stage, > > and make sure no others are assigned to it. Or, if you cannot exclude > > all other resources (since run stages work at class granularity) then > > use explicit resource relationships to push other resources before or > > behind the group as needed. Be warned: doing this is likely to cause > > you continuing grief with dependency cycles, even with classes not > > Bingo. At this point almost every class has dependencies within every other > class which make it impossible. Mostly shared path names, but sometimes > services and config file references. If it is truly impossible to do the job with run stages then it is inconsistent with the context of your overall manifest set. You need to change it somehow, such as by altering which resources are involved or by eliminating some resource relationships. The bigger picture here is that such a high degree of resource interrelationship constitutes a modularity problem that will bite you again if not fixed. It may even be a direct contributor to your present problem, rather than merely a complication. You should work to minimize cross-class relationships, and especially cross-module relationships in your manifests. John -- 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.
