- Stop serializing JSONMessage in favor of events.Message.
- Keep backwards compatibility with JSONMessage for container events.
Signed-off-by: David Calavera <david.calavera@gmail.com>
We keep only one logic to test event related behavior that will help us
diagnose flacky event errors.
Signed-off-by: David Calavera <david.calavera@gmail.com>
This is useful for cluster systems such as swarm to sync the image
state when new images are successfully built.
Signed-off-by: Shijiang Wei <mountkin@gmail.com>
Although having a request ID available throughout the codebase is very
valuable, the impact of requiring a Context as an argument to every
function in the codepath of an API request, is too significant and was
not properly understood at the time of the review.
Furthermore, mixing API-layer code with non-API-layer code makes the
latter usable only by API-layer code (one that has a notion of Context).
This reverts commit de41640435, reversing
changes made to 7daeecd42d.
Signed-off-by: Tibor Vass <tibor@docker.com>
Conflicts:
api/server/container.go
builder/internals.go
daemon/container_unix.go
daemon/create.go
This PR adds a "request ID" to each event generated, the 'docker events'
stream now looks like this:
```
2015-09-10T15:02:50.000000000-07:00 [reqid: c01e3534ddca] de7c5d4ca927253cf4e978ee9c4545161e406e9b5a14617efb52c658b249174a: (from ubuntu) create
```
Note the `[reqID: c01e3534ddca]` part, that's new.
Each HTTP request will generate its own unique ID. So, if you do a
`docker build` you'll see a series of events all with the same reqID.
This allow for log processing tools to determine which events are all related
to the same http request.
I didn't propigate the context to all possible funcs in the daemon,
I decided to just do the ones that needed it in order to get the reqID
into the events. I'd like to have people review this direction first, and
if we're ok with it then I'll make sure we're consistent about when
we pass around the context - IOW, make sure that all funcs at the same level
have a context passed in even if they don't call the log funcs - this will
ensure we're consistent w/o passing it around for all calls unnecessarily.
ping @icecrime @calavera @crosbymichael
Signed-off-by: Doug Davis <dug@us.ibm.com>
Adds several integration tests for `docker cp` behavior with over a dozen
tests for each of:
container -> local
local -> container
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Fixes#13107. This change enables Go duration strings
computed relative to the client machine’s time to be used
as input parameters to `docker events --since/--until`
and `docker logs --since` arguments.
Added unit tests for pkg/timeutils.GetTimestamp as well.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Move some calls to container.LogEvent down lower so that there's
less of a chance of them being missed. Also add a few more events
that appear to have been missed.
Added testcases for new events: commit, copy, resize, attach, rename, top
Signed-off-by: Doug Davis <dug@us.ibm.com>
Fix for #13175.
This change allows user-input timestamps (e.g. to `docker events
--since/--until` or `docker logs --since` to be parsed using
standard RFC3339Nano layout in Go instead of the layout that parses
all timestamps into fixed-length strings (currently buggy).
User inputs need not to be complying to the internal format
(`RFC3339NanoFixed`) anyway.
Added test case for `events --since/--until` with all possible
timestamp input formats.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Changed method declaration. Fixed all calls to dockerCmd
method to reflect the change.
resolves#12355
Signed-off-by: bobby abbott <ttobbaybbob@gmail.com>
This patch include the following fixs:
- fix image name error when docker ps
- fix docker events test failure: use the exact image name for filter
- fix docker build CI test failure due to "docker events" change
Because of change of daemon log behavior. Now we record
the exact Image name as you typed. So docker run -d busybux sh
and docker run -d busybox:latest are not the same in the log.
So it will affect the docker events. So change the related CI
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
This also seemed to be checking the ordering of the events, which
doesn't seem like something we sould be interested in this particular
test.
Added check to make sure the filtered events have the expected ID's.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>