Manifest interface refactor #1105
Conversation
…egistry. Add a generic Manifest interface to represent manifests in the registry. 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. Move tag functionality to a seperate TagService and update ManifestService to use the new interfaces. Signature functionality will be retained for backwards compatibility, but isn't represented in this change. All signature related code for Schema1 V2 manifest will exists in a specific SignedManifestStore implementation (not shown). Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
distribution APIs. Remove Maniest.Tags() Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
| // Constituents returns a list of objects which make up this manifest. | ||
| // The dependencies are strictly ordered from base to head. A constituent | ||
| // is anything which can be represented by a distribution.Descriptor | ||
| Constituents() []Descriptor |
There was a problem hiding this comment.
Why Constituents and not Dependencies? /mostly curious
There was a problem hiding this comment.
I wasn't sure Dependencies really captured the right meaning as it implied to me something external to this object. Constituents is more accurate, but I'm not thrilled with the word (I also considered objects and references). I was hoping for a minor bikeshed over this one: @dmcgowan @aaronlehmann
There was a problem hiding this comment.
Sweet! 🚲 🏡 initiated! <bikeshedding music plays, mostly death metal cause its going to be brutal!> 🎸 🚲 🏡 🎸
I like References. I think that captures the intent.
There was a problem hiding this comment.
I am also not a fan of the name, but if it remains unchanged this will be the last I say about it 😄
There was a problem hiding this comment.
Yeah, I don't think Dependencies is the right term.
There was a problem hiding this comment.
OK. 2 votes for References. Any more takers?
|
LGTM! |
|
LGTM |
| type Manifest interface { | ||
| // Target returns a descriptor for the configuration of this manifest. This | ||
| // may return a nil descriptor if none exists for this manifest. | ||
| Target() Descriptor |
There was a problem hiding this comment.
Will this return nil for old-style manifests? If so, shouldn't it be part of a more specific interface?
There was a problem hiding this comment.
I did consider this, but didn't want to fragment the interfa 8000 ce.
Perhaps more explicit return types (e.g. returning ErrNotSupported) would work here.
There was a problem hiding this comment.
Hmm... I don't want to make a big deal out of it, but it doesn't seem right to me to have a method in an interface that's specific to one of the implementations. What do others think?
There was a problem hiding this comment.
The target should just be the manifest itself.
Add method for getting tags for a digest. Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
| ) | ||
|
|
||
| // TagService provides access to information about tagged objects. | ||
| type TagService interface { |
There was a problem hiding this comment.
Is this scoped to a global namespace or particular repository or both?
There was a problem hiding this comment.
Currently a repository returns an instance to its tag service. In the future there will be a tag service. docker notary for instance.
|
Closing. Included in #1268 |
Carry @stevvooe's branch to refactor Manifest interfaces within the registry.
Add a generic Manifest interface to represent manifests in the registry.
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.
Move tag functionality to a seperate TagService and update ManifestService
to use the new interfaces.
Signature functionality will be retained for backwards compatibility, but isn't
represented in this change. All signature related code for Schema1 V2 manifest
will exists in a specific SignedManifestStore implementation (not shown).
Signed-off-by: Richard Scothern richard.scothern@gmail.com