Skip to content
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

Keep but deprecate registry v2 schema1 logic and revert to libtrust-key-based engine ID #39365

Merged
merged 7 commits into from Jun 18, 2019

Conversation

tiborvass
Copy link
Contributor

@tiborvass tiborvass commented Jun 15, 2019

Partially reverts #37874

This partially reverts 98fc091.

Because registry v2 schema1 was not officially deprecated and
registries are still relying on it, this patch puts its logic back.

However, registry v1 relics are not added back since v1 logic has been
removed a while ago.

This also fixes an engine upgrade issue in a swarm cluster. It was relying
on the Engine ID to be the same upon upgrade, but the mentioned commit
modified the logic to use UUID and from a different file.

Since the libtrust key is always needed to support v2 schema1 pushes,
that the old engine ID is based on the libtrust key, and that the engine ID
needs to be conserved across upgrades, adding a UUID-based engine ID logic
seems to add more complexity than it solves the problems.

For that reason, this patch also reverts the engine ID changes.


This reverts commit 13b7d11.


Added a test to guard the daemon ID when upgrading.


This also adds a deprecation message to the user as well as in the logs.

logrus.Warnf("failed to upload schema2 manifest: %v - falling back to schema1", err)

logrus.Warnf("[DEPRECATION NOTICE] schema1 support will be removed in an upcoming release. Please contact admins of the %s registry NOW to avoid future disruption. Waiting 13 annoying seconds...", reference.Domain(ref))
time.Sleep(13 * time.Second)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be debated

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could randomize it?

If this needs more discussion, might be good to move it to a separate PR to unblock this one

@tiborvass tiborvass requested a review from tianon as a code owner June 15, 2019 07:12
@@ -14,4 +14,4 @@ export SCRIPTDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
. ${SCRIPTDIR}/toml
. ${SCRIPTDIR}/changelog-well-formed
. ${SCRIPTDIR}/changelog-date-descending
. ${SCRIPTDIR}/deprecate-integration-cli
#. ${SCRIPTDIR}/deprecate-integration-cli
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess this was to make CI pass?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

daemon/daemon.go Outdated
trustKey, err := libtrust.LoadKeyFile(config.TrustKeyPath)
switch {
case err == nil:
d.ID = trustKey.PublicKey().KeyID()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we write the ID to the new file in this case? That way we're able to preserve the ID once we really remove this logic.

FWIW, the format of the ID is not formalized (the new code uses an UUID for convenience), so storing the old ID format in the new location should not be a problem

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thaJeztah @justincormack the only problem I see here is that we would put a non-UUID into a file called engine_uuid. Should we rename the file to engine_id ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me; it's used to store an ID (and we describe it in the API that the format is not specified)

logrus.Warnf("failed to upload schema2 manifest: %v - falling back to schema1", err)

logrus.Warnf("[DEPRECATION NOTICE] schema1 support will be removed in an upcoming release. Please contact admins of the %s registry NOW to avoid future disruption. Waiting 13 annoying seconds...", reference.Domain(ref))
time.Sleep(13 * time.Second)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could randomize it?

If this needs more discussion, might be good to move it to a separate PR to unblock this one

@tiborvass
Copy link
Contributor Author

@thaJeztah @justincormack since this PR reverts v2 schema1 removal, and that libtrust key is needed to push with v2 schema1, I'm afraid we need to revert the engine ID change altogether. Migrating from libtrust key to engine UUID would mean removing the libtrust key, and thus breaking users who rely on pushing v2 schema1. So we will only be able to remove the libtrust key when we decide to remove support for pushing v2 schema1. But now that libtrust key stays, it makes little sense to introduce another engine ID.

@codecov
Copy link

codecov bot commented Jun 17, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@882e26a). Click here to learn what that means.
The diff coverage is 29.68%.

@@            Coverage Diff            @@
##             master   #39365   +/-   ##
=========================================
  Coverage          ?   37.35%           
=========================================
  Files             ?      610           
  Lines             ?    45235           
  Branches          ?        0           
