Skip to content
This repository was archived by the owner on Feb 24, 2020. It is now read-only.

rkt: Implement distribution points#3101

Closed
sgotti wants to merge 1 commit intorkt:masterfrom
sgotti:distribution_uri_impl
Closed

rkt: Implement distribution points#3101
sgotti wants to merge 1 commit intorkt:masterfrom
sgotti:distribution_uri_impl

Conversation

@sgotti
Copy link
Contributor

@sgotti sgotti commented Aug 22, 2016

This is the implementation of the distribution concept proposed in #2953.

This patch implements the distribution point concept with the three initial
kind of distributions already used by rkt (appc, aci-archive, docker).

It just makes the smallest required changes to the fetchers logic to make them
work and pass the functional tests.

This is the base for future fetchers (a future patch will refactor the
fetcher logic to better fit the distribution concept) and store refactors.

// Returns a copy of the distribution URI
URI() *url.URL
// Returns the distribution type
Type() DistType
Copy link
Contributor

Choose a reason for hiding this comment

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

The distribution type is encoded in two places, as distribution.Docker, and DistTypeDocker. I am not convinced we need this type information in two places.

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 was thinking to just use type assertions/switches and remove DistType and Type() from the Distribution interface. Or do you have other suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

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

I was hoping that we could leverage polymorphic behavior by using interfaces and avoid type assertions/switches as much as possible. I am hesitant to use DistType switches in upper architectual layers (although I am aware this is hard).

Copy link
Contributor Author

@sgotti sgotti Aug 24, 2016

Choose a reason for hiding this comment

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

I am hesitant to use DistType switches in upper architectual layers (although I am aware this is hard).

I'd also like to avoid this if possible. Some thoughts:

  • Upper code needs a way to know the distribution type. e.g. for calling the right distribution handler. Possible solutions:
    • Keep the Type() DistType func from the Distribution interface as now.
    • Use an helper function DistType(d Distribution) (DistType, error) (removing the Type() DistType func from the Distribution interface)
  • To avoid type assertions I can remove/unexport all the additional (not covered by the Distribution interface) methods from the distributions (Appc.App() *discovery.App for Appc, ACIArchive.ArchiveURL() *url.URL for ACIArchive, Docker.DockerString() Docker.SimpleDockerString() string for Docker) and implement generic helpers methods like
AppDiscovery(d Distribution) (*discovery.App,error) // Will work only for Appc Distribution
TransportURL(d Distribution) (*url.URL, error) // Will work only for ACIArchive and perhaps we can use the same function for future distributions like oci-image-layout
DockerString(d Distribution) (string,error) // Will work only for Docker Distribution
SimpleDockerString(d Distribution) (string,error) // Will work only for Docker Distribution

Since they will have a Distribution interface as input (to avoid type assertions) they have to do validation since they'll work only for a specific distribution type (so they will also return an error) (and quite probably they'll do an internal type assertion).

This will avoid the need for the user to know the additional provided methods of a distribution type but just use some helper methods.

Thoughts? Better Ideas?

Copy link
Contributor

Choose a reason for hiding this comment

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

This is nice improvement 👍 One question regarding the "distribution handler": Couldn't this also be an interface type included in the returned struct from a potential Parse(...) ... method? Just fighting for more generalization ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One question regarding the "distribution handler": Couldn't this also be an interface type included in the returned struct from a potential Parse(...) ... method? Just fighting for more generalization ;-)

The distribution handlers, like the user friendly string and the use of distribution URIs as references in #3071 are on top of this. Every user could implement their own logic. Given this, I'd like that this could be shared be more projects since it could probably be of help also for k8s (@euank @yifan-gu) for handling multiple diatribution types (sometimes called, IMHO not correctly, image types).

@sgotti sgotti changed the title rkt: Implement distribution concept rkt: Implement distribution points Aug 25, 2016
@sgotti sgotti force-pushed the distribution_uri_impl branch from 369af1f to 8c5a3f2 Compare August 25, 2016 13:41
@sgotti
Copy link
Contributor Author

sgotti commented Aug 25, 2016

Updated the PR.

  • The Distribution interface has only two methods (URI() and Compare(Distribution))
  • Now every distribution will register itself. This avoids a type switch inside New(...) and Parse(...) and makes easy to add new distributions.
  • Removed all the custom distributions functions and added generic helper functions. This avoid doing type assertions at the cost of an increased number of error checks.

@s-urbaniak I tried to simplify as much as possible. An extreme simplification will be to just remove the Distribution interface and declare type Distribution *uri.URI. This will require, since comparison is a primary property of a distribution, that the URI string will be provided ready to be compared. But I'd prefer the current way since an interface forces the right behavior instead of relying on a simple godoc.

@s-urbaniak
Copy link
Contributor

@sgotti thanks, this looks much simpler than the initial version. Although it does not include the abstractions I was hoping for, it does LGTM, thanks!

}
fds2, err := FullDockerString(d2.ds)
if err != nil {
panic(err)
Copy link
Member

Choose a reason for hiding this comment

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

I think this panic (and the one above) shouldn't be here, and just return false instead.

@sgotti sgotti force-pushed the distribution_uri_impl branch 2 times, most recently from 6a2392f to a90b25e Compare September 20, 2016 08:57
This patch implements the distribution point concept with the three initial
kind of distributions already used by rkt (appc, aci-archive, docker).

It just makes the smallest required changes to the fetchers logic to make them
work and pass the functional tests.

This is the base for future fetchers (a future patch will refactor the
fetcher logic to better fit the distribution concept) and store refactors.
@sgotti sgotti force-pushed the distribution_uri_impl branch from a90b25e to 2d9de5f Compare September 20, 2016 11:16
@s-urbaniak s-urbaniak self-assigned this Nov 10, 2016
@s-urbaniak s-urbaniak added this to the v1.20.0 milestone Nov 10, 2016
@s-urbaniak
Copy link
Contributor

Closing in favor of #3369

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants