Ability to define nodegroups through `master_tops` system

[madduck]

Edit: master_tops is probably not the right place for this. I'll repurpose (and retitle) this issue as soon as the storm has left my brain (i.e. "brainstorming is done…").

---

At least with reclass, nodegroups are part of the inventory and thus could easily be made available to Salt, such that I could target commands or states at groups in my inventory.

Instead of defining a new interface (we already have master_tops and ext_pillar separately, do we want a third?), maybe the master_tops interface could be extended to allow the external source to return nodegroups?

I don't have a clear idea of how this would work yet, but if you give a general green light into this direction, I could start looking and evaluating various options. It is possible that the interface would have to be incompatibly changed, unfortunately, but I would document this appropriately and change the existing tops plugins.

[thatch45]

I think this is a good idea, I am not putting it on the top of my list, but please let me know if you can see a clean way to make this a possibility.
I think that adding it into master_tops makes a lot of sense, since the pillar data maps to a very different context, but ideas will need to be cultivated here to determine exactly how to approach this feature.

[madduck]

Thanks for your time to reply, @thatch45!

@UtahDave and I are just discussing this on IRC and we think that master_tops is not the right place for this, because it just returns the same data as top.sls, and as long as top.sls is not used for node group definitions, master_tops shouldn't be either.

Right now, we are brainstorming about a third external information source, maybe something like an "inventory". It would not only provide node group membership information, but also be able to give a list of all minions and allow the master to report if a minion didn't respond.

We'll keep you posted!

[madduck]

If there were an inventory, then maybe minions that are not addressed by a published command could still respond with a NOOP, or a "yeah, I heard you, but I am not addressed". This would close the loop and allow the master to stay on top of things.

[thatch45]

I am liking where this is going, it will be useful on many levels!

[arthurzenika]

+1 on this feature

[mgwilliams]

Inventory could be defined in yaml and/or by an ext_inventory module... I like this idea too. Could this somehow be combined with roster?

[baby-gnu]

+1

I can't imagine a configuration management without an inventory of “what I want” to compare to “what I have” and see the progress and configuration policy violations.

[bbinet]

+1

[nikicat]

+1

[jnials]

+1

[loz-hurst]

I hope that the node groups defined through this new "inventory" mechanism will be available in the pillar top.sls file too - so that those of us who solve the "what groups does this node belong to" issue with ext_pillar interfaces to other inventory systems can (finally!) match on these groups in pillar/top.sls.

[mumblez]

+1

[HontoNoRoger]

+1

[Galser]

+1