=========================================
  Hits              ?    16897           
  Misses            ?    26046           
  Partials          ?     2292

@tiborvass tiborvass force-pushed the deprecate-v2-schema1 branch 2 times, most recently from 2afb14b to 3cb4c1f Compare June 17, 2019 21:54
@tiborvass tiborvass changed the title Keep but deprecate registry v2 schema1 logic and read old engine ID from disk Keep but deprecate registry v2 schema1 logic and revert to libtrust-key-based engine ID Jun 17, 2019
@tiborvass
Copy link
Contributor Author

@thaJeztah @tonistiigi @justincormack PTAL I updated the code, the title, and the description based on the discussions. Removed the annoying sleep, will PR it separately.

@tiborvass tiborvass force-pushed the deprecate-v2-schema1 branch 3 times, most recently from fa1920c to f18350d Compare June 17, 2019 23:21
This reverts commit 13b7d11.

Signed-off-by: Tibor Vass <tibor@docker.com>
Tibor Vass added 2 commits June 18, 2019 00:36
Signed-off-by: Tibor Vass <tibor@docker.com>
This reverts commit 98fc091 in order to
keep registry v2 schema1 handling and libtrust-key-based engine ID.

Because registry v2 schema1 was not officially deprecated and
registries are still relying on it, this patch puts its logic back.

However, registry v1 relics are not added back since v1 logic has been
removed a while ago.

This also fixes an engine upgrade issue in a swarm cluster. It was relying
on the Engine ID to be the same upon upgrade, but the mentioned commit
modified the logic to use UUID and from a different file.

Since the libtrust key is always needed to support v2 schema1 pushes,
that the old engine ID is based on the libtrust key, and that the engine ID
needs to be conserved across upgrades, adding a UUID-based engine ID logic
seems to add more complexity than it solves the problems.

Hence reverting the engine ID changes as well.

Signed-off-by: Tibor Vass <tibor@docker.com>
@tiborvass tiborvass force-pushed the deprecate-v2-schema1 branch 3 times, most recently from 65f8392 to ecc8c8a Compare June 18, 2019 01:38
Tibor Vass added 4 commits June 18, 2019 01:40
Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Tibor Vass <tibor@docker.com>
This will add a warning log in the daemon, and will send the message
to be displayed by the CLI.

Signed-off-by: Tibor Vass <tibor@docker.com>
…revert

Signed-off-by: Tibor Vass <tibor@docker.com>
@tiborvass
Copy link
Contributor Author

I updated the code by actually reverting the original commit 98fc091 and added a commit that is the change that it should have been. This way it is easier to compare with 98fc091.

Also made a change to send the deprecation message to the client in addition to logging a warning to the daemon.

@@ -14,6 +14,7 @@ import (
"github.com/docker/docker/layer"
dockerreference "github.com/docker/docker/reference"
"github.com/docker/docker/registry"
"github.com/docker/libtrust"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW; had a chat with @dmcgowan, and there's a desire to get rid of this dependency; not sure if it's worth doing so as part of this PR (if we plan to remove it in the next release); his suggestion was to copy the parts we use into this repository (somewhere in pkg or internal perhaps?), so that we can remove the dependency

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thaJeztah Sure I can do that in a followup, don't want to add more changes to this PR which is already big.

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :(

@andrewhsu
Copy link
Member

SGTM

As much as I would prefer quay.io to support v2 schema2 pushes, at this point it fails to handle it. I just tried and daemon says:

Jun 18 17:58:29 ip-172-31-27-101 dockerd[1129]: time="2019-06-18T17:58:29.365129917Z" level=warning msg="failed to upload schema2 manifest: manifest invalid: manifest invalid"

@tiborvass
Copy link
Contributor Author

Thanks for the reviews.

@dmcgowan
Copy link
Member

dmcgowan commented Aug 8, 2019

This message should not have been added on pull, that can be unnecessarily confusing for users as there is nothing that must be done now related to pull and just causes noise. If a user is pushing to a registry which still only supports v1, then they do need to contact their registry administrator to upgrade. distribution/distribution#2976

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants