Copy over compose format 3.8 from docker/cli

[sirlatrom]

Resolves #6530.

[sirlatrom]

Ping @chris-crone just in case.

[sirlatrom]

Also pinging @ulyssessouza, maybe this can get into a release sometime soon, seeing as 19.03 has already been released?

[ulyssessouza]

Just a little comment regarding the tests

[thaJeztah]

We need to check the specs for this, and other versions; I tried this a while back, but noticed there's changes in this repository that are not upstream; if they're still needed, we need to make sure they're upstreamed, but also that they find their way into current versions of the spec

See #6642 for some more details

[sirlatrom]

We need to check the specs for this, and other versions; I tried this a while back, but noticed there's changes in this repository that are not upstream; if they're still needed, we need to make sure they're upstreamed, but also that they find their way into current versions of the spec

See #6642 for some more details

Would a better approach (in terms of mergeability of this PR) be to copy over the diffs from docker/cli beween config_schema_v3.7.json and config_schema_v3.8.json, rather than the entire config_schema_v3.8.json?

[sirlatrom]

Ping @thaJeztah about #6823 (comment)

[thaJeztah]

Well, I think there should be a single source of truth for these schemas; afaik, the version in docker/cli is considered "leading", so we should look if the changes that were made in this repository should be either "upstreamed" (made in the docker/cli repository as well), or should be reverted (if no longer necessary).

I'm not familiar enough with the changes that were made in this repository to know if they are;

• specific to the Python implementation
• perhaps already addressed in other ways (upstream?)

@ulyssessouza @chris-crone would one of you know?

[chris-crone]

Well, I think there should be a single source of truth for these schemas; afaik, the version in docker/cli is considered "leading", so we should look if the changes that were made in this repository should be either "upstreamed" (made in the docker/cli repository as well), or should be reverted (if no longer necessary).

+1. Ideally we should pull what's in docker/cli out and put it into a separate repo

@ulyssessouza @chris-crone would one of you know?

I do not but @shin- may know. Otherwise we can add a ticket to our backlog to find the diffs and investigate.

[sirlatrom]

@thaJeztah @chris-crone Any takers on this one? Docker Engine has had 3.8 format support since 19.03.0, and since 3.x is generally meant to be deployed on Swarm or Compose on Kubernetes, I would argue that fields and changes made in docker/cli should override those in docker/compose for 3.x formats.

[chris-crone]

I would argue that fields and changes made in docker/cli should override those in docker/compose for 3.x formats.

I would agree on this. We have an internal ticket tracking this, we just haven't prioritised it yet. I'll chat to our PM and see when we can fit it in.

[Belogix]

Any more progress with this? @ulyssessouza have you seen the update as per your request?

[RyanW19]

Anyone have an update on this? Nearly been a year and itching to use a feature in the stack/compose files!

[terrpan]

Any updates here? Would be nice to be able to use the new features with 3.8

[chris-crone]

AFAIK this has been superseded by #7217 which is now merged.

Thanks for the PR @sirlatrom! I'll close this.