Puppet users - Apr 2012 - Tighter Puppet Dashboard and MCollective integration

I was just thinking about the problem of host groups and such trying to set 
up our puppet infrastructure properly and came to the realization that 
using MCollective better in puppet dashboard would allow for more cloud 
like scaling of infrastructure services.

Here is the concept:

Right now in puppet dashboard groups can have nodes, facts (parameters) and 
Classes.

What I am suggesting would be the reverse of this -- dynamic groups.

Dynamic groups, instead of deciding what nodes get certain facts or 
classes, would contain an "MCollective Query" to decide what nodes are
applicable for this group.

It should also save the results of the last query.
If there is a difference between the last query and this query, then these 
nodes should be added to the group and then an audit entry should be saved 
to the database.

If an agent times out, then it should not be added or removed as it may 
just be too busy to respond.

Doing this will allow external applications to update facts assigned to a 
specific node and then have puppet dashboard automatically adjust its 
groups.
Obviously things to think about are, what groups does it query when a node 
gets added?
This would have to be groups dependent on the facts, classes or agents that 
get updated for that node.

The point of this is to create an event that could be fired and acted upon 
by a listening application to perform some action (how would have to be 
thought about).

One of my favorite examples being that it could get added to a 
load-balancer pool via this event.

In concept the dynamic group is just a representation of the pool within 
puppet-dashboard.
But the dynamic group can be the shared representation of this group, as it 
might be used by a load-balancer and an application deployment system which 
each have groups of some kind in created in their own program, which have 
the same nodes, preform the same role, but act on those nodes differently.

This would be an add event, there should also be a remove event etc...

Events might also be applicable for regular groups as well so that the 
communication goes both ways.

I believe this would extend the use case for puppet in many enterprises by 
giving them a central repository to group nodes in different ways once, and 
provide that information to downstream systems.

Thoughts?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/jUTnJeOvd_sJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.