OCI Weekly Discussion, 17 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OCI Weekly Discussion - 2021-03-17

Description

OCI weekly developer's call recording from 17 March 2021. Notes/agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#March-17-2021

A

And let's see, are we ready we're at what before after it can't seem to.

B

Be a stabilized.

A

Number of people that attended- I think these first two are yours. John we've been trying to put names next to him, so we know whose there are.

C

Yeah, uh well, jason can't make this time slot, but he has asked me to bug people about this again. um I think he addressed a lot of the feedback and has pushed somewhat recently a new version of this today. I think, and so is.

D

It hold on, are we talking about the actionable agenda, items or yeah.

C

Sorry for 22 and eight standards base image.

A

Annotations, did you want to escort those through john and just kind of walk through them, quick.

C

I honestly haven't even looked at it, so um I just wanted people to if they had looked at it and had actionable feedback uh a time to talk about it. It's a very small pr right. um So I'm not as happy with this as I was with the one everyone hated, but uh I am happy to see anything land.

A

Because you liked the multi-list was that the major difference.

C

Yeah, it was just a little less specific, um more abstract and so more generally useful and also having multiple is nice, but uh we have a proposal later. That makes me happy regardless, and so I don't.

B

C

As much and if one reference is uh enough for everyone to be happy, then that's fine with me.

A

Yeah, I think, if we're allowed to get a good place here, then you're happy, that's fine! I think the problem is if it's too generic, it's kind of hard to make tooling actionable on it right. If, if you can't really make a strong decision on what this thing is, then it's kind of hard to have consistent tooling across all of it.

A

C

There's a con common problem right because we're solving and oci solves both a very specific problem uh and also a very very generic and abstract problem, and sometimes we mix the two contexts and it's hard to talk about. Why we're doing certain things.

D

Is this? Is this data field going to be unbounded.

C

D

Let's hold down the right context of the descriptor.

A

Let's try to we said your vincent. Your feedback was, let's make get through a couple of actionable ones. So if we can, um because the data one, I think, will be a little bit more of a discussion so on a 22, I think there's two: is this the one with two annotations? This is base image.

D

Yeah, it's two there's two annotations, so this.

A

One's not huge.

D

I mean they're annotations, so they're shoulds, anyways, like you can use them, but how you should use them is effectively would only be enforced by some kind of performance, compliance, tooling and so.

D

I mean I don't guess that we really should can even say must in these fields, because that would be arbitrarily implemented by registries.

A

So I I think to john, I think we've got the right feedback coming on those on that one specifically on e22. So I think we just let that finish up. I think it's getting pretty close. I think it was just a some minor question on a sample because I misread it said descriptor, but it was actually the link was descriptor, so it is just a digest that makes sense and then we're just basically wrestling with the same old story of default registry. Do you get a fully qualified url? What does that mean?

A

And so I'm I'm trying, because I'm also trying to drive this other thing, where we want to decouple registry names from deployments and make that a mapping field that when you do, we should basically ignore this concept that the one default registry is docker hub, like I'm trying to make that go away, and so, if you're really trying to say this is the ref the from statement that it should be fully qualified.

A

So you actually could rebuild it or whatever it is you're trying to figure that out doesn't mean you have access to it like I shouldn't have access to john's personal. You know registry, but I can know that. Oh that's where that came from. So I could go back to john going hey we're trying to fix this thing and it came from your registry.

A

Hey can whatever that means, give me access rebuild it whatever, but if it's, if it's just sitting there as a loose name that that that doesn't really help me anything, it's the digest. That really helps me there.

A

But if anybody else has a different viewpoint on it, but I think that's where we left the pr.

E

So, just just so, this feedback doesn't get lost. I want to say that I also agree with where john was coming from uh that I'm not as wild about where this proposal is right now. um But the big issue for me is that, in this proposal is trying to encode inheritance that one image comes from another image. That's not really part of how the oci image spec is written right now,.

A

I mean to vincent's point of there's: no, must here it's it's just trying to say for the people that are doing the docker build with the from statement that they have a way, a consistent way to know how they would trigger like what is it based on because they can so they could rebuild it to your point. If you want to do uh build packs or some other way, that you're building the image or some of the other you know formats, then maybe you don't use this. This field.

D

Well, I mean that was that was actually. I was just like scrolling to make sure that misha was in this this thread, because, uh like I, I want this kind of information um in there and discoverable.

D

Somehow this, this kind of, like history or information, needs to be preserved somewhere and that's kind of what the little materials we've talked about before also like some way to spec out all this, even if it's just another object completely in the layers list that has its own like media type and otherwise I I would much much rather see another object in the media list. Immediate manifest list that has its own media type and structure.

C

You're gonna love the proposal from later then um yeah. I would just echo what sam said, because he made me realize something um I I think in the current form of the proposal is too prescriptive. um This, as in this, should be the immediate sharing zero index players. I think that's nice, and that it's very specific, but um I mean we could say, may instead of should, and that opens it up to me doing exactly what I want to do, which is um you know some artifact that represents my dependencies.

C

That might be a single base image. It might also be you know, a manifest list that references all of the images I I'm dependent on at build time, and so just changing that, from a should to a may, um would make me happy.

A

And why not just make it john's annotation and you can do what you want to do with it and like if you're, if we're going to be so loose about it, that I don't know how any tool would make use of a standard annotation as opposed to there's a that said, john's update. Whatever the scenario you want to support, it doesn't have to be under the open containers namespace, it could be something else, and then it means exactly what you want it to mean.

A

If we make something, that's so generic in an annotation and we're trying to enable some tooling. That's that I don't know how that's done in any kind of consistent way. Well,.

C

I guess I think this is very specific, even if that should becomes a may, um it means something very specific and it is still pretty powerful right, and so we don't even have to list any other situations. You know if that should becomes a may, then uh I think we're pretty good because you can verify if that is true right. If it's, if it's a may, you know the client might do do something differently than you expect, but it's still trivial for you to verify.

C

Wait a minute. These zero indexed layers don't match. Okay, so this isn't what I expected. This is not the docker from file based image. This is some other thing.

A

Okay, so we could keep on going zero. What is zero index when it's from or whatever, but this starts to sound more than an actionable thing. I think that the from the time boxing of it there's there's a conversation happening, we should figure out. If we don't fully support consistently across it, then we don't have to and if we can find a happy ground and add an oci annotation. That seems to make sense, but the process seems to be working through in the pr feedback.

C

Yep, I just mostly wanted to ping it to say: please give feedback, because I in the coming weeks, I would like to make this actually like a yes or no go or no-go decision. Yeah.

A

Okay, so just moving on the next one is the data one and I um john and I were kind of doing some feedback back on and forth on it. um I didn't read your latest comment, but.

C

Yeah, I just pushed it sorry, um but yeah, so I can talk about it briefly, but I opened this last week and um there are situations where you are referring to content that may not make sense to actually require an http request right. So if we're talking about pulling an image, maybe you have a layer that is 64 bytes, because this contains like a signature or something it would be really nice.

C

If I didn't have to go across the wire to go, get those 64 bytes when the the artifact that is pointing to it is less than that there is is even more right so like for for very small amounts of data. um It would be really convenient if we could just embed them in the descriptor that describes them. um So this would be exactly the content you would have gotten if you were to fetch it through any other means, and you should verify it in exactly the same way you would, but it.

D

C

Also be fetchable on.

D

The content addressable api.

C

uh So this is something that came up in the pr. I think yes, for now, um one thing we could do is fix how the non-distributable layers work, because that is a quality that should not be in the media type, in my opinion.

C

um So if we pulled like the non-distributability aspect out of a media type and made it even a bullion or something, um then we could use that behavioral expectation of hey- this might not be in the registry, or this might not be where you expect it to be to say, hey this is this?

C

Isn't there right like so clients would not expect it to be in the content, addressable store when encountering it, um but yeah, I think, for now you would just duplicate things to make it easier and backwards compatible with existing registries, because existing registries would expect that content to be there.

D

Well, yeah! That's because that was my next thought. Besides, I don't know how best to like set an upper limits on this, so you're not like unmarshaling, something that just literally makes you some red. Some implementation take a dump on the floor. Yeah.

C

D

There's the other pieces that how how best would you know for old registry, old clients and or old registries with new clients that you could see that you know a registry even supports this, that if that field is not even returned back, then it would be absolutely asking for that constant adjustable object next, but rather than trying to make some other api like do you support this feature like if the field is present, then you might not have to.

C

I I would be surprised if registries could support this. um I guess you mean on the um for, for the for the like reference. Counting part right, like registries, expect there to be a blob uploaded if the manifest references it um yeah, a registry that does support this- might skip that. But you know for most registries this you don't have to support it at all and and the push time is not really a place where you care so much about duplicating the content it one.

C

It's a very small amount of content, usually and two pushing can be slower if this speeds up pulling and and of course this is an optimization that you as an artifact author are making, and so you can choose not to do this.

C

D

C

Do not have the flexibility to choose whether or not to do this right, because they have to round trip the content addressable thing. So this is an entirely client-side decision.

A

And I generally worry about the payload size I mean a manifest was always intended to be here is a declarative information declared made by the westwood here is a description of the content that has been stored. Here's some metadata around it, so you can make decisions the config object. Lets you pull some information before you actually start dealing with the layers blobs, because the layers blobs might get routed to another host. So there's this very structured interaction.

A

I fully agree that we there's some places where I don't want to have to pull a blob to figure out the next step, um and we've been discussing this in the the linked list. Conversation of like how do I get a list of signatures and know which one I really care about, so I don't have to pull them all, um but the way this was written it it.

A

What it doesn't sound like it's bounded, is to can somebody just put a gigabyte worth of text in that string um and what's what is the expectation of this manifest? That's supposed to be relatively small.

C

I think uh to answer the first question: yes, I think it is valid to put a gigabyte in here um whether or not a registry is going to take that from you. That's that's your problem right like if you are embedding gigabytes of string data, um you're gonna have a bad time right in the same way that you can't push a layer with a million or an image with a million layers right. There are limitations that exist in the world and it is your responsibility to abide by those right.

C

You also can't upload, you know 100 terabyte layer to a registry, just there are limitations. So this is why I think it's I can add to the pr you know this should be used for very small amounts of content. Perhaps, and we could even have a number right, we could say.

D

No more than 64 kilobytes, no one.

C

Needs more than that right, yeah.

A

No, I think, that's a reasonable thing. Like we say, registry urls should not be more than 256. and at first it's like that, seems kind of limiting, and then I actually created a namespace with 256 characters like wow that that actually is really long and seemed reasonable.

A

um But, like the layer size, the layer counts, the layer size. The different registries have different sizing like we've we've all like and we've seen ml images start to push those boundaries um and to sometimes you can argue, no but they're making sense to me a manifest it's good to have some surface level, but if we can bound it to some reasonable textual size that, if I return a manifest list in an api that that's not the thing, that's going to blow it up, um I can see.

B

It being helpful.

A

But just not the idea, that's that's! Truly duplicative of, what's already in the blob.

C

Right so so, there's kind of two situations where you might want to use this. um I'm thinking about registries a lot, but of course all this applies in other contexts, but so as as something producing an image right as like say docker right, producing the manifest myself, we can have some language in there. That says you know you should consider the size of the embedded data when and what you're going to do with it right, because we shouldn't limit it.

C

We shouldn't say this can't be more than x because that that might be useful in certain situations, but we we can be. We can provide guidance that hey, uh you might not be able to push this to a registry if it's too large, and so you should keep this bounded and, we might even say a number as like. You should keep this under a kilobyte um for broad compatibility reasons or something right. On the other end as a registry, there are not any apis where I have the freedom to return.

C

Something like this right like uh I. I can't embed data in a um like manifest that I'm returning, but if we did do all the things I want to do with listing, manifests uh where we we call hey. Give me tell me all the manifest in the registry and the registry gives you a list of descriptors in that list. The registry has the flexibility to embed the manifest data right, and so you could ask the registry hey, uh give me all the manifest and include the data, because I don't want to send you.

C

You know a thousand requests. I just want to send one giant request: um we that doesn't exist right, it's hypothetical, but uh in that situation, because the client isn't expecting a content, addressable response.

C

This is a totally reasonable thing for the registry to do, and it would be up to the registry to decide the threshold for that right, because the client isn't expecting this to be it's an optimization right. So if the client sees the data is embedded okay, I can use that. But if if the data is omitted because it's above some threshold, the registry decided on uh then the client can just go fetch it again, but then so it's a there is a reasonable fallback that already exists, and so this is strictly an optimization.

A

I I guess I see this group and this oci specs as being a way that there we can create more consistency across the registries to enable more tooling that isn't cloud or registry specific, because it's just frustrating all of our users. You know the fact that docker pull docker run, you know, docker push is just in the most simple works across all registries is been a huge thing that has brought the whole platform forward.

A

The fact that we don't have listing apis or searching apis and and consistency on some of these things has been a huge detriment um to us to put to start saying that hey you could do this, and the registries might do this and it might not. It feels like it provides more instability that we're just hacking stuff into something, as opposed to coming with a better way that a manifesto is about this. You know the information in summary, and if you want the data, then you can get the data. um I.

B

Say sometimes you can probably just in it.

A

Would be very destabilizing to what we're trying to drive.

C

I think you're very wrong. um I agree with you. Your point stands for like the base image stuff. I kind of agree right. It would be nice if this meant exactly one thing, but for this it's it's strictly an optimization right it. The existing model continues to work. Even if you completely ignore this field right and so there's not there's no instability right. It is only in the same way that, like http, caching, stuff just works, and you don't think about it. This would just work and you wouldn't think about it.

A

It would just work if the registries work when it consistently and the payloads.

D

They don't have to they. Don't have that. That's that's! What he's saying is.

A

C

A

Tooling, are we talking about google specific tooling? That would work with the google.

D

Registration registry.

A

Tooling is supposed to chase every registry with a different implementation.

D

If you're registering, if your registry and or tooling could make those optimizations, because I mean I could imagine this even going into container d- that it just likes- looks for that data field and if it's there, then it has an optimized experience and it like you, like you, said you, you know, don't have the the baseline experience on all registries. But if a registry so chose to implement this support for this data field, then some clients would have a more optimized experience.

C

Yeah, this allows progressive enhancement right, there's, no backward incompatibility problem, both clients choosing to support or not in both registries, choosing to support or not works. All always there's no there's no place where this is a problem.

A

Well, I think we're highlighting there are. There is a place of a problem. Where is, is the idea that the registry can stuff the data field if it wasn't uploaded with it? In the first place,.

C

No, absolutely not only in non-content addressable context so and none of those really exist. um So it's not a problem. Currently uh in my hypothetical listing proposals yeah, the registry could choose to populate that, but it is a completely valid implementation to never populate this field and for a registry unless it, you know the registry doesn't have flexibility currently in basically any api. It has to return what was pushed to it, because all of it is content, um I'm completely I'm on board with it.

D

That and I I think I think that's the kind of interesting part that, even as as you were talking, I was trying to kick around like if somebody did like you said, even if somebody did find a registry that supports it or make one, and they show way too much data in that field, they would get to experience how they're, having a bad time and not you know, or just get blocked, which is probably the safer nicer way so that you don't find like the payload, the payload small, like signature, piece of it or like attestation or otherwise, like small small things, I could see how this is pretty neat.

D

It's something we talked about for a while of even like wanting to push towards like http, 2 or like keep a lives and all these other kinds of optimizations like.

C

Reduce round trips as much as possible, yeah and and to be clear like this is not coming from me. I found this uh like. I thought it would be cool if we did this and I went to go at like create a pr and I found oh, they already decided to do this earlier, and so I messaged uh steven day. I was like hey what's this field for, and he said exactly what I'm proposing and so like this. This was planned to exist and I'm just trying to drive it forward, because it's a great idea.

D

Cool, that's all. I need.

F

All right, you got this so somewhere else. The field has already been there. It's already supported in docker distribution. It just didn't have a proof of concept behind it. It.

C

Is reserved fully.

F

C

Really it's a reserved field, and so let's make it a real field.

F

Right, I I think I I for sanity, you might want to hold this open or you know, as a draft working in progress until we get proof of concept on both the client and the registry side and then and then you can, we can drive it forward from there. It might make more sense to see what kind of optimizations and see if there's anything else that drags. You know it introduces like that, the limitation of when the client doesn't have it. Maybe it's too much data what's nice? Is you don't really.

C

Need registry support right registry doesn't know about this at all, I'm not on the.

A

Client so, but there's a size constraint that I think we said we want to have some kind of reasonable size constraint on it, because we all do optimizations around how we store manifests so.

C

That already exists.

A

C

There's already a size constraint right like I can't exercise not in the spec but in real life right. I assume, if I push a gigabyte, manifest to acr it's going to choke it's going to give me a 500.

F

Or 400 right, that's, you can't even have a whole lot of annotations before we're going to barf right. So so yeah yeah.

C

Yeah and yeah this isn't very actionable. Maybe they should have been part of the discussion, but I would like people to look at this and give feedback because I put it together. Please take a look.

A

Okay, what do we got? That's next here me.

C

A

Cool stuff, this one.

C

I didn't quite understand.

A

What this one was, do you want to.

C

Sure so we talked about this three or four weeks ago. um There are currently there's no way to really mutate things in a registry safely, and I'm talking about tags specifically.

C

So if I wanted to push a new image, um let's say so: okay, the use case that came up is like when you're producing multi-platform images, it would be really cool to fan out a build for like each platform to some build farm. Where you have like an arm machine and an amd 64 machine. It would be great if those could coordinate at the registry um by say checking to see hey.

C

Does an image exist at this tag already it does great I'll append what I just built to that image and then update it, and so you can like incrementally build up a multi-platform image. You can't do that today because of race conditions that exist right, so I might overwrite. What's already there or I you know, I might not see someone push something it it's a problem and http solves this problem using conditional requests, uh you you have e-tags and then you have. um Let me see.

C

Let me open this because I can't remember the exact headers but there's like if match and if none match headers and there's well-defined semantics and http, for you know: hey, don't overwrite this or only overwrite this. If the current value matches what I expect it to be right, so we just get some optimistic, concurrency controls and all we have to do is document them. We don't have to make them up. We just say hey, you know this is http.

C

Let's, let's do http the way it's meant to be, um and that's what I'd like I'd like to just call it out specifically and say: hey registry should return e-tags on manifest and registry should respect conditional request, headers.

C

That's it it's small.

A

No, it makes sense, because tags are the only place today that we have well index. I guess that's is another place index and tags well, an index actually is only updatable because it's related to a specific text as it index itself is its own digest. So it's really tags the only place in a registry where we have update semantics, because everything else is immutable.

C

Yep- and I would like to flush out- maybe the pr with more examples right, but uh it really is just hey, implement this rfc over here. Please.

A

Now part of the the notary stuff we're going to have to introduce tag signing- and this has been one of the things like in everything other than a tag- signing you're just signing a digest. So that's relatively easy. You want a signature to be associated with something you want to be able to add signatures later on, and you can add them to a digest, because that's the basic design um to add something to a tag which can be updatable, that there is some conditions there. That would be great to have put some locking around it.

