On Nov 17, 10:57 am, Stephan <[email protected]> wrote: > Hi John, > > thanks for your reply, much appreciated. > > > I recommend that you check whether > > it is having the desired effect. > > Yeah, I actually double-checked before writing my post, and it did > work just fine ... but I agree with you that the term "realize" is > semantically questionable. What I actually need is a collection of > attributes across many modules to configure another module. That > doesn't go against puppet's declarative nature, since such a > collection would arrive at a certain set of attributes, no matter > where in the policy one starts to collect them. I'm actually not so > sure this "realize" I did for $tsm_backup doesn't go against the > declarative nature. If a realize is really supposed to act as you > describe and how I observe it in my tsm module, then we have something > like a race condition. Whichever spaceship is found first finalizes > the content of $tsm_backup. That's not very declarative. The more I > think about it, the more I think I should file a bug for it. What do > you reckon?
A race condition is a reasonable analogy. I would file the ticket, provided there isn't already one on this topic. At mininum, Puppet should issue a warning when it encounters potentially conflicting realizations of the same resource. Ideally, it would error, but only when there is a bona fide conflict. I suspect, however, that it is a lot easier to detect the possibility of a conflict (which is present whenever at least one of two or more realizations of the same resource employs an override) than it is to determine whether there is an conflict. > > I would assess a high risk of it breaking > > from one version of puppet to another. > > Good point. > > > As for how to achieve your goal, I'd recommend one of > > 1) target the original resource declaration, applying whatever logic > > or external data is needed to declare all the needed backup > > directories in the first place > > If I understand you correctly you suggest that the tsm module rolls > out a script which picks up all backup information from files rolled > out by the modules that need backups, rebuilds it into a usable conf > file for tsm and deals with making sure to restart the service and all > that. Probably possible, but kind of a nightmare to develop and > maintain. That's actually all stuff I expect a managing software to do > for me. Bit of a puppet-managed puppet replacement. But I agree it > might be possible, I'll think about it, thanks. I suppose what you describe is a possibility, but certainly not one I would pursue. I was intentionally vague on the precise mechanism for putting together the needed list of backup directories because I don't have an adequate view of the problem and context. Maybe there's no good solution available along this path. > > 2) rework your design so that each module can declare its own, > > independent Tsm::Config instead of relying on resource overrides. > > That could be built around a fragment-based approach to building the > > needed config file, or it could leverage the configuration language's > > mechanism for interpolating other files, if it has one. > > Unfortunately tsm doesn't offer something like a include of all files > in a .d directory (I guess that's what you mean with interpolating > other files). But what exactly do you mean with a fragment-based > approach to build the config file? Sounds like exactly what I want to > do, just don't know a way to realize it with puppet. Look up the Concat module. That seems to be the tool most often used for this sort of job, and several of the regulars around here can help you out with it. 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.
