rkt/image: check that discovery labels match manifest labels #2311

sgotti · 2016-03-21T17:33:21Z

The spec in the discovery part says: "Implementations MUST ensure
that the initial name and labels used for discovery matches the name and
labels in the Image Manifest."

Actually rkt just checks that the names matches but ignore the labels.

This patch also check the labels. Like the other validation parts the
check is executed only if the user doesn't pass --insecure-options=image

A functional test is added.

With this patch users calling rkt fetch example.com/aci:latest but
receiving an aci with a different version (like v2.0) will receive a
validation error.

This will fix a part of #2305 (since it will error on users running rkt fetch example.com/aci:latest to get the latest image if they don't have image verification disabled)

jonboulle · 2016-03-31T11:13:45Z

Can we land this in such a way that won't break today's :latest experience?

iaguis · 2016-03-31T12:10:31Z

This doesn't break the "implicit latest" when you don't specify any labels:

$ rkt fetch kinvolk.io/aci/busybox
image: searching for app image kinvolk.io/aci/busybox
image: remote fetching from URL "https://kinvolk.io/aci/busybox/busybox-latest-linux-amd64.aci"
image: keys already exist for prefix "kinvolk.io/aci/busybox", not fetching again
image: downloading signature from https://kinvolk.io/aci/busybox/busybox-latest-linux-amd64.aci.asc
Downloading signature: [=======================================] 473 B/473 B
Downloading ACI: [=============================================] 640 KB/640 KB
image: signature verified:
  Iago López Galeiras <[email protected]>
sha512-140375b2a2bd836559a7c978f36762b7
$ rkt i c --pretty-print kinvolk.io/aci/busybox | grep version -A 1
            "name": "version",
            "value": "1.24"

However, using the label:

$ rkt fetch kinvolk.io/aci/busybox:latest
image: searching for app image kinvolk.io/aci/busybox
image: remote fetching from URL "https://kinvolk.io/aci/busybox/busybox-latest-linux-amd64.aci"
image: keys already exist for prefix "kinvolk.io/aci/busybox", not fetching again
image: downloading signature from https://kinvolk.io/aci/busybox/busybox-latest-linux-amd64.aci.asc
Downloading signature: [=======================================] 473 B/473 B
Downloading ACI: [=============================================] 640 KB/640 KB
fetch: requested value for label "version": "latest" differs from fetched aci label value: "1.24"

jonboulle · 2016-03-31T12:14:28Z

@iaguis and your second example works today right?

sgotti · 2016-03-31T12:16:09Z

We can also try to not break today's :latest experience on discovery (for example ignoring the version label comparison when the required version is "latest")

But this won't fix the problem that, a future rkt fetch/run, will go to the store and won't find an image with label version==latest (so fetching it again, additionally: is this "magic" behavior used by some users instead of using rkt fetch --no-store?). See #2276.

I think that the current problem is the lack of explanation on what implies fetching/running by image name and labels (for example users accustomed with docker thinking that :latest is a tag). All of this is in turn probably caused by lack of explaining on how to do "latest" discovery in appc/spec (with additional mess caused by "hidden" latest magic behavior).

For this I opened some appc/spec PRs with two different ways of doing this:

Pure meta tags based "latest" pattern: discovery: match template only if satisfies all required labels appc/spec#580 Discovery do not set default version appc/spec#581. But this sounds like hackish primarily because I think that multiple discovery endpoints should be used for "mirrors" and not for obtaining different image files (an will cause other breakage). Additionally this way to do "latest" pattern should rely on some symlink/redirect implemented on the server...
Image tags ([RFC] spec: add image tags appc/spec#584), this sound better, and covers multiple kinds of features and issues.

So I think we should primarily clarify how to do "latest" pattern in appc/spec and accept possible breakage since making it compatible with current experience (which IMHO is not correct) will subsequently cause other incompatibilities.

I think this deserves a broader discussion. Perhaps opening too much related issues has caused some confusion (sorry for this), so let me know if I should try another path (like providing a document explaining the current issues or something else).

iaguis · 2016-03-31T12:16:59Z

@iaguis and your second example works today right?

Yes.

sgotti · 2016-03-31T12:20:45Z

This doesn't break the "implicit latest" when you don't specify any labels:

Yeah! This is the right way of doing current implicit latest. The problem is that, as asked by @jonboulle, some user do rkt fetch kinvolk.io/aci/busybox:latest and this patch will (correctly) break it.

jonboulle · 2016-04-04T14:01:34Z

I think I agree with the summaries in #2311 (comment) and #2311 (comment), that the likelihood of the :latest case being used today is vanishingly small (except for Kinvolkians). @sgotti how would you feel about doing a straw poll on the rkt-dev mailling list before we ship this?

jonboulle · 2016-04-04T14:01:48Z

also cc @alban for review since he's been quiet

sgotti · 2016-04-05T14:36:31Z

@sgotti how would you feel about doing a straw poll on the rkt-dev mailling list before we ship this?

I'll happily do it. Will a recap of the current "problems", the possible solutions and the related appc/spec and rkt PRs will be too much?

alban · 2016-04-06T12:12:53Z

rkt/image/validator.go

+// the ones in the image manifest.
+func (v *validator) ValidateLabels(labels map[types.ACIdentifier]string) error {
+	for n, rv := range labels {
+		if av, ok := v.manifest.GetLabel(n.String()); ok {


Shouldn't it also return an error if ok == false?

Doh! Right! Need to improve the tests to also match these cases.

alban · 2016-04-06T12:31:20Z

Since the fetch works without specifying ":latest" on the command line, the change is ok for me.

jonboulle · 2016-04-06T12:31:23Z

I'll happily do it. Will a recap of the current "problems", the possible solutions and the related appc/spec and rkt PRs will be too much?

Probably too much for some, but I'll never argue against thoroughness ;-) - as long as there's a tldr section

alban · 2016-04-07T14:50:57Z

@sgotti the code LGTM. Do you mind adding something in CHANGELOG.md, in the vUNRELEASED section? That would help @s-urbaniak when doing the next release (#2378) :)

sgotti · 2016-04-07T16:00:28Z

@alban Sure. Will do.

sgotti · 2016-04-08T11:56:57Z

@sgotti the code LGTM. Do you mind adding something in CHANGELOG.md, in the vUNRELEASED section? That would help @s-urbaniak when doing the next release (#2378) :)

Tried to add something understandable in the CHANGELOG.md (since the latest pattern can be confusing). Please let me know how it can be improved.

iaguis · 2016-04-11T13:55:22Z

CHANGELOG.md


+#### New features and UX changes
+
+- Ensure that the initial name and labels used for discovery matches the name and labels in the Image Manifest as specified in the appc spec ([#2311](https://github.com/coreos/rkt/pull/2311)). Now users calling `rkt prepare/run/fetch example.com/aci:latest` but receiving an aci with a different version (like v2.0) will receive a validation error. With the current rkt "latest" pattern, users that want to use the "latest" image should use `rkt prepare/run/fetch example.com/aci` or if they want to bypass a locally cached image in the store and fetch an updated image (if the ACI's image discovery provides it) should use `rkt --no-store prepare/run/fetch example.com/aci`.


s/matches/match/

The last sentence is a bit confusing, also, --no-store needs to go after prepare/run/fetch. How about:

Users wanting the latest image should use rkt prepare/run/fetch example.com/aci without any labels. If the discovery server supports the "latest" pattern, the user can bypass a locally cached image in the store and fetch an updated image using rkt prepare/run/fetch --no-store example.com/aci option.

I like it. Will update with it.

After that, LGTM

Done! Thanks.

The spec in the discovery part says: "Implementations MUST ensure that the initial name and labels used for discovery matches the name and labels in the Image Manifest." Actually rkt just checks that the names matches but ignore the labels. This patch also check the labels. Like the other validation parts the check is executed only if the user doesn't pass `--insecure-options=image` A functional test is added. With this patch users calling `rkt fetch example.com/aci:latest` but receiving an aci with a different version (like v2.0) will receive a validation error.

sgotti mentioned this pull request Mar 23, 2016

[RFC] Define in the spec (or remove from code) that discovery will set version to "latest" if no version is requested appc/spec#575

Open

jonboulle added the needs/review label Mar 24, 2016

jonboulle added this to the v1.3.0 milestone Mar 24, 2016

jonboulle added the component/stage0 label Mar 24, 2016

alban modified the milestones: v1.4.0, v1.3.0 Mar 31, 2016

alban reviewed Apr 6, 2016
View reviewed changes

sgotti force-pushed the rkt_images_validate_discovery_labels_with_manifest branch from ea955e0 to c6c3de0 Compare April 6, 2016 13:23

sgotti force-pushed the rkt_images_validate_discovery_labels_with_manifest branch from c6c3de0 to addc99f Compare April 8, 2016 11:53

sgotti force-pushed the rkt_images_validate_discovery_labels_with_manifest branch from addc99f to 6529268 Compare April 8, 2016 12:55

iaguis reviewed Apr 11, 2016
View reviewed changes

sgotti force-pushed the rkt_images_validate_discovery_labels_with_manifest branch from 6529268 to 15b33b1 Compare April 11, 2016 16:56

iaguis added the reviewed/lgtm label Apr 11, 2016

alban merged commit 6a79129 into rkt:master Apr 12, 2016

alban removed the needs/review label Apr 12, 2016


		#### New features and UX changes

		- Ensure that the initial name and labels used for discovery matches the name and labels in the Image Manifest as specified in the appc spec ([#2311](https://github.com/coreos/rkt/pull/2311)). Now users calling `rkt prepare/run/fetch example.com/aci:latest` but receiving an aci with a different version (like v2.0) will receive a validation error. With the current rkt "latest" pattern, users that want to use the "latest" image should use `rkt prepare/run/fetch example.com/aci` or if they want to bypass a locally cached image in the store and fetch an updated image (if the ACI's image discovery provides it) should use `rkt --no-store prepare/run/fetch example.com/aci`.

Uh oh!

rkt/image: check that discovery labels match manifest labels #2311

rkt/image: check that discovery labels match manifest labels #2311

Uh oh!

Conversation

sgotti commented Mar 21, 2016

Uh oh!

jonboulle commented Mar 31, 2016

Uh oh!

iaguis commented Mar 31, 2016

Uh oh!

jonboulle commented Mar 31, 2016

Uh oh!

sgotti commented Mar 31, 2016

Uh oh!

iaguis commented Mar 31, 2016

Uh oh!

sgotti commented Mar 31, 2016

Uh oh!

jonboulle commented Apr 4, 2016

Uh oh!

jonboulle commented Apr 4, 2016

Uh oh!

sgotti commented Apr 5, 2016

Uh oh!

alban Apr 6, 2016

Choose a reason for hiding this comment

Uh oh!

sgotti Apr 6, 2016

Choose a reason for hiding this comment

Uh oh!

alban Apr 7, 2016

Choose a reason for hiding this comment

Uh oh!

alban commented Apr 6, 2016

Uh oh!

jonboulle commented Apr 6, 2016

Uh oh!

alban commented Apr 7, 2016

Uh oh!

sgotti commented Apr 7, 2016

Uh oh!

sgotti commented Apr 8, 2016

Uh oh!

iaguis Apr 11, 2016

Choose a reason for hiding this comment

Uh oh!

sgotti Apr 11, 2016

Choose a reason for hiding this comment

Uh oh!

iaguis Apr 11, 2016

Choose a reason for hiding this comment

Uh oh!

sgotti Apr 11, 2016

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants