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

log driver - Interpolate fields into log tag #15384

Merged
merged 1 commit into from Sep 17, 2015

Conversation

Projects
None yet
@phil-monroe
Contributor

phil-monroe commented Aug 6, 2015

Fixes #15058

Substitute variables about the context of the container into the syslog tag. The following go templates are added:

  • {{.ID}} - The first 12 characters of the container id.
  • {{.FullID}} - The full id of the container.
  • {{.Name}} - The name of the container.
  • {{.ImageID}} - The first 12 characters of the image id used for the container.
  • {{.ImageFullID}} - The full id of the image used for the container.
  • {{.ImageName}} - The name of the image used for the container.

example:

docker run --log-driver=syslog --log-opt syslog-tag="{{.ImageName}}/{{.Name}}/{{.ID}}" --name foobar hello-world

output in syslog:

Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]: Hello from Docker.
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]: This message shows that your installation appears to be working correctly.
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]: To generate this message, Docker took the following steps:
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:  1. The Docker client contacted the Docker daemon.
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:  2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:     (Assuming it was not already locally available.)
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:  3. The Docker daemon created a new container from that image which runs the
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:     executable that produces the output you are currently reading.
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:  4. The Docker daemon streamed that output to the Docker client, which sent it
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:     to your terminal.
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]: To try something more ambitious, you can run an Ubuntu container with:
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:  $ docker run -it ubuntu bash
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]: For more examples and ideas, visit:
Aug  6 22:20:04 80fbe5afa9a9 docker/hello-world/foobar/c24f89499fce[952]:  http://docs.docker.com/userguide/
@icecrime

This comment has been minimized.

Show comment
Hide comment
@icecrime

icecrime Aug 7, 2015

Contributor

Cool, seems like a good idea (and code LGTM). @LK4D4 WDYT?

Contributor

icecrime commented Aug 7, 2015

Cool, seems like a good idea (and code LGTM). @LK4D4 WDYT?

@phemmer

This comment has been minimized.

Show comment
Hide comment
@phemmer

phemmer Aug 7, 2015

Contributor

I think the idea is sound, but personally I would prefer go template formatting. We already have a few commands that use go templates, and I would prefer not to see another template format.

If the template had access to the ContainerJSON object, that'd be even better, as then the template would support the same fields as docker inspect. But this is probably too complex.

Contributor

phemmer commented Aug 7, 2015

I think the idea is sound, but personally I would prefer go template formatting. We already have a few commands that use go templates, and I would prefer not to see another template format.

If the template had access to the ContainerJSON object, that'd be even better, as then the template would support the same fields as docker inspect. But this is probably too complex.

@eolamey

This comment has been minimized.

Show comment
Hide comment
@eolamey

eolamey Aug 7, 2015

Contributor

There is an opened pull request to address the same issue for the fluentd driver, and it uses go templates.

Contributor

eolamey commented Aug 7, 2015

There is an opened pull request to address the same issue for the fluentd driver, and it uses go templates.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Aug 7, 2015

Contributor

+1 for go-template if we do this.

Contributor

cpuguy83 commented Aug 7, 2015

+1 for go-template if we do this.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 7, 2015

Contributor

Updated to follow the go template convention and include documentation.

Contributor

phil-monroe commented Aug 7, 2015

Updated to follow the go template convention and include documentation.

@icecrime

This comment has been minimized.

Show comment
Hide comment
@icecrime

icecrime Aug 7, 2015

Contributor

@phemmer Good call thanks. Moving to code review.

Contributor

icecrime commented Aug 7, 2015

@phemmer Good call thanks. Moving to code review.

Show outdated Hide outdated daemon/logger/syslog/syslog.go
@@ -167,3 +178,31 @@ func parseFacility(facility string) (syslog.Priority, error) {
return syslog.Priority(0), errors.New("invalid syslog facility")
}
func parseTag(ctx logger.Context) (string, error) {
tag := ctx.Config["syslog-tag"]

This comment has been minimized.

@thaJeztah

thaJeztah Aug 7, 2015

Member

Would it make sense to move this (and setting the default (line 194)) outside of this function; I.e. pass a template and the "tag" and return the result. This would open up the possibility to re-use this for other log drivers at some point.

(Thinking out loud here :-))

@thaJeztah

thaJeztah Aug 7, 2015

Member

Would it make sense to move this (and setting the default (line 194)) outside of this function; I.e. pass a template and the "tag" and return the result. This would open up the possibility to re-use this for other log drivers at some point.

(Thinking out loud here :-))

This comment has been minimized.

@phil-monroe

phil-monroe Aug 7, 2015

Contributor

So something like:

func parseTag(ctx logger.Context, tagTemplate string, defaultTagTemplate string) (string, error) {
    if tagTemplate == "" {
        tagTemplate = defaultTagTemplate
    }
    //...
}

and would be used like so:

tag, err := parseTag(ctx, ctx.Config["syslog-tag"], "{{.ID}}")
@phil-monroe

phil-monroe Aug 7, 2015

Contributor

So something like:

func parseTag(ctx logger.Context, tagTemplate string, defaultTagTemplate string) (string, error) {
    if tagTemplate == "" {
        tagTemplate = defaultTagTemplate
    }
    //...
}

and would be used like so:

tag, err := parseTag(ctx, ctx.Config["syslog-tag"], "{{.ID}}")

This comment has been minimized.

@thaJeztah

thaJeztah Aug 7, 2015

Member

Yes, something along that line. I'm not really a code reviewer here 😊, but I expect that other log-drivers may want to use templating as well, so having something more reusable would be great.

Perhaps some other people have suggestions here (@LK4D4 ?)

@thaJeztah

thaJeztah Aug 7, 2015

Member

Yes, something along that line. I'm not really a code reviewer here 😊, but I expect that other log-drivers may want to use templating as well, so having something more reusable would be great.

Perhaps some other people have suggestions here (@LK4D4 ?)

This comment has been minimized.

@izaakschroeder

izaakschroeder Aug 8, 2015

+1 to something reusable.

@izaakschroeder

izaakschroeder Aug 8, 2015

+1 to something reusable.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 10, 2015

Contributor

Updated to make the code hopefully more reusable.

Contributor

phil-monroe commented Aug 10, 2015

Updated to make the code hopefully more reusable.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 10, 2015

Contributor

Just pushed an update to namespace the helper method as to not clutter logger.go and add some unit specs.

Contributor

phil-monroe commented Aug 10, 2015

Just pushed an update to namespace the helper method as to not clutter logger.go and add some unit specs.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 11, 2015

Contributor

Do those build failures seem like they relate to this or should just be retried?

Contributor

phil-monroe commented Aug 11, 2015

Do those build failures seem like they relate to this or should just be retried?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 13, 2015

Member

@phil-monroe I triggered a rebuild; let's see 👍

Member

thaJeztah commented Aug 13, 2015

@phil-monroe I triggered a rebuild; let's see 👍

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 13, 2015

Contributor

@thaJeztah seems like things passed.

@icecrime / @cpuguy83 / @phemmer / @eolamey - Any other comments for the code?

Contributor

phil-monroe commented Aug 13, 2015

@thaJeztah seems like things passed.

@icecrime / @cpuguy83 / @phemmer / @eolamey - Any other comments for the code?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Aug 17, 2015

Contributor

@phil-monroe Have you considered using the existing Context struct and adding methods to get the fields we want to support to that directly?

Contributor

cpuguy83 commented Aug 17, 2015

@phil-monroe Have you considered using the existing Context struct and adding methods to get the fields we want to support to that directly?

@mariussturm

This comment has been minimized.

Show comment
Hide comment
@mariussturm

mariussturm Aug 21, 2015

Contributor

This should also be consistent for all logging drivers which support tags, not only the syslog-driver.

Contributor

mariussturm commented Aug 21, 2015

This should also be consistent for all logging drivers which support tags, not only the syslog-driver.

@calavera

This comment has been minimized.

Show comment
Hide comment
@calavera

calavera Aug 24, 2015

Contributor

I agree with @mariussturm. @phil-monroe can you make changes in the other drivers too?

Contributor

calavera commented Aug 24, 2015

I agree with @mariussturm. @phil-monroe can you make changes in the other drivers too?

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 25, 2015

Contributor

Sorry for the delay, I've been on vacation. I'll get the changes in here soon.

@mariussturm, @calavera - Sure thing.

@cpuguy83 - For some reason I thought the logger.Context was crucial to the container and was worried that someone could exploit the function capabilities of go templates to do something dangerous. On second look, I don't think that there should be any real security concern from giving raw access to the
logger.Context. Do you (or anyone) think that there could be a security issue with that? I agree that helper methods on that struct would be better than a separate context if there aren't any concerns there. I'm probably being overly sensitive here as I'm new to go and the docker codebase.

Contributor

phil-monroe commented Aug 25, 2015

Sorry for the delay, I've been on vacation. I'll get the changes in here soon.

@mariussturm, @calavera - Sure thing.

