Target minions with a list file?

[Raj Wurttemberg]

Hi All,

I'm relatively new to Salt...  Is it possible to have Salt run against a list file of minions?  Say for example I had a text/list file like this:

server01

server02

server02

I know I can use grains for targeting minions but sometimes the attribute isn't there or I only need to run Salt against a small subset of minions (i.e. not all Red Hat or not all web servers).

Thanks!

/Raj

[Loren Gordon]

I think the closest would be to use a nodegroup, which you can define in the master config file.

https://docs.saltstack.com/en/latest/topics/targeting/nodegroups.html#node-groups

Another option would be to read a list of minion IDs from the file and join them with commas.

https://docs.saltstack.com/en/latest/topics/targeting/globbing.html#lists

Something like: `salt "$(cat file | tr '\n' ',')" cmd.run echo hello`

-Loren

[Jeremy McMillan]

Can you tell us more about what you're trying to accomplish so we can each give you our favorite, and discuss how to evaluate the options so that we can provide Google with our collective wisdom for future use?

[Johann Kappacher]

Hello

a list of hostnames (a file with just that) is "the most natural way" to feed a wider range of hosts that cannot be specified with regex/grains etc.

distributed/parallel remote shell tools work this way.
I am wondering why this kind of target listing has not been implemented.

Of course, workarounds exist ...

[Jeremy McMillan]

That's not a specific example.

[Johann Kappacher]

Okay, to be specific ....

we will schedule a patch run this weekend, not all of them, considering 900 linux instances and 300 aix, 200 solaris.

just patching the obvious three ... openssh/openssl/java (and perhaps a ntp or bind hot fix?)

no, there is no regex or grains or a compound match that serves our needs!

defining a nodegroup of hundreds of targeted minions? nodegroups are static master config!

I just want a simple list of hostnames, one per line, as an input (file or stdin) to salt instead of a comma-separated list ("-L").

And NO, i don't want a bash workaround!

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/HnKZKaYgnjA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Loren Gordon]

Whether it is "the most natural way" is a matter of opinion. I checked GitHub issues and couldn't find anyone else asking for something quite like this. So it seems to me the current targeting options are working fine for existing users. I would recommend submitting a new issue on GitHub requesting this feature.

Anyway, since what you want isn't possible currently, let's keep the discussion here productive on how to get as close to what you want to do as we can. Perhaps an approach closer than using nodegroups would be to use pillar matching with -I, https://docs.saltstack.com/en/latest/ref/cli/salt.html#target-selection

You could set it up like this:

/srv/pillar/top.sls

base:

  '*':

    - roles

/srv/pillar/roles.sls

role:

  db:

    - minion1

    - minion2

  web:

    - minion3

    - minion4

And call it like this to target all your instances assigned the 'db' role:

salt-call -I 'role:db' test.ping

It's obviously not quite a simple list of hostnames in a file like you are asking for, but it doesn't require modifying the master config file or using bash as a workaround.

-Loren

To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Loren Gordon]

Oops, I'm too used to using salt in masterless mode. The command would be:

salt -I 'role:db' test.ping

-Loren

[Dimitri Maziuk]

On 11/14/2016 01:38 PM, Johann Kappacher wrote:
> Okay, to be specific ....
>
> we will schedule a patch run this weekend, not all of them, considering 900
> linux instances and 300 aix, 200 solaris.
> just patching the obvious three ... openssh/openssl/java (and perhaps a ntp
> or bind hot fix?)
>
> no, there is no regex or grains or a compound match that serves our needs!
> defining a nodegroup of hundreds of targeted minions? nodegroups are static
> master config!
>
> I just want a simple list of hostnames, one per line, as an input (file or
> stdin) to salt instead of a comma-separated list ("-L").
> And NO, i don't want a bash workaround!

While I agree that feeding it a list of hostnames is a very common and
familiar usage pattern, it seems to me that what you really want is a
grain that says "I need patches x, y, z".

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

[Jeremy McMillan]

I want world peace. To get it I might have to roll up my sleeves and do some work.

The beautiful thing about a bash-y solution is that it makes an awesome use case which doesn't require a lot of discussion to understand the functional requirements.

