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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
