Inter-applet dependancy using "action policy"

[pgasparovic]

Hi there,
I need an urgent help. After intensive study of EEM for 1,5d before and experimenting today, I can't get why the EEM applets does not work the way they reasonably should. I want to grasp the dependancies, etc.

Why for these 2 scripts :

event manager applet first
 event none
 action 1   set a1 "xxxxx"
 action 1.1 puts "1. $a1"
 action 2   wait 3
 action 3   policy second
 action 4   puts "2. $a1"
event manager applet second
 event none sync no
 action 1 puts "sub - $a1"

I get this result :

host#even manager run first
1. xxxxx
2. xxxxx

*May 12 12:01:21.183: %HA_EM-6-LOG: second: sub - 0

where:
1) the  second applet is not called from first while it's running (I know about maxrun that could set an assured timerange). A detailed log shows :

host#debug event manager server scheduling
host#event mana run first
1. xxxxx

*May 12 12:03:52.976: EEM server schedules one event: policy_type=applet epc=0x25B42A3C.
*May 12 12:03:52.976: fh_set_epc_pid: EEM callback policy first has been scheduled to run. fdid: 16 sn: 140 jobid: 3522. xxxxx

*May 12 12:03:55.980: EEM server schedules one event: policy_type=applet epc=0x25D7BBB8.
*May 12 12:03:55.980: fh_io_ipc_msg: EEM callback policy first has ended with normal exit status of 0x0
*May 12 12:03:55.980: EEM: server decrements in use thread: jobid=352 rule id=2 in use thread=1.
*May 12 12:03:55.980: EEM server schedules scripts
*May 12 12:03:55.980: fh_set_epc_pid: EEM callback policy second has been scheduled to run. fdid: 16 sn: 141 jobid: 353
*May 12 12:03:55.984: %HA_EM-6-LOG: second: sub - 0
*May 12 12:03:55.984: fh_io_ipc_msg: EEM callback policy second has ended with normal exit status of 0x0
*May 12 12:03:55.984: EEM: server decrements in use thread: jobid=353 rule id=2 in use thread=0.
*May 12 12:03:55.984: EEM server schedules scripts
host#


2) if I don't set "sync no" in second, the first event takes 30s (besides that 3s wait), what relates to some "default" timer of event detector 30, even more than def. 20s for maxrun ?!? WTH?

3) I have read that variable changes among applets can be propagated only via config. change of them (or in TCL totally).. this was to test it, but I still hoped if step 1 was OK, it could work also.

So, who can explain steps 1 and 2 to me, I'm yet amazed that there are almost none topics on "action policy" issue (to me). Thank you very much may some reactions come.

BR
Peter

[Joe Clarke]

1. Yes it is.  But in the case of the second applet, it doesn't have a controlling terminal, so the "puts" gets turned into a syslog automatically.  Note: Simply setting $a1 in your first applet has no effect on the second applet.  If a1 is not defined as an EEM environment variable (or explicitly defined in the second applet) you will get an error as the variable doesn't exist.

2. There is another timer, the default timer, that controls how long the applet will wait before returning the prompt.  This is 30 seconds by default and also configurable just like maxrun.

3. This is correct.  You can also use EEM contexts to share data between policies.

In general, I don't recommend "action policy".  I prefer publish-event to chain together policies as it's asynchronous.

[pgasparovic]

thanks for quicky reply, but still don't get it :

1) "Yes, it is".. you insist on that second is called from first? Actually, I had "a1" as EEM variable in config, just was not here.. if that was true, I would not be reporting.

2) you did not explain why I can't get sequence :

1. xxxxx

sub - 0

2. xxxxx

... or whether manipulating "sync" was a good step...

I also changed default timer on both to 1s.. no success... simply I miss a sense of "default" a lot.

Thanks for answer yet.

Peter

[Joe Clarke]

1. You said, "the second applet is not called from the first."  It is.  It's just that the puts statement will not print to the current terminal.  It will print via syslog instead since the second policy is asynchronous.

2. Because the second applet is executed asynchronously.  You will not be guaranteed when the message gets printed, and it will only display in syslog.

Make the policies synchronous and lower the default timer.

[pgasparovic]

This is futile .. I tried to avoid puts behaviour, changed/added for "a1" variable change test and still no success.

So, r u willing to fix this "easy" setup rightaway, or I do need it open a TAC case on this?

[Joe Clarke]

What are you actually trying to do?  Understanding the real use case may provide a better solution.

[pgasparovic]

Actually it's more complex and imagined quite fine, but still in attempt to avoid TCL code instead of applet.

So this is a concept test, understanding interaction between applet, call it what you may like.. I simply was expecting the things to go straight - if there is enough threads for given applet type (def. 5 is), calling one from another should be of no issue and getting data (if puts is problematic, test it with variable change via config) in order I want. Can you do it, or not? I like to got your eye as you are guru in this topic, but if you can't be exact with direct CLI sample, fixing my config, then I need to turn to TAC for deeper explanation.

[pgasparovic]

Hi Joe,

I have this simple question yet, as I had to move from applet to TCL in my case, yet waiting for TAC to give me explanation on nested policy calls..

In TCL, with this simple script registered as user type :

::cisco::eem::event_register_none

namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

if {![info exists Cell_iface]} {
 error {Variable "Cell_iface" is not defined in configuration!}
}
puts $Cell_iface

the thing works fine when run as "event manager run ...".

But :

1) when using it with "tclsh" run, I get error that these commands ("event-register" I could accept, but "namespace" not, inc. order change) are failing by interpreter. I just don't undestand why it's so..the whole TCL environment in IOS as such for EEM and tclsh should be  common, no?

2) Why I can't use e.g. TCL "exec" command when no safe-scripting is in effect (per "sh run all " inc scripting", as documentation on this mode of operation may suggest. Just because it's "user" type only?

Thank you for your opinion and clarification, have a nice day.

Peter