APIv2: No events on image build

[marusak]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
podman build does not produce any event in the REST API.

Steps to reproduce the issue:

1. sudo curl --unix-socket /run/podman/podman.sock http://d/v1.24/events - start listening on events

2. sudo podman build . (some simple Dockerfile)

3. sudo podman images -a shows a new image, but there is no events in the step 1. (sudo podman pull produces event)

Describe the results you received:

Describe the results you expected:
Some events that the image list has changed.

Output of podman version:

Version:      2.0.1
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

[vrothberg]

Thanks for opening an issue, @marusak. I can reproduce: both podman build and podman-remote build do not yield an event.

[vrothberg]

I found some time to have a closer look. It seems there is no build event at all. @mheon did we have some in previous versions?

[mheon]

I don't see how we would, given that the events code lives in Libpod and image build is entirely in Buildah land

…

On Mon, Jul 20, 2020, 06:29 Valentin Rothberg ***@***.***> wrote: I found some time to have a closer look. It seems there is no build event at all. @mheon <https://github.com/mheon> did we have some in previous versions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7022 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCDO5ITCTHH2BVPR2RDR4QMATANCNFSM4PB7LGXA> .

[vrothberg]

I don't see how we would, given that the events code lives in Libpod and image build is entirely in Buildah land

I think it's pretty similar to pulling, which happens in c/image. We could track down all buildah API calls in the code and record events there. Wouldn't that work?

[mheon]

The problem specifically with build is that we immediately hand off from our CLI to the Buildah CLI - the other calls are usually a lot more integrated with the rest of our code (commit on images, for example - uses Buildah code, but just library calls, not handing off the entire responsibility, so we can embed the events calls).

We could potentially generate an event before we ever call Buildah, but I don't think we know some important things at that point (ID of the final image being the big one)

[rhatdan]

Let's integrate something intoBuildah, that it can call functions on events. Would seem to be the best way.

[mheon]

We should move the events code into c/common to allow Buildah to also call into it.

[mheon]

We will have issues if they want to do container events, though, because we can't see those in podman ps or the list API, so Cockpit will get very confused.

[vrothberg]

We will have issues if they want to do container events, though, because we can't see those in podman ps or the list API, so Cockpit will get very confused.

Very good point. I think Buildah as a tool shouldn't do events, but buildah as a library should provide a way to opt-in to events. This way, Podman could call the buildah API with events enabled where we'd get events on image pulls, commits, builds etc.

[vrothberg]

I suggest that we can tackle that after we split libpod from Podman.