how to catch the fired events on minions

[Peng Yao]

when use "salt '*' event.fire"  or "salt-call event.fire" to fire the event on minion's local bus, how to catch the fired events on minions ? not on master

[Colton Myers]

Yep, it's actually very similar to how you might listen on the master.  Use the eventlisten test script as a guide:  https://github.com/saltstack/salt/blob/develop/tests/eventlisten.py

Note that on a minion, you have to pass in `--node=minion` to that script.

--

Colton Myers

On Mon, Nov 25, 2013 at 10:13 PM, Peng Yao <xuanw...@gmail.com> wrote:

when use "salt '*' event.fire"  or "salt-call event.fire" to fire the event on minion's local bus, how to catch the fired events on minions ? not on master

--
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+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Peng Yao]

I have to pass in `-n minion` to that script on a minion, but get nothing when I fired events using "salt-call event.fire" and "salt-call event.fire_master" on the minion.

My Salt Vesion: 0.17.1

[Colton Myers]

Looks like something is, in fact, broken here.  I can't get the eventlisten script to receive the events either (it seems to be binding to the wrong ipc socket).  Looking into it now.

--

Colton Myers

[Colton Myers]

Alright, I figured it out.

First, it turns out you need to pass in the minion ID to the script:

python eventlisten.py -n minion my_minion_id

However, even with this change there was still a bug.  (Apparently no one has been using this script to listen on the minion event bus -- it seems to have been broken for about 6 months)  The fix is here:  https://github.com/saltstack/salt/pull/8857

If you make that change in your eventlisten.py (or pull the latest `develop` branch) it should start working.

Hope that helps!

--

Colton Myers

[Peng Yao]

It works! Thanks

[dopp...@gmail.com]

Am I correct to assume that the only way to catch events on a minion is through writing a python service? Can it not be done in a state so as to chain events between Master and Minion with states?

Cheers,
Daniel

[Stephen Spencer]

Daniel,

Events can be caught in the master by way of a reactor.

-S

For more options, visit https://groups.google.com/d/optout.

[Daniel K]

Thank you Stephen, although I am trying to chain events between the master to the minion.

My minion has a state that fires an event to the master. I have a Reactor on my master that triggers a Runner that executes some commands on the master. When these commands have finished, I would like the master to fire an event back at the minion to tell it that the state was completed successfully (or with error) depending on the result of the commands that were executed on the master.

To do this I was looking for some state method that allows the state to simply wait for the event from the master until it completes.

I realize that this is going out of scope for this thread and if it is preferred, I can create a new more detailed thread.

Cheers,

Daniel

--
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/H5fRkJbcMIg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Stephen Spencer]

Ah! Interesting. There is a section of the docs that I perused the other day regarding firing events from a minion ( http://bit.ly/XUaOT2)

The example given uses salt-call. So that leaves us with only an execution module to work with.

I've been kinda hyper-focused on writing support modules for ovirt over the last several weeks,l rather than state formula construction, but I'm pretty sure that you can call an execution module as a depends-on target for a state definition. The catch is that the state would actually have to fire first, so depending on the use-case that could be adequate for your purpose. Perhaps a state that is hooked into the scheduler?

Some might consider a cron job for a salt-call, but I'm more partial towards keeping it salty.

-S

[Stephen Spencer]

Aaand re-reading your response..

I think you might be able to deal with this by having your reactor fire off a state definition targeting the responding minion. The minion wouldn't exactly be waiting, but if you have a state (not hooked into its high-state pattern) that is only triggered by a particular message from the master, that might get you where you want to go. In a way, you could consider this a way to short-circuit the normal high-state run--having a portion of the minion's state-run depending on information returned from the master.

-S

On Sep 23, 2014 2:25 AM, "Daniel K" <dopp...@gmail.com> wrote: