Add tail and since to service logs#31500
Conversation
daemon/cluster/services.go
Outdated
There was a problem hiding this comment.
Yeah, there should be a different message for parse errors and negative values.
There was a problem hiding this comment.
I submit a CFB: Call For Bikeshedding.
There was a problem hiding this comment.
(I'm sorry, I mean it is legitimately a bad error message and I do need help getting it better, and it would benefit from some light bikeshedding to get right)
There was a problem hiding this comment.
My suggestion:
if err != nil {
return errors.New(`Tail must be a non-negative integer, or "all"`)
}
if t < 0 {
return errors.New("negative Tail values are not supported")
}(I don't actually think the current log message is bad for the second case, but I have a slight preference for talking about the domain of the parameter, instead of what a negative parameter would do if it was supported.)
|
Can you please add tests for these features? |
|
I'm finally remembering to run I'll get right on it @aaronlehmann . |
ce43475 to
c35a984
Compare
|
pushed up new changes. tests are gonna fail, this requires a revendor from swarmkit master, which someone mentioned is currently in a different PR |
There was a problem hiding this comment.
Non-blocking: Seems like the sleep could be a lot shorter, since we're parsing the timestamps later on as an argument to --since, instead of fudging it.
There was a problem hiding this comment.
fixed this sleep to be shorter.
There was a problem hiding this comment.
Non-blocking: might be better to use waitAndAssert to wait for docker service logs to return the full set of logs.
There was a problem hiding this comment.
waitAndAssert is undocumented, headache-causing voodoo magic and I was trying to avoid it if at all possible.
There was a problem hiding this comment.
I think this could be racy. If service logs runs before the container finishes its output, the test might fail. Should we wait for the task to finish running instead of waiting for it to start running?
There was a problem hiding this comment.
you're almost certainly correct, and the possibility of a race also exists in the since test as well, as I've just realized (sleeping does not guarantee that anything else has happened on the system in the meantime.)
There was a problem hiding this comment.
Same comment as https://github.com/docker/docker/pull/31500/files#r104269245
|
This is not introducing API changes (i.e. the API already supported this, and is documented?) |
|
@thaJeztah I'm not sure if this is documented or not, but the API endpoints and CLI flags all existed, they just weren't wired up. |
|
It's probably here; https://github.com/docker/docker/blob/f9bd8ec8b268581f93095c5a80679f0a8ff498bf/api/swagger.yaml#L7646-L7726, but check if it's all documented. Given that it's been an experimental feature, if we expect this feature to leave experimental in docker 17.04, it should be mentioned in the API changes for API 1.27 https://github.com/docker/docker/blob/3a88a24d23e6eb1ca521cd9ab6e306d4ba1c1464/docs/api/version-history.md#v127-api-changes (or 1.28 if it's gonna leave experimental in 17.05 |
|
Right now there is a flaky test in my local branch that I'm trying to sort out before I finish this PR. |
c35a984 to
4481bba
Compare
|
Fixed the flaky integration test. |
|
There probably needs to be a revendoring for the integration test to pass |
|
This definitely need revendoring for the integration tests to pass. There is a separate open PR for revendoring swarmkit. |
|
@dperny #31535 (comment) was merged |
|
Rebasing, running tests, and pushing now. |
4481bba to
fe9e67d
Compare
|
Tentatively targeting 17.04.0 |
|
@dperny I see a few of @aaronlehmann's comments not being addressed - could you double check? |
|
His comments don't appear addressed because the diff for those particular lines is the same; the comments have been addressed after those lines. |
daemon/cluster/services.go
Outdated
There was a problem hiding this comment.
non-blocking: maybe use errors.Wrap to add some context to the error.
daemon/cluster/services.go
Outdated
There was a problem hiding this comment.
non-blocking: maybe use errors.Wrap to add some context to the error.
There was a problem hiding this comment.
As far as I understand, yes. There's a stream from the engine to the manager, and a stream from the manager to the client. While lines from different nodes could get interleaved, I can't think of any way that log lines from a single node would change their order.
There was a problem hiding this comment.
Someone, I cannot remember who, has mentioned that they have seen engine-side logs come back in the wrong order. I don't have proof, this is something like a third-hand account, i'm not sure if it's a bug or a consequence of some technical limitation, and i'm not even sure it's real. would it be alright for me to leave these TODOs in, in case the tests fail later, so someone might know why?
There was a problem hiding this comment.
i've reworded the TODOs into regular comments.
|
LGTM |
fe9e67d to
6860fe5
Compare
There was a problem hiding this comment.
Should be TestServiceLogsCompleteness
Comment there looks good, though
This change adds the ability to do --tail and --since on docker service logs. It wires up the API endpoints to each other and fixes some older bugs. It adds integration tests for these new features. Signed-off-by: Drew Erny <drew.erny@docker.com>
6860fe5 to
8dc437b
Compare
Add tail and since to service logs
- What I did
This change adds the ability to do --tail and --since on docker service logs.
Should also fix #31307.
Part of a series of changes in #31399.
- How I did it
It wires up the API endpoints to each other and fixes some older bugs.
- How to verify it
Make a service, note how passing
--tailand--since- Description for the changelog
docker service logsnow supportssinceandtailoptions.- A picture of a cute animal (not mandatory but encouraged)
