Drop experimental tag for manifest commands

[dims]

Signed-off-by: Davanum Srinivas [email protected]

- What I did

Some of us working on Kubernetes have been using the docker manifest
experimental commands to build images for some time now. The last
problem we had was fixed by one of the commits a few months ago:
69e1743

Could we please promote these commands from experimental to GA

- How I did it

Delete the annotation for the command that sets it to experimental

- How to verify it

Just run docker manifest commands without the config.json or environment flag for experimental mode

- Description for the changelog

docker manifest commands are now no longer considered experimental and available for general use

- A picture of a cute animal (not mandatory but encouraged)

[GordonTheTurtle]

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "promote-docker-manifest-commands-and-drop-experimental-tag" [email protected]:dims/cli.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

[dims]

cc @estesp

[clnperez]

I'm for it! ;)

This is also a headache for our internal teams who have to add bits to their Travis files to add the experimental json info after installing docker.

[ijc]

In my (rather light) use of it so far it seems rather rough around the edges still. For example shouldn't issues such as #910 and #1358 (and I'm sure there must be others) be fixed before this becomes non-experimental?

[dims]

@ijc

• for 'docker trust sign' does not work with manifest lists #910 - this PR does not ask to promote the trust sign, just the manifest create/annotate/push/... So we can leave the trust one as experimental until 'docker trust sign' does not work with manifest lists #910 gets fixed.
• for "docker manifest inspect --insecure" doesn't work #1358 - i believe it is the same that we faced in docker manifest create fails due to permission denied on /etc/docker/certs.d/gcr.io for-linux#396 and i have a patch up in Ignore permission error when accessing certs.d directory moby/moby#37619

[dims]

@thaJeztah @estesp @ijc as part of the kubernetes ci/build process, we have a few months under our belt now. So can we please promote manifest now?

Also moby/moby#37619 is now fixed as well so situation is even better than before.

[olljanat]

@vdemeester PTAL

[dims]

@thaJeztah Can we please get this in?

[grooverdan]

I'm also been asked by sysadmins not to use docker manifest in automated build processes because of its experimental status. My frequent use of docker manifest over the last year has been stable and useful. The code history shows minor bug fixes but no significant churn and no outstanding bugs, and to me that seem to make it an ideal candidate fro removing the experimental tag. Related issues mentioned above aren't part of docker manifest as @dims mentioned 6 months ago.

Please merge this. I'd really appreciate it.

[vdemeester]

LGTM 👼
/cc @thaJeztah @silvin-lubecki @andrewhsu

[dims]

w00t!!! thanks @vdemeester @grooverdan

[cpuguy83]

ping @tiborvass @estesp WDYT?

[estesp]

I think this is totally reasonable and agree that the functionality seems stable at this point. However, I've never been a docker/cli maintainer, so was assuming one of them would take @vdemeester's ping and do a review.

[tiborvass]

cc @tonistiigi who had concerns about the design.
Question: now that we have CLI plugins, why not make it a CLI plugin instead? Could have faster iterations too.

[docwhat]

Would the cli plugins be distributed in the docker-ce apt & yum repositories?

[tonistiigi]

Next version of CLI will come with CLI plugins support #1564 for allowing docker cli to be extended with functionality that doesn't directly expose the Engine capabilities. I think that's the right place where the manifest command should go and it doesn't require experimental after that.

The main reasons for that are that manifest command does not use or integrate with anything from the Engine/remote API. It's a completely standalone tool where the CLI directly communicates with a registry. For example when you do docker build or pull you can't even use these images with manifest command because they are local.

Buildkit already supports directly building manifest lists, including the functionality of stitching already available images into the manifest list. That is currently only available in BuildKit-standalone and not in Docker integration (DOCKER_BUILDKIT=1), but it will change in the future. With the containerd image integration in engine moby/moby#38043 docker images will start to manage manifest lists locally, and push/save/load will be able to work directly with manifest lists. I'm not saying that current manifest command would be completely useless then, but there will be alternatives that are much more tightly integrated.

As @tiborvass mentioned this would also allow faster iterations for the functionality and maybe allow exposing more similar useful functionality.

If people agree we can create a repo under the docker org to make sure manifest cli plugin will be part of the official plugins.

For distribution of plugins, I don't know for sure, but I assume they will be distributed on the same channels where you can get the CLI (packages+static builds).

[docwhat]

If people agree we can create a repo under the docker org to make sure manifest cli plugin will be part of the official plugins.

Yes, please. I don't mind it being moved into a plugin as long as I can continue to use Chef to point at the docker repositories to get all the packages I need.

[docwhat]

Why was this closed? Was something merged that addresses it?

[dims]

@docwhat it did not look like there was any support for merging this patch as-is as folks were talking about moving this to a CLI plugin. If one of the maintainers wants to merge, i'll be happy to reopen the PR. (also, if anyone wants to pick up this patch into their own PR, that's fine with me as well)

[tonistiigi]

If people agree we can create a repo

Facing some internal issues for creating a dedicated repo for this at the moment. I am trying to integrate support for this use case in the builder cli plugin currently in development. https://github.com/tonistiigi/buildx/pull/25 Maybe this could be used as an alternative. The plan is to include it with docker installation but I can’t guarantee a timeline atm.

I’ll leave it to other maintainers to decide. I know it is frustrating to wait but it is also bad to add backward compatibility guarantees to something that may not fit the overall design direction and would probably increase confusion in the future. As mentioned before moby/moby#38043 will add native manifest list support in the daemon and a lot of user flows will change because of it.

[pjh]

It looks like this PR was rejected because of forthcoming CLI plugin support last year. I followed some of the links and it looks like #2534 deprecated support for the CLI Plugins API last month though. That PR did not link to any discussion or context or other issues explaining why it was deprecated.

Does anyone know the fate of the "experimental" docker manifest commands now?

[olljanat]

@dims can you reopen this one so we can continue discussing if it can be merged now when concept of CLI plugins was rejected?

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (master@ce4a9f8). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1355   +/-   ##
=========================================
  Coverage          ?   54.63%           
=========================================
  Files             ?      293           
  Lines             ?    19369           
  Branches          ?        0           
=========================================
  Hits              ?    10582           
  Misses            ?     8126           
  Partials          ?      661           

[dims]

@olljanat Done!

[justaugustus]

IT'S HAPPENING! 🎉

[thaJeztah]

We had some internal discussion on this, and I opened alternative pull requests in #2774 (and related: #2773)

[dims]

@thaJeztah those pesky "Enterprise users"!!! :) thanks! i'll close this now.

[thaJeztah]

Haha, yeah, well, it made sense for some things perhaps. Overall, documentation should be good enough.

FWIW; we'd still like to improve the UX for handling the manifest commands, which was the main reason for keeping it in experimental; such changes could potentially break scripts that rely on the UX / output. That said, not having to configure the CLI to be able to use these features definitely makes things easier to use, and is better to collect feedback on these

[olljanat]

@thaJeztah hmm, but is Windows Server version still considered as enterprise version? (even when support is actually much worse than on community edition on Linux).

You can see my old and still valid use case (which why especially would like this to be enabled by default on Windows Server) on https://github.com/olljanat/multi-win-version-aspnet

[thaJeztah]

@olljanat Docker currently doesn't build packages for Windows (besides Docker Desktop); if we would build packages again, then windows packages would have the same configuration (i.e., no special "enterprise" variant for Windows)

[olljanat]

@thaJeztah yep, that why manifest commands shouldn't be experimental feature IMO.

/cc @StefanScherer you probably have seen this dilemma with Windows containers.

[clnperez]

Very nice! 😀