A

So this makes a lot of sense.

C

Yeah, so I don't know if anyone thinks that's a terrible idea, I think it's pretty straightforward. I would love people to give feedback or maybe add their own use cases or examples, and then I can I can keep pushing on it. We probably don't want this for 1.0 of the spec, but maybe one point whatever I don't know.

C

Does a is anyone who, like can speak to a registry implementation say like whether or not you already respect this or if you would like to implement this, I'm curious about willingness or existing support to for this thing.

A

From an across, I don't know whether we do I'm doubting we do, but if we don't, we should like. I I do we. This has been a problem. We, the geo, replication stuff. This is one of the places where, uh because we support master, you know active active scenarios. There's there are places where this kind of thing has showed up. This really doesn't completely solve it, um but it gets closer to solving some of the individual uh region updates.

G

Yeah, I think the goal here is just to create that primitive. That lets you do an atomic update or have that atomic update fail so that you can try again or whatever failure behavior you want. It's definitely something. We in official images have struggled with a lot.

C

Yeah, I think this opens up a lot of use cases that were previously impossible, or just everyone was living with race conditions and crossing their fingers right.

F

It definitely that's why it was grimacing. It was like. Oh man,.

A

It's like you made it more granular, you didn't really tie it to um multi-york, manifest updates right or the index updates. It's not like, because there's been other conversations we've been debating. Should a registry manage the updating of the index itself and there's some interesting ideas there there you know and there's certain places where there's good registry specific implementations to kind of innovate in that space. This isn't going that far.

A

This is simply just saying that look, there's contention on an updateable element of a registry it'd be great if we had a better semantics to be able to handle that and have that defined in the spec again back to here is something that's in the spec that it should work consistently across registries, because we've implemented whatever version of the spec, assuming we could ever get a 1-0 out, um but yeah to get this clarified would be great.

C

Cool! uh That's it for me,.

H

There's one there's a question that just popped in chat there. Oh.

C

Where is it on top.

B

All right, I I don't know if my mic is working um but yeah like the conditional request stuff. I see that there's a must in there.

B

um If we're, for people who are like building on top of say, like s3 clones, that don't implement strong consistency, how would we possibly do this.

C

uh So you wouldn't supply e tags for in your responses, um the the must is guarded by an if and that, if conceptually it cannot exist. If the registry doesn't support e-tags for manifest.

B

But like e-tags are also provided by like proxies and such um like cloudfront.

C

G

Registries also already provide e-tags, so suddenly not providing them could be perceived as a breaking change, because I'm sure there's someone out there relying on them, I'm certain of it.

B

I mean sure yeah like putting squid or apache in front of the registry uh automatic like it. It automatically generates these tags and I I think, that's like non-standard behavior to change that, because it means that downstream components like cloud front wouldn't be able to cache your images or your layers.

C

um That's a good point. We could invent a header or something in the response that says, like you know, oci dash something stupid that says like yeah. I I understand conditional requests.

C

If we want this to be a the registry to communicate support for it so that clients can rely on.

C

It no problem with that that seems reasonable enough to.

C

Me, okay, I'll I'll, add that to the pr uh we can keep going. If no one else has concerns or questions.

F

Did did you want to uh try to get this into the first release, or were you thinking.

C

I don't know I I don't have strong opinions about releases because they don't really affect me. um I mean it's just a number, so it doesn't matter. I just want this to land eventually, and I would like everyone to implement it, whether or not that's in the spec, 1 or.

B

F

Just trying trying to avoid feature creep if it's not.

A

Yeah, I think I I I'd defer to um josh and others have been trying to get the 1-0 out, but I think that they're we've had 1-0 cued for a year. Two three.

F

Run season four years now, I think so try to try and avoid that if we can, because we got a very narrow scope on what we have for 1-0, I'd like to see a boat on getting that one.

F

But I like this option, it looks like a really cool feature.

A

Cool all right moving on uh next one was two wait. Was that no, that was the document condition request. The next one is uh damn.

H

Yeah hello: I opened um an issue with a bunch of text, explain some motivations and use cases and design discussions as well as an accompanying pull request to kind of visualize. The exact concrete changes we're proposing against the distribution repo, so both links should be in here.

H

Currently, if I look yeah okay, so I can get both links. Eight two eight and eight two seven are on the image spec repository you.

A

H

Just present dan, so you can check this out.

A

As you're talking about.

H

See if I can get zoomed to cooperate.

H

Is that working.

H

Yep, it is cool people can see now I have to switch because it immediately open in a new tab when I click the link all right. So here is the pull request. um We can see a diff um and then the longer discussion is in the issue which I'll jump to in a second. After we talk about this. um The summary here is that to propose make another kind of concrete um self uh freestanding proposal on ways. We can start linking objects in a registry um and even not in the registry, as we propose here.

H

um This covers a lot of the same use cases as the proposal. I think it's in the open containers, artifacts repo as a draft pr, um but the the real use case is around signing containers. You can build up john, it gets excited because you can do a whole bunch of other cool stuff when you can do linking this way, but the real thing I want to use this for and the reason I'm pushing forward is because we want better support for signing of containers and other artifacts.

H

In a registry we have a tool called cosign, which you can see and play around with if you're interested, but it's kind of a proof of concept or working tool that does container signing and verification on top of the existing ocs spec without any changes.

H

So from that, I wanted to extract the smallest possible set of changes to make that stuff better and not have to do the hacky stuff that it's doing but does tend to work pretty well.

H

So the real primitive that we need is a way to push an artifact and associate that with another artifact and then a way to query all of those references later like a reverse index. So if we jump back to 827, let me figure out how to do that without opening a new tab.

H

If that's an issue, so I'll just go back here, actually, here's the my proposal explaining the background um how I designed this goal of making this as backwards compatible and as easy to implement and as small of a change as possible, while still enabling all of the use cases and requirements that we've identified for signing of things.

H

The link pr here again shows the exact small set of changes. um There's some examples of what this looks like uh to try to keep this minimal. We use the existing types that we have instead of making up new types, so the uh these references actually take the form of a descriptor.

H

um So it's basically one new field on image index and descriptor as well, which is um the one that powers some really complex use cases to reference. Another descriptor, um then this is all in one change now to make it kind of self-contained.

H

But this also does propose one other change to the distribution spec, which we can turn into a pr there. If we decide to move this forward um of one new read on the api to get the references associated with an object, um so most of the stuff is in here there is this one extra change: we've discussed some of the implications for registries and how they might implement that below got some example.

H

Use cases signing and verifying one is the one that I really care about, but you can imagine other ones we can fill in later, like attaching s-bombs or other types of information you get after the container is built, feel free to add stuff an issue we can merge it up into here.

H

um There's also the one main alternative. um I considered that I discussed here and why we didn't like it, but there's a way to do this, with no changes to any of the existing types, with only some registry side changes um that would look sort of like this, where you would push something by pushing it under an existing reference, rather than pushing it to the top level and that works with get and delete, and everything like that too.

H

I like this one at first, but after I thought about it a little bit more um and talking to john, I said the the other one's probably cleaner, even though it does require the type changes instead, so yeah feel free to take a look at these only got them a couple hours before the meeting. Apologies for that, but I did want to get this out, so we can start discussion and figure out if this is a good path forward.

D

What what do you think your uh or what are your feelings on if, if garbage collecting, if something has references.

H

I, like it um john says that we should leave that up to the registries to decide if they want to do some registers, don't even garbage collect. You know things attached to tags when they get deleted.

H

So I think in general um this gives registries the information they need to garbage collect if they want to, but it's up to them um if they want to yeah, because that.

D

Was even something that kind of stalled stalled me and a few of us out when we were talking about like the ex that extensions pr that I know steve you've referenced a few times of like adding these extensions that might bring new references. You know like pushing pushing that kind of decision all the way back like eventually it's just it's not an extension. It's a whole feature that you have to bring on or not um right like garbage collection, because I don't, I don't think it should.

D

I mean like they could, but they don't think they should, because it could be that I push. I might even push a signature to my repo that I can address or something that's in another registry that I tested completely unlinked. I don't even have access to push or relate to that other other. I don't have privileges to that. You know ubuntu image and docker io, but I pushed it to vbats on quay or whatever and saying like I test attest to it somehow.

H

You're convincing me more that john was right and that this text is correct. um Registries are free to implement garbage collection, as I see fit. That's how I put it. I like.

D

H

Sometimes he's right so.

B

H

You're completely right, though, um I think the the other alternative we have here would make it more clear. The garbage collection um wouldn't make sense, because you're actually pushing it under something else, and so um yeah moving it to the top level and then saying you're free to do whatever you want just make it clear to your users makes sense to me.

H

John, do you want to talk about some of the crazy stuff you love and we're getting excited about earlier about the.

C

H

Descriptors and a list.

C

Right uh so so there are a couple I have a couple like. I want to bike shed this a little bit points um and, depending on how that goes, this gets really powerful, but also a little crazy like right now. Reference is a is an object. It is just one thing, but why not? Let that be a list say um and then you can create like arbitrary trees of this stuff, really dags of this stuff.

C

um And if you combine this with the data field edition, you can now inline an entire tree in one object right, so you could, since, since this makes descriptor recursive, uh you could have just sprawling trees of references all embedded in a single object, and I think that's neat. um It.

D

Is it is academically neat, and that was it? Was it so? My mind was just going there, but it would. It would hit some other threshold limit like too many objects or too many layers or whatever pretty quickly.

C

Yeah, I think yeah you'd run into natural limitations of the underlying storage systems. Pretty quickly, if you try to do arbitrary depth, but what's nice is that they can't be cyclic. At least you know um the the other.

