-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to define nodegroups through master_tops
system
#5787
Comments
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. |
Thanks for your time to reply, @thatch45! @UtahDave and I are just discussing this on IRC and we think that 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! |
If there were an inventory, then maybe minions that are not addressed by a published command could still respond with a |
I am liking where this is going, it will be useful on many levels! |
+1 on this feature |
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? |
+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. |
+1 |
2 similar comments
+1 |
+1 |
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. |
+1 |
3 similar comments
+1 |
+1 |
+1 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
We now do this with ext_pillar to import "group" pillar information based on a custom module that reads the data from a combination of external inventory systems. The addition of ext_pillar_first (available in stable after this bug was filed) means we can target using the "group" from ext_pillar in our pillar files. In short, for our use case we have a workaround through other developments in salt in the meantime. |
Thank you for updating this issue. It is no longer marked as stale. |
Unfortunately it doesn't help if there are only ext_pillar sources and one of them provides "groups" list and it's needed to use these groups to target pillars from other sources. |
@iavael Indeed, which is why I said "for our use case". It's very much a workaround, not a fix, as we've had to create a single ext_pillar that interfaces with the other ext_pillars (and some sources that we've not bothered to write a proper ext_pillar interface around, since we can't use it direct because of this) so we can cross-reference and cross-use them before using (some of) the information in them to target the pillar_root files. The functionality to do it properly in salt would be much better than mangling ext_pillar sources via our own hacky interface to get it to work. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
As a workaround we currently target pillars to nodegroups in the external system. Basically, our internal service that provides nodegroups for state targeting via pillars, also began to provide some actual pillar data that was stored in git. |
Thank you for updating this issue. It is no longer marked as stale. |
Any news on this issue? Is it normal that I'm not able to target minions using pillar ( |
@bbinet you can target jobs (via salt -I) and states (via top.sls) by pillar data (including ext_pillar). We successfully ise this in production for several years. You cannot target pillar via top.sls by pillar data. |
@iavael it does not work for me for all my minions (version 2019.2.0), but I've just come across issue #52234 and I think I should upgrade my minions to latest 2019.2.4 which should have the fix. |
@bbinet that's strange. We used such targeting since 2017.7. It could be available even earlier, but we didn't use saltstack then yet. |
Is this still an issue? from the last comments on the ticket it sounds like it has been fixed |
closeing this issue. if users are still having issues with this. please test in latest supported version to see if already addressed. |
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
andext_pillar
separately, do we want a third?), maybe themaster_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.The text was updated successfully, but these errors were encountered: