Include annotations in events

[fpoirotte]

Feature request description

Hello,

I have some code that listens to podman events (using podman events --stream --output json --no-trunc) and reacts to certain events.
The code needs to behave differently based on annotations associated with the objects (pod in my case but the same could be true for containers).

Currently, annotations are not included in the events, meaning that a separate command must be used to retrieve them, which causes other issues (e.g. race conditions).

Suggest potential solution

Include annotations associated with an object in events generated for that object.

Have you considered any alternatives?

Alternative solution : retrieve the annotations separately using podman inspect <object>.

However, doing so runs into a race condition where the object may have already disappeared (e.g. when running a short-lived pod or container to do a task) and the annotations cannot be retrieved.

Additional context

Tested on podman version 4.9.4.

[Luap99]

Unfortunately with our event log design (file or journal) we must print all the container information on each event so we write a lot of duplicated information there which causes a lot of log churn. As such I rather not do that, we already have lots of complains about the log churn as we do include labels. If we include annotations as well we make this even worse

[fpoirotte]

Thank you for your reactivity.
Though logical, I had not come to the realization that podman events & the events_logger option in containers.conf used the same mechanism internally.

By the way, I do not see the labels either in the output from podman events --format json --stream. I see that this is both the case in the version of podman I'm using for daily usage (4.9.4) and on a freshly compiled version based on this main branch. Is this expected?

If labels were part of the output from podman events, I think I could come up with a solution for my specific use case.

[Luap99]

The labels all get merged into Attributes, not really perfect I know. The event struct is a bit of a mess. I don't know why it ended up like that, maybe docker compat?!

[fpoirotte]

FWIW, I tried to use OCI hooks instead, but stumbled across issues there as well for my particular use case.

For reference, this is the full picture of what I'm trying to achieve:

• I have several pods that get started using podman kube play.
• Some of these pods make use of so-called init containers (containers that do some prep work and exit before the main containers get started).
• When one of the main containers exits (either normally, or due to an abnormal condition: signal, wrong exit code, etc.), I want to stop the whole pod (see also feature: Stop pod when one of its containers dies #16832)

This is as far as I got using hooks:

• I can access pod annotations easily from the hook (the pod's annotations are copied over to each of its containers and get passed to the hook's stdin among other things)
• Unfortunately, it's not possible to distinguish between init containers and regular containers (which is actually a show stopper for my use case but may not be much of an issue for other use cases).
• Ignoring the previous limitation, I came across other hurdles further down the road:
  • When using the "poststop" hook, it seems the hook is running using the container's user namespace. This makes it hard (though not impossible) to execute podman commands to stop the pod from within the hook itself. For a pod started in rootless mode, and assuming the user inside the container is root, this requires reversing the user mapping from the namespace (using /proc/self/uid_map), manually setting XDG_RUNTIME_DIR and passing additional options to podman commands like --root, --runroot & --tmpdir.
  • podman will deadlock when calling podman pod stop <pod> for within the hook. This is expected behavior (the hook is being run due to a container being deleted from the pod, and a lock is maintained on the pod while the hook has not returned). This can be worked around by using commands like nohup & disown to run the podman pod stop command in the background (it will wait there until the lock is released and will run after that).

[github-actions]

A friendly reminder that this issue had no activity for 30 days.