D

Point where they could you could you could find enough random choices.

C

D

C

Go break shots yeah, um the other. uh The other point I thought was interesting is that going back to the base image discussion? um You know this kind of works for that right, so I could push up a um some artifact that references um the image I care about and says like hey. These are all of the inputs to your build uh and I could, instead of having it embedded in the manifest. I could have this external reference to contain all that information that I care about. You might want to.

D

C

D

Case because I'm pretty sure even just that that right there could build quite the story for for some of the stuff that nisha isn't investigating nisha kumar.

C

A

C

So one of these starts to.

A

Get weird because this was the thing that we did like if you look at the artifact manifest proposal, it's it's doing the same thing. It's just we're not trying to make breaking changes, because that was the problem we had when we tried to do other things to the image manifest and so forth.

A

The the original proposal had two types: one was here's a manifest link, manifest collection, so you can reference an s-bomb. You can say a reference, another thing, but it would be in the same repo, because that was the permission boundaries.

A

We also had another references collection that could reference things that were outside of that repo, so that enables like the helm chart to be able to say these images it references you can actually copy things across, but that's the one that I think, john. You push back on, specifically that you didn't want to be able to support things cross, repos, so vincent, that's kind of the challenge we've been facing is: should you be able to loosely reference something outside of the image?

A

Immediate repo that you're in? So that's why we pulled that piece out, because there was so much controversy around it right. I think.

C

It's a good additive.

A

Thing that we should consider adding later on, but I wanted to handle the direct linkage first um and then then get into the loose references.

C

So I right so so this pulls out some of that in and in a slightly different way. um I think so have like this enables cross repository things. If you really want them right, so you could have, because this is effectively a weak reference to an object right. um You could have in the urls field, like hey, I'm referencing this thing over somewhere else um and and that's a way we already do that today to to reference objects, not in the same link base.

C

um So that's like composing, two properties of a descriptor to achieve a very complicated thing, which is you know, multi-repository artifacts, um but so the my problem with that mostly was like. If you expect a registry to maintain some that relationship um across repository boundaries, that's really complicated. But if you let the registry say like oh a reference, you know I'm not going to count these weak references as, like.

C

You know, pinning garbage collection stuff. um This gives you a different kind of descriptor that can have different properties within the registry, and so I think this solves that in a little and kind of.

A

I think the question, though, is how do you define a weak versus hard reference or whatever strong reference, whatever how you want to do.

F

A

F

The way I would define it is the current the current references and the manifest which are which have a config descriptor are the hard references right and- and these are weak references that we would be adding to every descriptor type, including layer and manifest config right.

A

So so it's not just the weak and strong connotation. It's the downward or upward reference, also kind of thing like a manifest that has layers. None of those aren't just strong references, because that's the thing that defines the thing right, like a manifest, has to have layers in it before the manifest can be uploaded.

A

The the thing that we're trying to do with the s-bombs and signatures is, I can upload things after it's been in a registry, so you similar to a manifest, can't be accepted until the blobs have been accepted. You want to make sure that the thing that you're referencing, whether it be through a references, collection or manifest collection, you want to say whether that thing must exist before it to be accepted or it can exist before it's accepted. And how do you differentiate? Those two.

C

Yeah, I think that's why we want to make it a new field. So one of my one of my problems with the current artifacts manifest proposal is that it reuses the manifests field to have new semantics, and so I could come up with a bad registry implementation that considers those strong references, because it looks a lot like a manifest list. By putting this in a separate thing and we we can have the freedom to define what this field means, and I I think you.

B

Know basically,.

C

This is a weak reference. Anything under the reference field. That's a weak descriptor, um so it it may not exist in the registry right.

F

When you say it's a weak thing, whatever you need is weak in the description.

F

D

F

Trying to understand the type model right, because yeah yeah yeah.

E

Both the config.

F

And the manifest and each layer right in the manifest are descriptors themselves. So it's hard to talk.

C

When you added this reference,.

F

To the descriptor type you made manifest more powerful by having both the strong type references and these weak, these new references and the descriptors that they can be considered.

C

F

Type references- that's it. Yes,.

C

And that's that's what I was trying to get at with my comments on the artifact. Manifest proposal is that this should this is powerful. I want to use it everywhere. um Well, it got me.

F

Confused when there was a get on just the ref, these weak references I was like. I don't. I didn't quite understand that yeah.

B

Why wouldn't you just.

C

F

Manifest right and then that would have all those references in it.

C

Right um right, and so that so the registry part is the like backwards, pointing part right. um We don't really need to store new information technically right. All of this is in the content, so you could satisfy an implementation of the like index by just crawling every single thing in a repository and and populating it as you need, um but yeah. What I was talking about earlier was the content referenced by the reference descriptor and not the containing descriptor uh may not be present in a repository.

C

So right it is. It is.

F

It's an optimization that could have been put into the manifest when it was pushed.

