----- Original Message ----- > > On Wednesday, 12 October 2011 at 13:44, Stu Teasdale wrote: > > > > On Tue, Oct 11, 2011 at 02:13:36AM -0700, Lucian Holland wrote: > > I've been pondering something not dissimiliar to this recently, a > sort of "config introspection", for some of our live services (e.g. load > balancers). My initial thoughts were geared around collected > resources, but I'm not sure the model works well for them. We already use > puppet > manifests to provide control info to mcollective, so feeding > mcollective discovery back into puppet might be an interesting way to do some > of > this information gathering. The scope of what we're thinking about is > a fair bit smaller than the sort of holistic, whole system stuff Lucian > is talking about though. > > > (Hi Stuart!) Isn't this essentially what > http://www.devco.net/archives/2010/09/18/puppet_search_engine_with_mcollective.php > is doing using mcollective registration? Although it's very cool I > wonder about having another fact store at another level of > indirection from the original information (machine properties -> > puppet -> yaml -> mcollective -> mongodb) - it feels a bit like a > cache hierarchy without enough in the way of proper cache > management. But I suppose that's a soluble problem with a bit of > work.
the registration based search only goes a small part of the way, its not nearly far enough. It's interesting and solves a subset of problems and a quick win but its far from complete. If you need application level awareness where applications are spread over a group of machines and dynamically managed through elastic auto scalers you need a lot more than just that. Luke has done some prototypes around moving to a application view rather than a node view [1][2], not sure what conclusions can be made from the existance of these repos though. You really do need to also include things like resource states (puppet resources) service states (monitoring) and weather information (latency between points) to make the kinds of decisions cloud managing needs.[3] Much of this is solvable by plugging in observers, reading states from monitoring etc and exposing it through some querying interface. But it's pretty complex especially as there's so few standards in this space. You may have all the data but no tools that can query it and understand the results. You may have tools but you need a solid expressive way for automated systems to reason out what is the best next step etc. I think we're some way off from seeing a real generic answer to this problem - but its totally possible to build your own now, the information is there and tools like mcollective allows you to keep that up to date and relevant. [1] https://github.com/lak/Puppet-Platform-Manager [2] https://github.com/lak/puppet-environment-manager [3] http://www.devco.net/archives/2011/05/04/monitor_framework_minimal_configuration.php -- 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.