@cpuguy83 - For some reason I thought the logger.Context was crucial to the container and was worried that someone could exploit the function capabilities of go templates to do something dangerous. On second look, I don't think that there should be any real security concern from giving raw access to the
logger.Context. Do you (or anyone) think that there could be a security issue with that? I agree that helper methods on that struct would be better than a separate context if there aren't any concerns there. I'm probably being overly sensitive here as I'm new to go and the docker codebase.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 25, 2015

Contributor

@mariussturm, @calavera, @cpuguy83 - Updated to take your comments into account

Quick question: Since we are trying to standardize on the way log tags are parsed, should there be a common log-opt between all of the drivers? Something like:

docker run --log-driver=ANY_DRIVER --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"

instead of

    docker run --log-driver=syslog  --log-opt syslog-tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
    docker run --log-driver=fluentd --log-opt fluentd-tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
    docker run --log-driver=gelf    --log-opt gelf-tag="{{.ImageName}}/{{.Name}}/{{.ID}}"

I figure for backwards compatibility we would support them all for now and maybe eventually deprecate the other log opts. Thoughts?

Contributor

phil-monroe commented Aug 25, 2015

@mariussturm, @calavera, @cpuguy83 - Updated to take your comments into account

Quick question: Since we are trying to standardize on the way log tags are parsed, should there be a common log-opt between all of the drivers? Something like:

docker run --log-driver=ANY_DRIVER --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"

instead of

    docker run --log-driver=syslog  --log-opt syslog-tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
    docker run --log-driver=fluentd --log-opt fluentd-tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
    docker run --log-driver=gelf    --log-opt gelf-tag="{{.ImageName}}/{{.Name}}/{{.ID}}"

I figure for backwards compatibility we would support them all for now and maybe eventually deprecate the other log opts. Thoughts?

@phil-monroe phil-monroe changed the title from syslog driver - Interpolate fields into syslog tag to log driver - Interpolate fields into log tag Aug 25, 2015

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 25, 2015

Contributor

From what I can tell, the DockerDaemonSuite.TestCleanupMountsAfterCrash failure seems to not be related to this PR since It is failing for other builds as well.

Contributor

phil-monroe commented Aug 25, 2015

From what I can tell, the DockerDaemonSuite.TestCleanupMountsAfterCrash failure seems to not be related to this PR since It is failing for other builds as well.

@calavera

This comment has been minimized.

Show comment
Hide comment
@calavera

calavera Aug 26, 2015

Contributor

I think it makes sense to unify all those in a single tag option, but still allow the driver specific ones for backwards compatibility. We can keep the client options, set the tag option with one of the deprecated ones if they exist, and internally use only tag.

Contributor

calavera commented Aug 26, 2015

I think it makes sense to unify all those in a single tag option, but still allow the driver specific ones for backwards compatibility. We can keep the client options, set the tag option with one of the deprecated ones if they exist, and internally use only tag.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 26, 2015

Contributor

@calavera: Added the functionality to prefer --log-opt tag=XXX.

Everyone else: any more comments?

Contributor

phil-monroe commented Aug 26, 2015

@calavera: Added the functionality to prefer --log-opt tag=XXX.

Everyone else: any more comments?

@calavera

This comment has been minimized.

Show comment
Hide comment
@calavera

calavera Aug 27, 2015

Contributor

Thanks @phil-monroe 🤘

Code LGTM, but I guess we should add the new tag to the documentation, saying that the other options will be deprecated in the future, although they keep still working.

Contributor

calavera commented Aug 27, 2015

Thanks @phil-monroe 🤘

Code LGTM, but I guess we should add the new tag to the documentation, saying that the other options will be deprecated in the future, although they keep still working.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 27, 2015

Contributor

@calavera: Yeah, I plan on updating the documentation as well. Just wanted to make sure the code is finalized.

Contributor

phil-monroe commented Aug 27, 2015

@calavera: Yeah, I plan on updating the documentation as well. Just wanted to make sure the code is finalized.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Aug 27, 2015

Contributor

Code LGTM, once you add docs we can move to docs review.

Contributor

cpuguy83 commented Aug 27, 2015

Code LGTM, once you add docs we can move to docs review.

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Aug 28, 2015

Contributor

Updated the documentation. Let me know what you think.

Contributor

phil-monroe commented Aug 28, 2015

Updated the documentation. Let me know what you think.

Show outdated Hide outdated docs/reference/logging/overview.md
The `syslog-tag` specifies a tag that identifies the container's syslog messages. By default,
the system uses the first 12 characters of the container id. To override this behavior, specify
a `syslog-tag` option
See the [log tag option](/reference/logging/log_tags/) documentation on how to format log tags.

This comment has been minimized.

@thaJeztah

