docs/dev: introduce "Distribution Point" concept #2953
Conversation
|
/cc @dgonyeo (this is part of the store rework I mentioned) |
|
Can we please put the PR details inside a markdown doc? Even if not final, it will make discussion easier.
Bikeshed level: I think so. I also think schemes should be scoped (as they are rkt specific) and be made future-proof. Something like:
Where we basically reserve for ourself a single scheme ( |
eaf5338 to
30859d9
Compare
Done, I put the details in a not final doc in Documentation/devel/distribution.md
This seems good. Version will be the sub-scheme version right? (to be able to update its internal format without putting the version directly in the subscheme and changing the subscheme name). @s-urbaniak? thoughts on the URI (as names) direction and the suggested formats? |
Right (and yes).
The former (which in case can be expanded into the latter given a k=v array, but I prefer not going that route if there's no need to)
I would avoid complexity and just keep a |
Since my hope is that all this effort and others to decouple different layers will be shared between multiple tools (acbuild, new tools etc...) I won't make them too much rkt specific. If we want to go with an unique scheme I'll try to find a more generic name ("distribution" ?). |
So the owner of this would be some kind of
(I hope we are not starting to over-design here) |
It would be ideal to share this with acbuild at the very least. Is there a difference between distributions here and distribution handlers in #2964? If not, it sounded like distribution handlers are responsible for interacting with rkt's store, which means that if an external project wants to use these distribution handlers it would also have to use rkt's store logic.
I think distribution is fine. |
That's a good point.
One idea will be to define a (read-write) store interface with the required CAS and ref methods (WriteBlob, ReadBlob, ListBlobs, HasBlob, SetRef ...). I have to experiment a little bit more with the store refactor to see if this will work or if some image type differences (ACI, OCI image) will force us to use dedicated store functions per image type (some example can be handling ACI manifest cache to avoid extracting the manifest every time its needed from an image), |
1face78 to
3b689e2
Compare
|
Updated with the proposed changes:
|
f7fbb8b to
ed95894
Compare
ed95894 to
f3995bc
Compare
f3995bc to
650d2b4
Compare
|
As suggested, and to speed up things, I split the proposal (this PR) from the implementation (#3101). @s-urbaniak thanks for your comments on the implementation! Due to the split they got lost in #3101, can you please copy them there? |
| @@ -0,0 +1,147 @@ | |||
|
|
|||
| **NOTE:** I'm not sure if distribution is the best name for this concept or it should be called with other names like "image reference". So I'd like to hear your thoughts. | |||
There was a problem hiding this comment.
I guess we can settle on calling them "Distribution Points". Current name looks fine enough, we just need to disambiguate it from typical "Linux distro" usage.
There was a problem hiding this comment.
Distribution Points looks good. I was also thinking to just Distribution URIs.
A Distribution Point represents the method to fetch an image starting from an input string. Before this concept was introduced, rkt used the ImageType concept, the ImageType was mapped to the input image string format and internally covered multiple concepts like distribution, transport and image type (hidden since all are now appc ACIs). The distribution point concept will be used as the primary information in the different layers of rkt (fetching but also for references in a CAS/ref store). This patch introduces the distribution point concept. See Documentation/devel/distribution_point.md for a detailed description.
9919e08 to
818a1a3
Compare
|
@lucab Thanks for the review! I used the |
|
@lucab ping for final pass |
|
I think this doc needs quite a bit of re-wording and polishing, but we are more interested in its content and the concepts it contains. Let's land it now and implement this. We will need to re-touch this anyway to show how to use them in practice. LGTM. |
A Distribution Point represents the method to fetch an image starting from an
input string.
Before this concept was introduced, rkt used the ImageType concept, the
ImageType was mapped to the input image string format and internally
covered multiple concepts like distribution, transport and image type
(hidden since all are now appc ACIs).
The distribution point concept will be used as the primary information in the
different layers of rkt (fetching but also for references in a CAS/ref store).
This patch introduces the distribution point concept. See
Documentation/devel/distribution_point.md for a detailed description.