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

Perform an O(1) check to find layers in an image #101

Merged
merged 5 commits into from
Jul 13, 2018

Conversation

smarterclayton
Copy link
Contributor

@smarterclayton smarterclayton commented Jun 12, 2018

Using the new imagestream/layers API, avoid making O(N) image fetches in the case where we don't have a cached association for the reference.

API in openshift/origin#19969

@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 12, 2018
@openshift-ci-robot openshift-ci-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jun 12, 2018
@smarterclayton
Copy link
Contributor Author

@bparees


REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY="${REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY:-/tmp/registry}" \
REGISTRY_OPENSHIFT_SERVER_ADDR="${url}" \
dockerregistry images/dockerregistry/config.yml
Copy link
Contributor

Choose a reason for hiding this comment

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

i assume this expects a cluster to be running somewhere, how are the coordinates of the cluster being supplied to the registry?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

KUBECONFIG

Copy link
Contributor

Choose a reason for hiding this comment

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

add a usage comment at the top of the file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

context.GetLogger(ctx).Debugf("(*blobDescriptorService).Stat: could not stat layer link %s in repository %s: %v", dgst.String(), bs.repo.Named().Name(), err)

// we couldn't find the layer link
Copy link
Contributor

Choose a reason for hiding this comment

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

comment should elucidate the implications of not finding the layer link

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is just a refactor of the method, i'm happy to make better comments

firstImage = name
break
}
return logFound(&imageapiv1.Image{
Copy link
Contributor

@bparees bparees Jun 12, 2018

Choose a reason for hiding this comment

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

what if layers.Layers was empty?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that means the image stream has no layers

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah but we shouldn't returning found in that case, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if we don't have a layer we return on line 43 with nil, and the if block fails, and we return ErrBlobUnknown.

}
var firstImage string
for name := range layers.Layers {
firstImage = name
Copy link
Contributor

Choose a reason for hiding this comment

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

we don't actually need to find the specific image that contains the blob? any image in the imagestream will do?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

correct

Copy link
Contributor

Choose a reason for hiding this comment

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

If we have the list of blobs, we don't need the image object anymore, we should just return that list.

Layers(name string) (*v1.ImageStreamLayers, error)
}

// Bind applies the provided binding to the named pod in the current namespace (binding.Namespace is ignored).
Copy link
Contributor

Choose a reason for hiding this comment

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

godoc is wrong

@smarterclayton smarterclayton changed the title WIP - Perform an O(1) check to find layers in an image WIP - 3.11 - Perform an O(1) check to find layers in an image Jun 12, 2018
ObjectMeta: metav1.ObjectMeta{
Name: firstImage,
},
DockerImageLayers: copied,
Copy link
Contributor

Choose a reason for hiding this comment

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

The configuration blob for v2 scheme is missed here.

Copy link
Contributor

Choose a reason for hiding this comment

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

RememberLayersOfImage will report the error "image %s does not have metadata" for this image. We trying to reduce amount of logs.

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’m going to remove that message. This is purely a blob access check.

Copy link
Contributor

Choose a reason for hiding this comment

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

This error message means that we got incomplete image and we do not have all necessary data (we do not have the digest of config blob) and can't to cache them all. For the RememberLayersOfImage this message is truely error.

Your handmade image object is really incomplete and hacky.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Then I'll split this into RememberLayers and RememberLayersOfImage.

firstImage = name
break
}
return logFound(&imageapiv1.Image{
Copy link
Contributor

Choose a reason for hiding this comment

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

Regression. The requireManaged was ignored. It will break config.Pullthrough.Enabled flag.

https://github.com/openshift/image-registry/pull/101/files#diff-0c454c8033229f303d88c165f82eb0d9L82

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’m not sure pullthrough enabled false is something we should support. In 8 release we’ve never had a reason to trn it off. At this point, I’d probably prefer to drop the use case.

I don’t really consider the distinction between managed an unmanaged images important anymore. If a layer is available it should be served. The image it comes from is irrelevant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Specifically, for the case where we are attempting to find the layers, I think this method should be returning a set of layers that are considered valid (which is added to the cache).

Copy link
Contributor

Choose a reason for hiding this comment

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

OK. Please, open an issue to make pullthrough not optional to address this important change. Because right now this functionality can be turned off and removing this option will need to be written to the log as a warning in the case of config.Pullthrough.Enabled = false.

/cc @bparees @dmage

@smarterclayton
Copy link
Contributor Author

I still need to add the e2e test to try and access content. Will do that once we clear up the case.

Copy link
Contributor

@legionus legionus left a comment

Choose a reason for hiding this comment

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

I think it is not necessary to add new features, which from the start leads to hacks. I mean the creation of images that are not images. Such image do not have all information about blobs (image blobs != image layers).

This will lead to the fact that the last code can no longer process images identically. This will greatly complicate the work with images.

@@ -37,6 +38,27 @@ func (is *imageStream) HasBlob(ctx context.Context, dgst digest.Digest, requireM
return found
}

if layers, err := is.imageStreamGetter.layers(); err == nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need to fallback to the old code?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For 1 release we should tolerate the cluster not having /layers or the admin not configuring permissions. We can then remove the old code path in 3.12.

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 26, 2018
@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 8, 2018
@smarterclayton
Copy link
Contributor Author

Updated with the latest version of the api, all feedback added to the PR.

The biggest change is the signature to HasBlob - it now returns (bool, *ImageStreamLayers, *Image), and the caller uses the two objects if they are available as "things to add to the cache". When we remove the legacy path in 3.12/4.0 we can drop that segment and simplify the signature back down.

Unit tests added, the e2e test will be added to the origin PR.

@smarterclayton smarterclayton changed the title WIP - 3.11 - Perform an O(1) check to find layers in an image Perform an O(1) check to find layers in an image Jul 8, 2018
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 8, 2018
@smarterclayton
Copy link
Contributor Author

/retest

@bparees
Copy link
Contributor

bparees commented Jul 9, 2018

looks reasonable to me

@smarterclayton
Copy link
Contributor Author

/retest

@smarterclayton
Copy link
Contributor Author

Bumped dependencies in #113, which I will rebase on master after that merges.

Was accidentally dropped when moved over from image-registry
@openshift-ci-robot openshift-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jul 11, 2018
@smarterclayton
Copy link
Contributor Author

Updated on bumps, ready for final review.

Added one commit to switch us to building on go1.10 for travis.

Because this must work during a rolling update we fall back to the older
path if we get an error. A future release can drop support for the
fallback path (3.12+).
@bparees
Copy link
Contributor

bparees commented Jul 12, 2018

lgtm. Any final concerns @dmage or @legionus ?

@smarterclayton
Copy link
Contributor Author

No comments? I'm happy to do follow ups (I need to improve the e2e tests in origin for pulling images.

@bparees
Copy link
Contributor

bparees commented Jul 13, 2018

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 13, 2018
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees, smarterclayton

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [bparees,smarterclayton]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit d46b6b6 into openshift:master Jul 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants