Implementation of the Manifest Service API refactor. #1268
Conversation
| if err != nil { | ||
| return nil, err | ||
| panic("digesting canonical") |
There was a problem hiding this comment.
This kind of thing is all the more reason to merge #1264 :)
d21d199 to
b3e2961
Compare
| if err := json.Unmarshal(raw, &sm); err != nil { | ||
| return nil, err | ||
| } | ||
| ms.Enumerate(ctx, make([]distribution.Manifest, 1), sm) |
There was a problem hiding this comment.
What's this Enumerate call for?
|
This is a solid crack at the task. Most of the commentary above is clarifications. |
|
|
||
| func (ms *manifests) Exists(ctx context.Context, dgst digest.Digest) (bool, error) { | ||
| // Call by Tag endpoint since the API uses the same | ||
| // URL endpoint for tags and digests. |
b3e2961 to
71b2c35
Compare
| return nil, err | ||
| } | ||
| // Target returns the target of this signed manifest | ||
| func (sm SignedManifest) Target() distribution.Descriptor { |
There was a problem hiding this comment.
Adding back a comment that GitHub thinks is against an outdated diff:
This function doesn't really make sense to me. It's returning a descriptor for the manifest itself as the target. It seems a bit recursive, and inconsistent with what Target will do for a schema2 manifest.
There isn't really a sensible implementation of Target for schema1. In the original proposal thread, I suggested that Target should not be part of the Manifest interface, because not all manifest types would be able to implement it. Looking over my preliminary schema2 code, all uses of Target do a type assertion to *schema2.DeserializedManifest before calling it. How about just removing Target from the interface and removing this implementation?
Adding to that: Target doesn't make sense for manifest lists either. It's very schema2-specific.
There was a problem hiding this comment.
Given that it's valid for a minority of manifests, I am OK with removing it.
ff33ec2 to
485f49d
Compare
|
LGTM Please squash commits though. |
Add a generic Manifest interface to represent manifests in the registry and remove references to schema specific manifests. Add a ManifestBuilder to construct Manifest objects. Concrete manifest builders will exist for each manifest type and implementations will contain manifest specific data used to build a manifest. Remove Signatures() from Repository interface. Signatures are relevant only to schema1 manifests. Move access to the signature store inside the schema1 manifestStore. Add some API tests to verify signature roundtripping. schema1 ------- Change the way data is stored in schema1.Manifest to enable Payload() to be used to return complete Manifest JSON from the HTTP handler without knowledge of the schema1 protocol. tags ---- Move tag functionality to a seperate TagService and update ManifestService to use the new interfaces. Implement a driver based tagService to be backward compatible with the current tag service. Add a proxyTagService to enable the registry to get a digest for remote manifests from a tag. manifest store -------------- Remove revision store and move all signing functionality into the signed manifeststore. manifest registration --------------------- Add a mechanism to register manifest media types and to allow different manifest types to be Unmarshalled correctly. client ------ Add ManifestServiceOptions to client functions to allow tags to be passed into Put and Get for building correct registry URLs. Change functional arguments to be an interface type to allow passing data without mutating shared state. Signed-off-by: Richard Scothern <richard.scothern@gmail.com> Signed-off-by: Richard Scothern <richard.scothern@docker.com>
ab361bf to
cb6f002
Compare
|
LGTM |
Implementation of the Manifest Service API refactor.
…factor-impl Implementation of the Manifest Service API refactor.
…factor-impl Implementation of the Manifest Service API refactor.
Add a generic Manifest interface to represent manifests in the registry and
remove references to schema specific manifests.
Add a ManifestBuilder to construct Manifest objects. Concrete manifest builders
will exist for each manifest type and implementations will contain manifest
specific data used to build a manifest.
schema1
Change the way data is stored in schema1.Manifest to enable Payload() to be used
to return complete Manifest JSON from the HTTP handler without knowledge of the
schema1 protocol.
tags
Move tag functionality to a seperate TagService and update ManifestService
to use the new interfaces. Implement a driver based tagService to be backward
compatible with the current tag service.
Add a proxyTagService to enable the registry to get a digest for remote manifests
from a tag.
manifest store
Remove revision store and move all signing functionality into the signed manifeststore.
manifest registration
Add a mechanism to register manifest media types and to allow different manifest
types to be Unmarshalled correctly.
client
Add ManifestServiceOptions to client functions to allow tags to be passed into Put and
Get for building correct registry URLs. Change functional arguments to be an interface type
to allow passing data without mutating shared state.
Signed-off-by: Richard Scothern richard.scothern@docker.com