reclass and class node membership with salt

Mike Kelly mike at piratehaven.org
Wed May 14 03:34:09 CEST 2014


I hacked this together today.  I just added these lines to
reclass/storage/__init__.py:
    def nodeinfo(self, nodename):
+        entities = self._list_inventory()
+        classes = {}
+        for f, nodeinfo in entities.iteritems():
+            d = self._nodeinfo_as_dict(f, nodeinfo)
+            for c in d['classes']:
+                if c in classes:
+                    classes[c].append(f)
+                else:
+                    classes[c] = [f]
+        ret = self._nodeinfo_as_dict(nodename, self._nodeinfo(nodename))
+        if 'classes' in ret:
+          my_classes = {}
+          for klass in ret['classes']:
+            my_classes[klass] = classes[klass]
+          ret['classes'] = my_classes
+        return ret
-        return self._nodeinfo_as_dict(nodename, self._nodeinfo(nodename))

It might not be the prettiest thing in the world, but it works.

A better solution would be to add node awareness to the Classes (ahem)
class.  That would avoid the crawling of the data structure every time.
However, doing that looks like an exercise for someone more familiar with
the code base.

To answer your question of how I want to use this data, a simple example
might be nagios, or splunk, or hudson, or backups, or any of a number of
client/server systems where I need to configure the server to beware of
the client, and then configure the client to be aware of the server.

I'm new to salt, so my simple approach is to classify data into two
types: data, and metadata.  Pillars store all the data, and the top.sls
files store all the metadata.

The problems with top.sls are many, the metadata is not available to
the minions when they run, and there's no good grouping system just to
name two of the most annoying points.

The problem with pillars is that they create two places to edit every
time I add or remove a node, and I'll end up with tons of membership
lists sprinkled in pillars all over the place.  Listing all the pillar
groups a node is a member of would be a fun jinja code block to cut
and paste all over my stacks as well.

My plan for this hack within reclass is simply to assign all clients to
a client class.  This class will trigger the correct salt stack to run,
and will allow the minion to know who its master is from either a
reclass parameter, another master class, or via some other method
involving pillars and stack logic.  Meanwhile, the master can know who
all the clients are merely by being a member of the same class and then
doing something unclient like when it discovers that its name is the
same as the master server.

Like I said, I'm new to salt, so if you know of a better way to do this,
I'd love to hear it.

Thanks,

Mike

-- 
--------Mike at PirateHaven.org-----------------------The_glass_is_too_big--------


More information about the reclass mailing list