C

uh Maybe I don't understand what you just said.

F

I'm just saying you, you could have added these weak reference references in the in the descriptors, for each layer and for the manifest config. Therefore, providing the extra detail that nima has been asking for since forever, yeah being able to create a tree.

C

Yeah and so the what gets tricky is like what you know populating the response from the registry. When you ask it hey tell me every manifest uh that references this subject, um that's hard right. Most of the hard part is there, but deciding on how we express that relationship in the format is what we want to accomplish here. I think um but yeah.

F

So not just storing it, but also you're, looking for some kind of an api that the registry could use each of those references as links if they've got access to it as possible.

F

The theory goes the.

A

Reverse lookup thing is basically you're, not looking for a specific signature per se you're looking for an artifact that the wordpress image and does it have a signature. So it's you kind of you want to start with the wordpress image and then decide. Does it have a specific signature that allows you to pull it, and that's the reverse link api that the registries don't support today. It knows how to find an image and the layers for that image. It doesn't know how to excuse me um find other artifacts that are referencing.

A

Okay, enhanced an existing artifact. This the signatures are nest bomb. For instance, you.

F

Get it now thanks.

A

So that's the links api that we've been talking about or whatever it's called.

C

Here, yeah, so the yeah, so at the end of the day, what we want is, I want to ask: hey docker hub, tell me every single thing that references ubuntu um and when I say references I mean, has embedded in it. This reference, descriptor um and so registries now are obligated to index the stuff right, and so that's a big change. But if we all agree on it and we all implement it, then wow we've got this magical thing.

A

I mean, finally, I think, that's the piece that we've all been trying to get to is: how do we add additional content to a registry without breaking the the seal of the original content? We can't change the digest. We don't want to change the tag. How do I add something to it after the fact?

A

um The the challenge that we've been facing we went through this with the artifacts is: what can we change in the manifest as it exists today, because there's not good versioning and everybody was like super nervous about making changes to image manifest and image index, so the what all? What the the only real difference, I'm seeing here in addition to the fact that it's a collection or single, is whether we're changing the existing manifest or we're adding a new manifest, so that there's no breaking changes to the tooling. That's already using this today.

C

So I think I think you and I are getting tripped up over incompatible terminology where there's a difference between something that's backwards compatible and something that is a breaking change. um I prefer if we can make backwards, compatible changes, but I refuse to make breaking changes and I don't think that this is a breaking change.

C

This is a backwards, incompatible, change right, because regis clients now have to do new things, but um it doesn't break existing behavior in any way. That's purely.

H

Additive, it doesn't change any of the semantics.

A

When we added the artifacts, when we proposed that an artifact type property to the manifest or some other things so like derek- should be here for some of these other conversations which they don't see them here. um But that was explicitly why we didn't go down that path and why we've been going down a new, manifest proposal.

C

uh Yeah so I mean it's: it's I'm gonna push back on anything that is both not backwards, compatible and not breaking um and we're past the backwards compatible part into the maybe breaking part, um and I don't want anything that is breaking.

A

Yeah, I think anybody's proposing. Well, I think, that's the argument for this is that the schemas today, don't the clients today would not work well when new elements show up in the manifest. I didn't think that that should be a change. I mean anything should be able to ignore new properties. That would be my argument.

A

That's that way I would expect to write code, but apparently enough, clients today that didn't handle that well, and there was a huge concern around that, which is why we wound up using the config, the manifest config media type, because there was no comfort in adding another property um because it is additive. I completely agree with you, but that's that's how we wound up where we did, because there was no comfort in that.

A

um The same reason, why that's- and that is the reason why we've got a new manifesto- that's not breaking it is additive, and it gives us the opportunity to be very definitive around the rules around delete and reference counting the manifest collection which again we can name anything. We want the reason it's a manifest. Collection is because it is referencing manifests as opposed to blobs, and we can then define semantics if it references a manifest that it doesn't have a tag it should get deleted.

A

If it has a tag, it gets ref counted and it can still be there. um It allows us to give us those same semantics and- and there is a collection because we felt like while we don't have a more than one scenario yet there's we want to make sure that we can add a more than one scenario um and then the links api, we're basically saying the same.

C

Thing yeah there's. I don't think we have time to really dig in. I have opinions, but um I yeah I would like feedback on this and please bike shed, especially things that I want a bike shed like. Should this be a list? Is there a better name than reference? I came up with subject or subjects. I think that might that's maybe more specific, but I'd would love to continue this discussion on the pr or the issue.

H

Thanks everyone.

A

Yeah we're at three um just reminder: please get things in the hack docs, so we people can plan appropriately for their schedule. It's this. We we're gonna, cancel and showed up last minute, so I don't know if that's why we have fewer people today. So thanks folks, we'll pick it up and watch the recording and we'll pick up next week.

F

Maybe weak reference john well yeah, okay, naming's hard see you guys.