compose v2 not sending meaningful user agent string

[thespad]

Description

When sending a pull request to a registry docker-compose 1.x will send a user agent which includes something like UpstreamClient(docker-compose/1.29.2 docker-py/5.0.0 Linux/5.4.0-88-generic) clearly identifying that the client is docker-compose and what its version is. Compose 2.x appears to send a generic user agent in the form UpstreamClient(Docker-Client/unknown-version \(linux\)).

Steps to reproduce the issue:

1. User docker compose v2 to pull from a registry you control
2. Observe the user agent sent with the request

Describe the results you received:
A user agent string of docker/20.10.9 go/go1.16.8 git-commit/79ea9d3 kernel/5.4.0-77-generic os/linux arch/amd64 UpstreamClient(Docker-Client/unknown-version \(linux\))

Describe the results you expected:
A user agent string with specific client and version information in keeping with the 1.x behaviour

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version v2.1.0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.3-docker)
  compose: Docker Compose (Docker Inc., v2.1.0)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 56
  Running: 56
  Paused: 0
  Stopped: 0
 Images: 59
 Server Version: 20.10.9
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 5b46e404f6b9f661a205e28d59c982d3634148f8
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-77-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.64GiB
 Name: docker2
 ID: 67LS:QX2S:7P4H:CTCH:IGKD:4BKW:6HYY:46PB:LHNR:IXBV:CDSP:FXXJ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: thespad
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details:

[ndeloof]

Compose v2 is implemented using the Docker CLI plugin mechanism, and as such has no control on the docker API client implementation (we receive an APIClient interface implementation in main). I don't think there's any way we tweak the user-agent being used under the hood for http API calls

[ndeloof]

maybe this could be a simple but useful improvement to plugin.Run to accept DockerCliOption so that a plugin can tweak the SDK client, typically for this use-case: customizing User-Agent could help track usage and adoption :)
cc @thaJeztah @nebuk89

[thespad]

This would be extremely helpful. For context I'm part of linuxserver.io and being able to identify which clients and versions our users are using is a big plus for us.

Historically we've seen around 1/4 of our users using compose but as people switch to v2 we'll lose that visibility, and we don't want to assume that any docker-client/unknown-version is some release of compose v2 for obvious reasons.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thespad]

This is still something we consider to be a big deal, it's frustrating not to be able to even identify compose v2 users let alone more specific info like the version in use.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[ndeloof]

Docker CLI explicitly prevent user to set a custom User-Agent header
https://github.com/docker/cli/blob/20923dfbc7fa7e338b6a2ee9df0dd4b713882186/cli/command/cli.go#L270-L274

@thaJeztah do you know the reason? Is this a rule we could relax?

[ndeloof]

Based on https://github.com/docker/cli/blob/20923dfbc7fa7e338b6a2ee9df0dd4b713882186/cli/command/cli.go#L270-L274 code explicitly preventing a CLI plugin to use an alternate User-Agent, I'm closing this issue as "not planned"