New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event all the things! #18888
Event all the things! #18888
Conversation
f3061c0
to
f4b543b
Compare
Nice! Looking at the command line output, should we put the type of event earlier on? the type of event is kinda hurried now. E.g.
Or
We could even consider a |
Obligatory regular expression meme (do not look at @thaJeztah I'm okay with moving the action at the beginning, let's wait to hear from other people to see if we agree in a format and I only need to change it once 😸 |
@calavera haha, absolutely, just my first impression looking at it. great work otherwise, I like it! |
Oh, and |
3cef129
to
411e141
Compare
ID: imageID.String(), | ||
Name: newTag.String(), | ||
} | ||
daemon.EventsService.Log("tag", eventtypes.ImageEventType, actor) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe all the eventtypes.ImageEventType
events should include the image labels in Actor.Attributes
. Previously this was being injected by daemon.GetLabels()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they're all done except for this one place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😔 fixing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually there are a couple more places in pull/push
Nice! I think this is awesome. We'll be able to make use of the new event data in the soon-to-be-released |
f063836
to
ce954d8
Compare
@thaJeztah one thing that I don't like about your suggested syntax is that it becomes harder to parse, because both name and attributes are optional at the end and are between parenthesis. But I'm open to suggestions. |
maybe we should add the name to the attributes. That would leave us only with one optional field, which I think it's better:
Example:
|
ce954d8
to
e9054ee
Compare
This is really impressive. Very nice work! A couple questions. Will there be a precise documentation of what are the possible values (states) to expect? Regarding the new changes to layering, image IDs 'n stuff, would it make sense to also include digest? How about untagging an image, will I get the tag name? And last thing: would be super cool to unite events status and |
@calavera oh, I like the suggestion of adding name to attributes. In addition, we can still add |
@TomasTomecek yes, with the new attributes, we can include more relevant information about the events, like that one. This is not a one time only change, we can improve the information we add to each event in the future.
I'm not completely sure that's related to this change. I think we should discuss it further, but I understand your issues. |
9eb3945
to
93be08b
Compare
@thaJeztah I've changed the log format to put the name in the attributes. I've also added a new feature to be able to filter by event type with Can I have some 👍 / 👎 to all this before moving it to code review? @TomasTomecek documentation is coming. |
7027b1b
to
5afee52
Compare
Signed-off-by: David Calavera <david.calavera@gmail.com>
good point @moxiegirl. The API still works with old fields, but I agree that's worth noticing in the deprecation document. I added it already. |
docs LGTM @moxiegirl the API is backwards compatible, but CLI output changed, I think we should mention that in the release notes |
@thaJeztah If by release notes you mean the changelog. Then we are good. :-) |
potatoes potatos, yup that's what I meant, haha |
@calavera very nice! can't wait to play with this |
@TomasTomecek for playing; https://master.dockerproject.org is your friend :-) And please do! We can never have enough testers :) |
This is an attempt to make our events more rich and extensible.
In order to do that, we stop using
JSONMessage
as a struct to deliver events. That struct is an abomination for all kind of purposes, and the less we use it the better (imo). I created a specific purpose structure that includes new fields:container
,image
,volume
andnetwork
.create
,destroy
,mount
,connect
and so on.ID
,Name
andAttributes
. Attributes is an open map to send extra metadata, like the labels for a container event.IMPORTANT: This change is backwards compatible at the API level, but not at the CLI level.
The new event structure preserves old fields that we've been using until now for container and image events. People consuming the API won't see any difference in those events, but will start to see events without information in those fields, because they come from storage and network operations.
I've included a test to guarantee that we keep that backwards compatible information: https://github.com/docker/docker/compare/master...calavera:event_types?expand=1#diff-1e68c88f5c9fa605c0f84199cd04feb0R38
The CLI output has been completely modified and it's standard for all types of events, the syntax is as follow:
The attributes are listed in KEY=VALUE format to be consistent with other places where we show this kind of values, like labels.
Some examples:
Networking and container events
Network events that operate on containers (connect and disconnect) include the container id as part of the attributes:
Storage and container events:
Storage events that operate on containers include the container id as part of the attributes:
Future improvements out of the scope here
TODO
/cc @coolljt0725, @dnephin
/events
API endpoint #18164docker events --filter container=foo
is broken as of 1.9.0 #18453