On Thu, Feb 4, 2010 at 9:58 AM, jcbollinger <john.bollin...@stjude.org> wrote: > > > On Feb 3, 3:08 pm, Michael DeHaan <mich...@reductivelabs.com> wrote: >> Actually I think it can be done by leveraging an improved storeconfigs and >> the existing language. > > I was wondering whether storeconfigs would come up. The problem I see > with that is storeconfigs, as I understand them, record the managed > resource states each host *should* have, not necessarily those each > one *does* have. What happens to my multinode deployment if at some > point in the middle, Puppet fails to apply a necessary resource state?
If Puppet fails applying a state, it should record the current state, not the once and future state. I'll dig into the schema of what it does now, but don't limit your thinking based on what storeconfigs currently does or is, think about what it can be. > Absolutely so, and that connects back to your earlier comments about > message buses. Messaging is the lifeblood of any kind of > orchestration technology, but there are a variety of message exchange > patterns, message implementations, and messaging options, many > combinations of which are viable. Some could reasonably be > characterized as "push", but many others couldn't. This is an software architecture statement, and architecture is independent of execution and concepts. Long term, I expect to see messaging will happen and can then play a much wider role mainly for offline delivery implications and routing. Though much can be hinged on present workings, whether RESTful or RPCy (which, aren't all that different regardless). However, first, small steps. > > Any way around, there is a class of messages needed for this that > Puppet does not currently have: messages from clients advertising the > individual or collective state of their managed resources. The > absolute simplest form would be a reply to the Puppetmaster indicating > whether a catalog was successfully applied, but finer-grained state > messages would be much more flexible. These would address the problem > of discrepancy between supposed and actual state. Eventing and reporting, and an evolved storeconfigs concept are something we're looking at, for sure. Stay tuned, and of course, if you have time, patches are very much welcome. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
