Fixes #36104 - Distinguish host events

[ofedoren]

Testable with foreman_webhooks. Adds new events to better distinguish between host events, whether it was triggered by user or via some automation.

@adamruzicka, what do you think? This is the simplest solution I could find and it seems to solve the issue...

[theforeman-bot]

Issues: #36104

[ofedoren]

Added a second commit, which removes new host_*[_automatically|_manually] events. Host created/destroyed can be left as general events, since they are pretty rare in comparison to host updated event we want to resolve problems with (due to often auto updates via e.g. reports). This commit ensures host_updated event is only triggered on actual user input against the host object. Auto updates (such as reports or changes through console) won't or shouldn't trigger this event. This comes from offline discussion with @ares, but any other input is surely welcome.

[adamruzicka]

I like this, it is nice and clean and seems to work well. However, shouldn't there be an event that would fire once uploaded facts get processed?

[ofedoren]

@adamruzicka, that event can cause spammed host_updated events. If we drop the second commit then it will fire host_updated_automatically event, which nobody used before, so it's pretty safe. But in the same time, host_updated will be still general, so users would need to manually re-subscribe webhooks to a different event.

I agree that with the last change here, users can no longer receive events if a host was updated by facts upload, but at the same time, if there will be a request, we could add either a custom facts_upload event, or host_updated_facts or even again host_updated_automatically.

Other than that, I'd personally prefer the initial fix (without second commit), but I can be missing something, so I'd like to see what direction here we would all like to take, @adamruzicka, @ares.

[adamruzicka]

we could add either a custom facts_upload event, or host_updated_facts

I had something like that in my mind. Spamming events is definitely wrong, but not firing anything when facts get uploaded doesn't feel right either

[ofedoren]

@adamruzicka, I've added host_facts_updated event, but I guess it will work only on Host::Managed.

It seems we'd need to check how webhooks work for unmanaged and discovered hosts (are there any other?).

[adamruzicka]

Works well, one inline comment

[ofedoren]

Thanks, @adamruzicka, updated. AFAIK it could throw NoMethodError, but apart from that I'm not sure it can raise something else, but just to be sure there is a catch for any exception.

[adamruzicka]

Looks good to me, let's get this in

[adamruzicka]

Katello failures seem unrelated

[ofedoren]

Yeap: Katello/katello#10701

[test katello]

[adamruzicka]

Could you please squash the commits before we merge?

[ofedoren]

Sure, done.

[adamruzicka]

Test failures are unrelated and are being resolved in another PR. Let's get this in

[adamruzicka]

Thank you @ofedoren !