James Turnbull wrote: > Ethan Rowe wrote: >> * puppetqd runs as a separate process, and is listening to the relevant >> queue (though the degree to which it uses the indirection system >> natively for queue subscription needs to be worked out a bit more); as >> messages come in, it serializes them and stores them to the database, >> using a new database indirection in development for a different thread. > > I think this is filled with awesome (to steal a Shafer-ism). > > My only comments are mostly end-user operability ones - which I guess > people should realise now is my focus because I often write the doco :) > > 1. Configuration should all run out of puppet.conf - no new files for > this (I am assuming that was the intent).
Since the message service particulars will need to be shared by at least daemons (puppetmaster, puppetqd), it makes sense to place those particulars in a common location. Our intent is to make this as simple as reasonably possible. Though to be honest, our approach to the configuration arrangement is "get something working now, improve it when we have the new logic working." :) > 2. I like options - making a variety of clients available would be good > and making sure adding new clients is easy and well documented is > crucial to this I think - people's opinions on messenging and message > buses will vary greatly. The working design absolutely takes these considerations to heart. Yesterday I did some fledgling implementation for the abstract terminus, the client registry, etc., and I'm taking the trouble to document as I go. Whether my documentation is comprehensible is another matter, but the effort has been and will continue to be there. > 3. This shouldn't be mandatory - it should be an optional extra rather > than the default to have queuing enabled. Right. My understanding is that the default behavior should be for catalog storage to act as it acts right now: just do the storage to the database right from puppetmasterd. Use of the queue option is something to determine on a per-deployment basis. > 4. What happens with the queue daemon breaks in the process? To be sure I understand what you're asking, did you perhaps mean "when the queue daemon breaks" rather than "with"? > 5. It'd be good to see both architectures/workflows documented - I > think - other than talking to Luke - that's the first time I've seen the > new indirection workflow articulated in words on screen as it were. I > see a whole new world full of diagrams and workflows... :) A diagram would presumably help quite a lot. Words can express the design, but the abstractions are of the sort that will tend to lose a reader. Thanks. - Ethan -- Ethan Rowe End Point Corporation et...@endpoint.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