thaJeztah Aug 28, 2015

Member

I think we should give slightly more context to this link. Something like this;

By default, Docker uses the first 12 characters of the container ID to tag log messages.
Refer to the [log tag option documentation](/reference/logging/log_tags/) for customizing
the log tag format.
@thaJeztah

thaJeztah Aug 28, 2015

Member

I think we should give slightly more context to this link. Something like this;

By default, Docker uses the first 12 characters of the container ID to tag log messages.
Refer to the [log tag option documentation](/reference/logging/log_tags/) for customizing
the log tag format.
Show outdated Hide outdated docs/reference/logging/fluentd.md
in the tags to their values at startup. If you use `docker rename` to rename a
container, the new name is not be reflected in `fluentd` messages. Instead,
these messages continue to use the original container name.
See the [log tag option](/reference/logging/log_tags/) documentation on how to format log tags.

This comment has been minimized.

Show outdated Hide outdated docs/reference/logging/overview.md
@@ -106,24 +104,18 @@ driver to a GELF remote server at `192.168.0.42` on port `12201`
$ docker run --log-driver=gelf --log-opt gelf-address=udp://192.168.0.42:12201
The `gelf-tag` option specifies a tag for easy container identification.
See the [log tag option](/reference/logging/log_tags/) documentation on how to format log tags.

This comment has been minimized.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 29, 2015

Member

Added some suggestions for the docs; given that we're deprecating the driver specific "tag" options, can you add that to the deprecated features document. It should mention that the syslog-tag, gelf-tag and fluentd-tag log options are deprecated in docker 1.9, and will be removed in docker 1.11 (we try to keep deprecated options around for 2 releases)

Thanks @phil-monroe ! Great work altogether

ping @moxiegirl

Member

thaJeztah commented Aug 29, 2015

Added some suggestions for the docs; given that we're deprecating the driver specific "tag" options, can you add that to the deprecated features document. It should mention that the syslog-tag, gelf-tag and fluentd-tag log options are deprecated in docker 1.9, and will be removed in docker 1.11 (we try to keep deprecated options around for 2 releases)

Thanks @phil-monroe ! Great work altogether

ping @moxiegirl

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 29, 2015

Member

Oh, and ping @albers because the completion scripts will need to be updated ❤️

Member

thaJeztah commented Aug 29, 2015

Oh, and ping @albers because the completion scripts will need to be updated ❤️

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 29, 2015

Member

Almost forgot; ping @sdurrheimer for zsh completions, once this is merged 👍

Member

thaJeztah commented Aug 29, 2015

Almost forgot; ping @sdurrheimer for zsh completions, once this is merged 👍

@albers

This comment has been minimized.

Show comment
Hide comment
@albers

albers Aug 29, 2015

Member

I'll add this to bash completion. Thanks for pinging me, @thaJeztah.

Member

albers commented Aug 29, 2015

I'll add this to bash completion. Thanks for pinging me, @thaJeztah.

@sdurrheimer sdurrheimer referenced this pull request Aug 29, 2015

Merged

Zsh completion updates #15915

3 of 3 tasks complete
@@ -0,0 +1,39 @@
<!--[metadata]>

This comment has been minimized.

@moxiegirl

moxiegirl Aug 29, 2015

Contributor

@phil-monroe Thanks for the contribution! Nicely done. Can you add a link to this file in the reference/logging/index.md page? Some tweaks to this page, table works better for reference also I think better to show a simple use oftag first then use of the templates.

--> https://gist.github.com/moxiegirl/5d5fbd9bd282c3dce3bd

Log Tags

The tag log option specifies how to format a tag that identifies the
container's log messages. By default, the system uses the first 12 characters of
the container id. To override this behavior, specify a tag option:

docker run --log-driver=fluentd --log-opt fluentd-address=myhost.local:24224 --log-opt tag="mailer"

Docker supports some special template markup you can use when specifying a tag's value:

Markup Description
{{.ID}} The first 12 characters of the container id.
{{.FullID}} The full container id.
{{.Name}} The container name.
{{.ImageID}} The first 12 characters of the container's image id.
{{.ImageFullID}} The container's full image identifier.
{{.ImageName}} The name of the image used by the container.

For example, specifying a --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" value yields syslog log lines like:

Aug  7 18:33:19 HOSTNAME docker/hello-world/foobar/5790672ab6a0[9103]: Hello from Docker.

At startup time, the system sets the container_name field and {{.Name}} in
the tags. If you use docker rename to rename a container, the new name is not
reflected in the log messages. Instead, these messages continue to use the
original container name.

For advanced usage, the generated tag's use go
templates
and the container's logging
context
.

Note:The driver specific log options syslog-tag, fluentd-tag and
gelf-tag still work for backwards compatibility. However, going forward you
should standardize on using the generic tag log option instead.

@moxiegirl

moxiegirl Aug 29, 2015

Contributor

@phil-monroe Thanks for the contribution! Nicely done. Can you add a link to this file in the reference/logging/index.md page? Some tweaks to this page, table works better for reference also I think better to show a simple use oftag first then use of the templates.

--> https://gist.github.com/moxiegirl/5d5fbd9bd282c3dce3bd

Log Tags

The tag log option specifies how to format a tag that identifies the
container's log messages. By default, the system uses the first 12 characters of
the container id. To override this behavior, specify a tag option:

docker run --log-driver=fluentd --log-opt fluentd-address=myhost.local:24224 --log-opt tag="mailer"

Docker supports some special template markup you can use when specifying a tag's value:

Markup Description
{{.ID}} The first 12 characters of the container id.
{{.FullID}} The full container id.
{{.Name}} The container name.
{{.ImageID}} The first 12 characters of the container's image id.
{{.ImageFullID}} The container's full image identifier.
{{.ImageName}} The name of the image used by the container.

For example, specifying a --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" value yields syslog log lines like:

Aug  7 18:33:19 HOSTNAME docker/hello-world/foobar/5790672ab6a0[9103]: Hello from Docker.

At startup time, the system sets the container_name field and {{.Name}} in
the tags. If you use docker rename to rename a container, the new name is not
reflected in the log messages. Instead, these messages continue to use the
original container name.

For advanced usage, the generated tag's use go
templates
and the container's logging
context
.

Note:The driver specific log options syslog-tag, fluentd-tag and
gelf-tag still work for backwards compatibility. However, going forward you
should standardize on using the generic tag log option instead.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Sep 15, 2015

Contributor

Ping, any chance you can update the docs?

Contributor

cpuguy83 commented Sep 15, 2015

Ping, any chance you can update the docs?

@moxiegirl

This comment has been minimized.

Show comment
Hide comment
@moxiegirl

moxiegirl Sep 15, 2015

Contributor

@cpuguy83 if necessary, I can carry. Just an FYI

Contributor

moxiegirl commented Sep 15, 2015

@cpuguy83 if necessary, I can carry. Just an FYI

@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Sep 16, 2015

Contributor

Sorry for the delay! Crazy couple of weeks. I'll try and finish them off
today.

On Tuesday, September 15, 2015, moxiegirl notifications@github.com wrote:

@cpuguy83 https://github.com/cpuguy83 if necessary, I can carry. Just
an FYI


Reply to this email directly or view it on GitHub
#15384 (comment).

Phil Monroe

Contributor

phil-monroe commented Sep 16, 2015

Sorry for the delay! Crazy couple of weeks. I'll try and finish them off
today.

On Tuesday, September 15, 2015, moxiegirl notifications@github.com wrote:

@cpuguy83 https://github.com/cpuguy83 if necessary, I can carry. Just
an FYI


Reply to this email directly or view it on GitHub
#15384 (comment).

Phil Monroe

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Sep 16, 2015

Contributor

Thanks!

Contributor

cpuguy83 commented Sep 16, 2015

Thanks!

log driver - add ability to interpolate container context into the lo…
…g tag field

Signed-off-by: Philip Monroe <phil@philmonroe.com>
@phil-monroe

This comment has been minimized.

Show comment
Hide comment
@phil-monroe

phil-monroe Sep 16, 2015

Contributor

Documentation updated. Sorry for the radio silence!

Contributor

phil-monroe commented Sep 16, 2015

Documentation updated. Sorry for the radio silence!

@moxiegirl

This comment has been minimized.

Show comment
Hide comment
@moxiegirl

moxiegirl Sep 17, 2015

Contributor

@phil-monroe Thanks! LGTM

Contributor

moxiegirl commented Sep 17, 2015

@phil-monroe Thanks! LGTM

cpuguy83 added a commit that referenced this pull request Sep 17, 2015

Merge pull request #15384 from phil-monroe/15058-include-name-in-sysl…
…og-tag

log driver - Interpolate fields into log tag

@cpuguy83 cpuguy83 merged commit 4dfa996 into moby:master Sep 17, 2015

4 checks passed

docker/dco-signed All commits signed
Details
experimental Jenkins build Docker-PRs-experimental 6966 has succeeded
Details
janky Jenkins build Docker-PRs 15716 has succeeded
Details
windows Jenkins build Windows-PRs 12745 has succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment