Event rules actions

[nyevess]

Hello Community!
I am trying to create an automation through "Event Rules", I would like that when a device with a certain tag is created a "custom script" is executed that makes modifications in the created device, but I am not sure how to pass the value of the device name that has been created to my script to perform the action. I think I should add something to the "Action data" field but I don't know how to do it. Could you help me?

[candlerb]

You can test it with a simple script like this:

from extras.scripts import Script

class ShowData(Script):
    def run(self, data, commit):
        self.log_success(f"data items: { {k: type(data[k]).__name__ for k in data.keys()} }")

You'll find that the data passed to the script is in fact a representation of the object that triggered the event. In this case, it's a Device:

data items: {'id': 'int', 'url': 'Hyperlink', 'display': 'str', 'name': 'str', 'device_type': 'OrderedDict', 'role': 'OrderedDict', 'device_role': 'OrderedDict', 'tenant': 'NoneType', 'platform': 'NoneType', 'serial': 'str', 'asset_tag': 'NoneType', 'site': 'OrderedDict', 'location': 'NoneType', 'rack': 'NoneType', 'position': 'NoneType', 'face': 'NoneType', 'latitude': 'NoneType', 'longitude': 'NoneType', 'parent_device': 'NoneType', 'status': 'dict', 'airflow': 'NoneType', 'primary_ip': 'NoneType', 'primary_ip4': 'NoneType', 'primary_ip6': 'NoneType', 'oob_ip': 'NoneType', 'cluster': 'NoneType', 'virtual_chassis': 'NoneType', 'vc_position': 'NoneType', 'vc_priority': 'NoneType', 'description': 'str', 'comments': 'str', 'config_template': 'NoneType', 'local_context_data': 'NoneType', 'tags': 'list', 'custom_fields': 'dict', 'created': 'str', 'last_updated': 'str', 'console_port_count': 'int', 'console_server_port_count': 'int', 'power_port_count': 'int', 'power_outlet_count': 'int', 'interface_count': 'int', 'front_port_count': 'int', 'rear_port_count': 'int', 'device_bay_count': 'int', 'module_bay_count': 'int', 'inventory_item_count': 'int'}

As far as I can tell, setting Action Data makes no difference.

Note that this isn't in the same format as data supplied by manually invoking a script from the web UI (with form parameters), so a script designed to be run like that can't be run as an event triggered script, and vice versa.

[candlerb]

AFAICS the behavior is not documented. Also, I don't see any way to distinguish between create, update and delete events (other than having different scripts for these events, linked to separate event rules), nor between different models (ditto).

Maybe it would have been better if the data passed to the script were structured the same way as a webhook. You could raise that as a feature request. Although it would be backwards-incompatible, Netbox in general doesn't provide any backwards-compatibility guarantees so it would just have to be called out in the release notes.

[llamafilm]

If the event rule is triggered by a Data Source sync, the data object is None. Even if I add something like {"triggered_by": "Event Rule 1"} in the action data field, that makes no difference. This seems like a bug but I'm not sure how it's meant to be used. The documentation on event rules is pretty light.

[kkthxbye-code]

@bitcollector1 - You sure you are not just modifying the same object that triggered the event rule, thus triggering it again? They implemented no safeguards against this as far as I can tell, so you would have to account for it in your script.

[bitcollector1]

Thank you so much for this clue....AND for all the other nuggets I've gleaned from you over the years :)

At least now I have a plan of action to fixing this issue! I can't tell you how many hours of sleep I have sacrificed already! Feeling a little crispy right now and happy it's Friday :)

[bitcollector1]

This is EXACTLY what my problem is! It appears anytime that one of my functions does a device.update that it triggers the script to run again!

THANK YOU SO MUCH @kkthxbye-code

[bitcollector1]

hours and hours of my life wasted on this circular logic, I really hope someone else finds this thread and it helps them to avoid this issue! Talk about a face palm! TGIF!

[AADIP]

hours and hours of my life wasted on this circular logic, I really hope someone else finds this thread and it helps them to avoid this issue! Talk about a face palm! TGIF!

If you dont mind me asking, how did you handle this? I would like to avoid triggering this event rule when I run my custom scripts.

[bitcollector1]

so I am still a little confused. It seems than ANY change to a device results in my script getting triggered, but I thought it was only supposed to trigger if Primary IP was changed. I'm guessing this is why I was so confused to begin with since I thought the scope was limited to just the primary IP itself being updated.

I must be missing something very obvious :(

Time for a break!

[candlerb]

I thought it was only supposed to trigger if Primary IP was changed

No: according to this post you set it to trigger if the primary IP address is not null. Whether the IP address has changed or not is irrelevant; if the device is saved, and the IP address is not null, then it triggers. The hook cannot compare the old and new values of an individual field, because it's only given the new value.

Conversely, if you directly edit the IP address object itself, e.g. changing it from 1.2.3.4/24 to 1.2.3.5/24, then I don't think this will trigger a change event on the device. The device itself hasn't changed or been saved; primary_ip4 is still pointing to the same IP address object. The IP address object itself has mutated.

[bitcollector1]

Thank you very much for clarifying this for me. I've been trying to figure this out for awhile now, so this is very much appreciated!

[matt-edu]

I thought it was only supposed to trigger if Primary IP was changed

No: according to this post you set it to trigger if the primary IP address is not null. Whether the IP address has changed or not is irrelevant; if the device is saved, and the IP address is not null, then it triggers. The hook cannot compare the old and new values of an individual field, because it's only given the new value.

Conversely, if you directly edit the IP address object itself, e.g. changing it from 1.2.3.4/24 to 1.2.3.5/24, then I don't think this will trigger a change event on the device. The device itself hasn't changed or been saved; primary_ip4 is still pointing to the same IP address object. The IP address object itself has mutated.

I just tested this scenario by editing the address object applied to a device as primary_ip. The event (device update) fired. v4.1.11