FAQ
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.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 18, '12 at 8:02p
activeApr 18, '12 at 8:02p
posts1
users1
websitepuppetlabs.com

1 user in discussion

Nigel Benns: 1 post

People

Translate

site design / logo © 2022 Grokbase