Lucy - Can you take a first pass at this and see if we need someone from the container team review?

Beni is this similar to (or even a duplicate of) bug 1489616?

If the problem is only CONTAINER_* events:
Working as Designed, but confusing, probably worth implementing.
CONTAINER_* are collected as EmsEvents, but there is no Automate definitions
triggering policy MiqEvent.

https://github.com/ManageIQ/manageiq-content/tree/master/content/automate/ManageIQ/System/Event/EmsEvent/Kubernetes.class/

- CONTAINER_* do event_action_refresh
- POD_* do event_action_refresh & event_action_policy
- REPLICATOR_* do event_action_refresh & event_action_policy
- NODE_* do event_action_refresh & event_action_policy

I believe these 4 are everything we collect.
https://github.com/ManageIQ/manageiq-providers-kubernetes/blob/master/app/models/manageiq/providers/kubernetes/container_manager/event_catcher_mixin.rb
(on kubernetes/openshift side these are just Pod, Replicator, Node, our event catchers translates Pod events that identify a specific container into CONTAINER_* instead of POD_* EmsEvent.)

Federico, when I implemented container policies, you said to support just Pods, Nodes, Replicators.  Were container events deliberately excluded?
Or now that I think of it, did I misundertood you and you meant all openshift Pod events, which on our side should include both Pod and Container policies?

(In reply to Beni Paskin-Cherniavsky from comment #4)
> Federico, when I implemented container policies, you said to support just
> Pods, Nodes, Replicators.  Were container events deliberately excluded?
> Or now that I think of it, did I misundertood you and you meant all
> openshift Pod events, which on our side should include both Pod and
> Container policies?

Argh, yes, in terms of writing policies we want to support Pods, Nodes and Replicators but it doesn't mean they're 1:1 with events that are raised.

How long would it take to make the CONTAINER event trigger the Pods Policies?

Trigger Pod policies — nice!  I expect it to be very easy.
Create the automate yamls, and possibly tweak function finding event target.
Only laborous part will be checking it actually works for each possible event.

(If OTOH you wanted to support Container policies, that would add UI work)

There is a mild but sticky benefit to doing the extra work to add Container Policies rather than tying these events to Pod Policies:
If condition target is a specific container, you to ask question about that specific container (eg. this container restart count > 5 AND this container hourly max memory > 1GB).
If target is pod, you can only ask about the pod, and some things about ALL its containers.
I don't know if that has any actual use case.

The catch:
if we now decide this benefit is negligible and tie this to Pod Policies, and later discover a stronger use case and need to switch to Container Policies, it will be nearly **impossible to migrate** existing Pod Policies.
(there is very little ability to introspect MiqExpression, only to evaluate it.  transforming expressions to be around a different subject would be a research project...)

So, what should it be?

(In reply to Beni Paskin-Cherniavsky from comment #9)
> if we now decide this benefit is negligible and tie this to Pod Policies,
> and later discover a stronger use case and need to switch to Container
> Policies, it will be nearly **impossible to migrate** existing Pod Policies.

Can't you route the same event to two objects?

E.g. today we implement the Pod support (routing the event to the Pod), users will start writing their Pod-based policies. Tomorrow we'll route the event to Containers as well and we'll enable more granular policies to be written without invalidating the old ones (the Pod-based ones).

(In reply to Federico Simoncelli from comment #10)

> Can't you route the same event to two objects?

For infra you can create a policy for a VM and attach the policy to the Host, Cluster or Provider of the VM. To have something similar, I think this requires us to go with attaching events to containers since we need to create the policy for them.

After discussion with Federico,
My conclusion is to go currently only with POD policy (for container events),
ManageIQ currently can not facilitate container level operations or policies (even no UI for it).
If such a need will come up in the future it will be discussed (along with possible racy situation where an event is routed to both policies)

Upstream PRs:
https://github.com/ManageIQ/manageiq/pull/16583
https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/181
https://github.com/ManageIQ/manageiq-content/pull/225

Note: theres an IMPORTANT limitation here

These events will trigger policies ONLY IF their target(pod in this scenario)  is in the DB. events like "pod container created" will not be picked up and will still generate an "Unable to find target" error message. 
this is because in most cases the pod will not be in the DB before the container created event is received.

(In reply to Ari Zellner from comment #15)
> Note: theres an IMPORTANT limitation here
> 
> These events will trigger policies ONLY IF their target(pod in this
> scenario)  is in the DB. events like "pod container created" will not be
> picked up and will still generate an "Unable to find target" error message. 
> this is because in most cases the pod will not be in the DB before the
> container created event is received.

BZ for this problem is https://bugzilla.redhat.com/show_bug.cgi?id=1367114