$ LIMIT=2

$ cat minions | xargs -I TEH_MINIONS -L $LIMIT echo salt --async --list '"TEH_MINIONS"' state.apply patchy.patch

salt --async --list "inky blinky" state.apply patchy.patch

salt --async --list "stinky clyde" state.apply patchy.patch

Once we have something people can try out, maybe we can go over to GitHub and create a ticket for the enhancement.

Then maybe someone (you?) will fork the code and make things happen.

To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Roman Šramatý]

I am looking for the same. Currently using favourite for loop:

for i in $(cat /tmp/minions_list.lst); do salt $i test.ping; done

[Mrten]

On 05-03-2018 11:00:01, Roman Šramatý wrote:
> I am looking for the same. Currently using favourite for loop:
>
> for i in $(cat /tmp/minions_list.lst); do salt $i test.ping; done

put them in the master config as nodegroups and use -N

that's not really answering the question but there's no reason why you can't
config salt master via salt, so these nodegroups can be read from a file
automatically as well.

M.

[Jeremy McMillan]

Whenever people ask me "but how do I target an arbitrary list of minions" I always hear "but how do I make toast using a microwave" because the person asking assumes out of habit that a microwave, or an arbitrary list of minions, is the way to get the job done. It can be done, but why not try something more natural?

"A foolish consistency.." (Ralph Waldo Emerson quote referenced in PEP08 "import this")

What Dimitri said:

what you really want is a grain that says "I need patches x, y, z"

But also consider applying a state. What if you could ask the minions and they could tell you whether they need the patches (or whatever else)?

How do you come up with your list? Instead of thinking "Which servers do I want to patch now" you should be thinking "What criteria do I need to decide which servers to patch in each batch?" Then give the criteria to the minions in the form of a state.sls with requisites, or even a judicious use of jinja or python logic to enable them to make their own simple decisions.

Criteria, like environment or server roles which seldom change, especially things that need to be investigated on the minions, are good candidates for grains. Criteria which are often changed may be good candidates for pillars. Things which are ephemeral or just change a lot are good candidates for execution module functions.

Grains and pillars can be used for targeting state runs. Everything else can be decided in highstate runtime.

If I were you, I'd write and run a state that sets a boolean in a minion data structure to determine which servers are in scope for the patch run.

https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.data.html#module-salt.modules.data

You are really intending to sample your entire infrastructure, and apply the patches to that sample. You haven't shared any sampling criteria, so we can't help you figure out the best way to do that.

Then I'd write a state which applies all the patches, conditionally, using a requisite only_if which evaluates the scope flag using the execution module data.get call in a module.run call.

[Dmitri Maziuk]

On 2018-03-08 22:28, Jeremy McMillan wrote:
> Whenever people ask me "but how do I target an arbitrary list of
> minions" I always hear "but how do I make toast using a microwave"

I personally think too much declarative kool-aid may result in hearing
loss. A list of targets is a natural usage pattern and should be
naturally supported; having to put a new script into _grains, that will
publish another flag, that can be used for target selection, is
bordering on the dictionary definition of back-asswards. It is how you
can do it with salt. I would not go so far as to call it a rational way
of doing it.

Dima

[Matthew Phillips]

Roman,

I don't believe the functionality natively exists (though it would be useful and probably not too difficult to add). However, instead of a for loop you can generate a string using list targeting to get salt localclient to handle iteration. Something like salt -C 'L@server1, server2,...' foo.bar.  

Cheers

Matt

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/8d56f002-e87f-4fda-9083-c2a3280ad53c%40googlegroups.com.

[Johann Kappacher]

Sorry,

I have requested this simple enhancement in a further mail thread, but some folks think this is not a "must have".

No comments.

A simple workaround:

cat minions.list | xargs | xargs -I{} salt -L "{}" test.ping

I have used this syntax to check and update settings for about 170 SAP servers in one shot.

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/HnKZKaYgnjA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CAFWy7Aa4c89YRR4Q7Ox3o35vk%3DCZingyqOwutha4f8acRU-0ow%40mail.gmail.com.