-
Notifications
You must be signed in to change notification settings - Fork 643
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
Misleading language in image-layout.md #173
Comments
I believe we need to split the |
On Thu, Jul 21, 2016 at 06:44:19AM -0700, Antonio Murdaca wrote:
Colons are not portable, and we map them to hyphens 1. If folks
This is just about the blob filename. Splitting it into its own
This is correct.
I'm fine adding different app examples here, although I'd recommend |
it's still misleading - what does that actually mean? what are we talking about? blobs naming? who does the conversion? is it really needed to say that? can't we just say blobs are named Not sure about the colon story and base64 - I'd love maintainers to chime in |
On Thu, Jul 21, 2016 at 08:34:36AM -0700, Antonio Murdaca wrote:
The CAS consumer says “get me ‘sha256:5b…’”, and the CAS engine says
You could do that too. I don't think it really matters.
Who cares where sha256:5b… comes from? Both sentences are just “If Consumers will know what sha256:5b… should be from the context of |
What's your saying is ok with with as I understand most of the concept and stuff you've highlighted - still I think that's not really clear in those sentences |
On Thu, Jul 21, 2016 at 09:28:49AM -0700, Antonio Murdaca wrote:
I expect PRs are welcome ;). |
Colons should not be allowed. The example refs are completely invalid. The following:
Should be:
Otherwise, we completely break windows compatibility, as colons are used for alternate data streams. |
So there's no way to have multiple images (images as in Ubuntu, Alpine, Debian, Fedora) in a single image layout?! |
On Thu, Jul 21, 2016 at 03:44:51PM -0700, Stephen Day wrote:
This particular bit (or at least, one solution to it) has been spun |
Rather extreme conclusion and tone. Maybe try taking a deep breath before replying? 🐹 The The path name of a ref must be compatible with as many filesystem and archive formats as possible. Let's look at alternative example to better understand the future role of refs (not a proposal):
This part of the specification still needs to be worked out carefully. There are several considerations:
|
On Thu, Jul 21, 2016 at 04:38:55PM -0700, Stephen Day wrote:
This seems trivial, since you can drop all the blobs into the same |
On Thu, Jul 21, 2016 at 04:38:55PM -0700, Stephen Day wrote:
Spun off into #176. |
Ha sorry Stephen, that didn't sound that bad when I wrote it and thanks for explaining that. I was sure that was something image-spec already had and I was just surprised to learn it doesn't fully support that. |
and this is what I was looking for, thanks |
@runcom No worries. This is an active area that we need to figure out. Another possibility is to support a hierarchy in refs. Following from the example above, we'd have something like this:
This opens the question of whether or not we specify structure in the naming standard. |
@stevvooe what about having an file which indexes names? $ cat ./names #ugly
{"busybox":{"refs":"latest"}, "alpine":{"refs":"v1.0"}} |
On Fri, Jul 22, 2016 at 11:34:14AM -0700, Stephen Day wrote:
This is going to be difficult to support portably if we don't have
If “the naming standard” is for signed name-assertions (#176) it seems |
@runcom The makes merging more complicated. Let's say you have two directories with an image layout in them. With the json index approach, it would require special code to merge the json files. If we can define path semantics, the merge can be done with a naive Albeit, the approach of having a file with the name index provides much better security guarantees, since the set can be verified. |
On Fri, Jul 22, 2016 at 11:58:55AM -0700, Stephen Day wrote:
I'm still missing the need for (or ability to have) security on |
@wking Users interact with names. They need to be able to trust that when they say |
On Fri, Jul 22, 2016 at 12:31:55PM -0700, Stephen Day wrote:
Agreed, but names != refs. You say “please unpack foo”, and
The ‘foo’ ref is just a hint for finding the CAS root blob, not part |
@wking Naive code generally isn't that careful. Drawing the parallel here is dangerous, as programmers will make assumptions. We can find a solution that is both simple and secure, as long as we define the requirements carefully. |
On Fri, Jul 22, 2016 at 01:15:01PM -0700, Stephen Day wrote:
I guess I'll wait and see when you file that proposal^ ;). |
I am going to take this one and clarify that refs should not include an image name but simply the "tags". |
is this just temporary or what? did we move from |
@runcom it's more a clarification. After in-person conversation, it was clarified that the |
makes total sense, thx for the explanation @vbatts |
Based on the confusion from Antonio in the image-layout in opencontainers#173 we are going to move everything that was in `refs` to `refs/tags`. This does a few things: 1. It makes it clearer that this layout is for a single "image name" instead of allowing for lots of different refs. 2. It matches the layout of git so it likely matches existing expectations. This was also discussed during the OCI F2F and decided to be a reasonable idea. Signed-off-by: Brandon Philips <[email protected]>
Trying again with this: #225 |
Three issues:
First:
This sentence is wrong because I can have colons
:
into the refs subdirectory to say./refs/vbatts-app:latest
Second:
these two sentences don't play nice together. What are we talking about?
refs
naming? both? I can have./refs/sha256:5b58496
but what does that mean that the name will map toblobs/sha256-5b58496
? AFAICT the content of that refs which is a descriptor will give us the location in the blobs dirs, not the ref file name.Third:
The above (with
app/
) isn't making clear that an image-layout can carry more than just one app with:/cc @vbatts @stevvooe @philips
The text was updated successfully, but these errors were encountered: