This looks very similar to #25633, except that this also allows templating for the log group and that #25633 has more tests of the functionality. I don't think having the log group as a template makes quite as much sense, since the driver does not automatically create the log group and depends on the log group already existing; a predictable, explicit name covers this.

@samuelkarp I agree that its not ideal that the log group might not exist and I'm looking at some procedural steps to mitigate that. The existing work-around (adding awslogs-group to docker run) has the same problem, so we're not adding risk. I should add that in my tests, I'm using {{.if}}{{else}}{{end}} templates to ensure that the container has been explicitly tagged with a group name, and using a sensible default otherwise.

The conceptual distinction between groups and streams is defined here:

Log groups define groups of log streams that share the same retention, monitoring, and access control settings.

I'm running a cluster with a number of different applications and indeed different business units. I require segregating logs by group. Amazon's design of groups vs streams is reflected in the console, in IAM security and in alarms and filtering. Anyone using awslogs in anger really does need to segregate different tasks by group.

On the issue of testing, I'm happy to add more. The difference between my patch and #25633 is that I've re-used the existing (and tested) template code that was added for the fluentd logger (loggerutils.ParseLogTag) instead of using text/template directly.

/cc @vdemeester @cpuguy83

Amazon's design of groups vs streams is reflected in the console, in IAM security and in alarms and filtering.

That's correct, which is why you would normally do docker run --log-opt awslogs-group=group1 ..., docker run --log-opt awslogs-group=group2 ..., etc. This gives you explicit segregation and also enforces that you specify a predictable, well-known group name when running a container. This driver requires a log group to be specified (there is no default).

@samuelkarp Re: defaults. With my patch, I am able to do this:

docker daemon --log-driver=awslogs \
   --log-opt awslogs-region=us-east-1 \
   --log-opt awslogs-group="{{if .ContainerLabels.awslogs_group}}{{.ContainerLabels.awslogs_group}}{{else}}/edt/dev/cluster/default{{end}}" \
   --log-opt awslogs-stream="{{if .ContainerLabels.awslogs_stream_prefix}}{{.ContainerLabels.awslogs_stream_prefix}}/{{.ID}}{{else}}{{.ID}}{{end}}" \
   -D&

This allows me to have a well defined default (specified in the daemon), but also allows teams to override logging in such a way that they aren't all hosed if I switch to, e.g. fluent. For example, if I switch the cluster to fluentd, then any job with --log-opt awslogs-group will fail to launch because of the different validator. I really don't want to be in that position.

So my goals are:

1. Easy default
2. Powerful templates for groups and streams.
3. Cluster doesn't stop running jobs if I change logger.

Having teams put the log group in a label rather than an explicit --log-opt means I can do that.

I do appreciate that some people could use the template to shoot themselves in the foot, e.g. by unconditionally using machine-generated ids in the log-group template that are unlikely to have been created on AWS, but they really have to go out of their way to do that.

For example, if I switch the cluster to fluentd, then any job with --log-opt awslogs-group will fail to launch because of the different validator. I really don't want to be in that position.

This makes it sound like the real problem you're trying to solve is that each of the log drivers reject options that they're not expecting. I think that might be a more-flexible way to address this since you could make it work across all log drivers and not just this driver. If you made it so each driver ignored unknown options instead of rejecting unknown options, you could safely specify the log group as a --log-opt without worrying that an option for the wrong driver would break you.

f you made it so each driver ignored unknown options instead of rejecting unknown options, you could safely specify the log group as a --log-opt without worrying that an option for the wrong driver would break you.

If I made that patch (disabling validation of unknown options in all the other loggers) you think that would be accepted?

If I made that patch (disabling validation of unknown options in all the other loggers) you think that would be accepted?

That's a good question for the Docker maintainers 😄. I think that might be a better approach though since it more directly solves your problem than trying to hack around it with labels and templating.

I'm not sure we'd be comfortable with silently ignoring unknown options. This'll easily lead to (e.g.) users trying to use options for one driver on another one, and then opening bug reports that it doesn't work, or having a typo, and not being aware that the option is ignored.

@thaJeztah I think this is a pretty reasonable use-case for ignoring unknown options; otherwise people will try to work-around it using things like labels and you'll just end up with the same potential problems exposed through a different interface. If ignoring all unknown isn't something that you want for fear of typos, here are some other ideas:

• Ignore unknown options, but validate all options with a known prefix (e.g., the awslogs driver would validate all options that start with awslogs-, but ignore options that start with fluentd-
• Validate all option names by having each log driver register expected names and only accept registered names
• Ensure that daemon options and docker run options don't conflict by ignoring validation failures for log opts specified on the daemon if docker run specifies a different driver (e.g., if the daemon options specify the journald driver with journald-appropriate options, but someone attempts to docker run with the awslogs driver, don't pass the journald-appropriate options to the awslogs driver for validation)

hey @jamiethermo, thanks so much for your contribution, but we are going #27707 which is a similar implementation tested and more inline with others log drivers. It will land in 1.13.0 😉