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). 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. 3. This shouldn't be mandatory - it should be an optional extra rather than the default to have queuing enabled. 4. What happens with the queue daemon breaks in the process? 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... :) Cheers James Turnbull -- Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/)
signature.asc
Description: OpenPGP digital signature
