OCI Weekly Discussion, 12 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OCI Weekly Discussion - 2023-01-12

Description

https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#January-12-2023

A

A

A

B

B

C

Reminds me of getting back just after New, Year's and Tuesday felt like the Monday is Tuesday ever.

C

I guess we don't have any names on the agenda items, so somebody want to take the 1.1 release discussion.

D

um I guess I've been all over the place, but are we? uh Are we feeling good about like after last week's discussion about what to change before we do another RC um I I have a feeling we're not going to do this by that conference at the end of the month, but I'd be delightfully proven wrong.

C

Yeah my suspicion, just knowing that I need to prepare for the conference myself, is that we probably won't have time to finish up all the RC items there. All the various open tasks on that Milestone. So potentially we've got another RC, but yeah I. Think the big thing from last week was just that we got some agreement from different parties that our registry can refuse a manifest if it has too many annotations.

C

Watch that, given that that frees up the concern about lifting up the annotations up into the descriptor.

D

Okay um I know there was an outstanding item about conformance um two two ideas for this, so one um it's kind of hard before Registries or implementing this to really write performance, um I I think Azure has some level of support. I. Think zot has some level of support, but I don't know it'd be kind of hard.

D

We basically have to code against one registry um I'm wondering if we want to punt conformance or option one or two just check for the refers endpoint and see if it's there um or plus, like chucking a artifact manifest and see. If it's there.

C

My own Comfort level is to have conformance check for everything and anything we think we want to include in here and then, if we realize we've got a problem, we want to relax the.

E

C

Later on, that's a lot easier.

D

I guess I'm, just you know, I I had hoped I'd have worked on this, but I just I just haven't and um I don't want to like hold up the release so.

C

I have in certain places volunteered to help you out on this one, so don't feel like you're, the only person that has to work on the conformance on this.

D

Well, if it's it doesn't matter, if it's me or you or someone else, it's just it's not, it hasn't been done yet and we've been talking about it. So that's all I'm saying.

C

F

Hey so this might be a good time on it. Sorry I'm joining a little late I was on a customer call um so I. This is probably a good time to just float the general idea like how the team feels or how the community at large feels about a spec going out ahead of compliance tooling, um as obviously, historically, we released the spec ahead of compliance for 1.0, and this is the first time we've had a minor release version.

F

So we're kind of setting a precedent in some ways, so I wonder if we can kind of up level this and just say, is this a blocker or not, and then from there we can determine if we need more resources or if we need to prioritize it, because, obviously we can say yeah everybody does it. It hasn't gotten done like Josh said and I think sometimes I I think somewhat we're not sure if it's a priority or not.

C

I would be comfortable if we just had a single conformance test that failed, and so that way nobody can go and say that they're doing 1.1 conformance yet because we haven't created the test for it. Yet.

E

What is that sorry if this came up early, I'm, also late, uh but I, don't have as good an excuse as Jessie did uh what, if we had a single conformance test that just said that slash references responds with an index successfully within nothing about the contents of that index. Just that it. You know the bare minimum to say that you are 1.1.

E

Are we worried about that? Letting people say their 1.1 prematurely.

C

I am I'm worried that somebody will implement.

E

It incorrectly.

C

A

C

Still get the check and pass and register themselves on the site and say that we've done everything oci said that we are supposed to do.

E

Yeah, we also as humans, approve those PR's to add them to the site right. So we can say like listen in this current state. The bar is on the floor. You've passed the bar, but that doesn't mean anything so we're not going to merge this PR right. We could it's not an automated thing. It's like someone somewhere says it's a you're above.

C

I think it's a lot easier. If we say it's an automatic fail with a message that says: conformance has not been written for this yet for 1.1, and so, if you want to do conformance, you can do 1.0, but not 1.1.

E

I suppose I'm fine with that, how do other people feel.

F

Or skip I mean, do we have I can't remember, and compliance that we have a skip might be a a good like I know, we talked about it very early.

F

Full disclosure I've been away from compliance for like four years so.

C

D

We yeah, we have ability to skip um yeah, we're already doing that for like you, can skip push or you can skip tag list, and so we could, by default, have a have a test that just yeah, because it's non-zero and then, if you put a skip, you can do the skip. I guess.

D

1 1.1.1, that has the Real Performance and then people can submit.

C

When people are running the conformance test, are they running it from the tag release or are they running it from the main branch.

D

um So for the for the compliance or the oci conformance repo, it's the tag. Release like it has to be. That's the rules um but I know, for example, zop is running off me so they'll. If we throw something on there, their CI will fail. Today.

D

They may offended actually I I really don't know, I, don't know if someone's here.

C

So, if we're looking at a hard deadline at the end of the month- and we want to ignore the conformance challenge there- we can we've at least gotten out on that one I'm, not thrilled about that album personally I prefer to push it off until we have the performance in that way, you do it all, but I'm I'm not going to be the block on the air if the rest of the community wants to get this released.

D

Well, I think I think people want it released, I mean we. You know we started about a year ago.

D

Talking about this and we had a year to do the conformance um I think it could be the type of thing where, like no one can say, officially quote you're, not seeing my fingers doing the quality science, but officially 1.1 support, obviously, but like I, think, like there's a lot of people who want to start, you know talking about this in marketing and writing clients against it, and it may actually be in a better State, like once, clients start doing stuff to really understand the behavior um but I like kind of agree with you, Brandon I, just you know, I just um feeling busy and you.

C

D

Not wanting to push it out any further kind of.

C

I'm busy right now, just because of the uh the security Con coming up at the end of the month, and so after that I'll have time to actually sit down and go over this, possibly for a camera presentation knocked out early.

G

uh If you want I can put some time into helping out with the conformance test, I think I'm a little more comfortable with go this year than I was last year.

D

um I I would offer also like yeah I. Don't want to just like talk about this until the end of time, um Nisha and Brandon, and whoever else do you want to like do a calendar on Monday or Tuesday next week. If you have time and just like, do it together,.

G

Foreign, so next Monday is MLK Day right.

G

But um I can carve out some time on Tuesday uh I'm on Pacific time, so um I think I'll. It's compatible with Brandon's time.

G

I, don't know about you, Josh.

D

I'm yeah I'm fairly free after, like your 10 AM.

D

um So it's just a matter of Brandon being like Brandon, is kind of the rep refers expert here, so I, just I like it'd, be nice to do a screen trigger I can drive and kind of get the end points together, but um I guess, let's consider we could put something together, even if it's tiny next week for conformance what else.

D

C

Foreign is probably what Sanjay wanted to talk about, which is 365, which kind of gets into. Are we going to include that in the 1.1 or not.

C

And I don't know if Sasha.

F

C

I just want to take that one yeah.

F

Sanjay, if you're, if you I, I, put it on there, but it's such A's issue, so um I could start I. Think I think this just Loops back to precedent. Setting right like this is the first minor release of the spec. So we haven't had to worry about this.

F

um I can say specifically watching a one one client effort in particular kind of thrash around how to manage things across multiple Registries. um You know it's I, think it's easy to say. Well, we could um you know we could just try and push an artifact and if it fails, you know don't use them. But it's kind of it's a lot simpler for clients to reason about saying: oh, it's 1.1 we can use artifacts so I. You know it seems simple enough. It seems like it would not be and I know Brandon you.

F

You had some some concerns about it, which I, absolutely we should talk through, um but I I personally, I think that you know and capabilities aside, like I, that was I know. That was the original thing. I brought up we'll just put a pin in that, but just a simple version and point might make sense.

C

So I think we had landed if we're going to do it, it needs to be capabilities, not just a single version, because our registry can mean a lot of different things behind a version number and the the question you usually have is: is this endpoint there? Is it going to support this manifest.

F

Yeah I do agree with that, but I also feel like we're hand. Wavy enough, like I mean, as you all know, ECR is not 1.0 compliant, but it certainly is a 1.0 registry right and there are certain things that we could change. There's certain things we can't change, there's certain things we could change in the spec, but the reality is is that at least a client can say: okay, that's a 1.! Oh this behaves differently weird and like put in this little corner case and complain to us and so I think that's!

F

The thing that's missing is just is the broad stroke that says roughly you can expect artifacts and refers API if it's 1.1, if you behave weirdly and whether that's you know, registry X registry y or register Z, then the client implementer can say Hey you behave. Weirdly I had to put some some work around code in and I I. Don't like that here fix that right, whereas right now it's like every registry um behaves a little differently, and so it makes it much more difficult.

C

Yes, um definitely from the client side, I feel as well. If a registry says that there are 1.0, because for some reason they don't want to support the artifact manifest, they only want to support images on their registry.

C

It doesn't necessarily mean that it's not going to support the referrer API, and so you would still need to go through and sure well.

F

A

Right, we talked about that.

F

Before, like I mean I didn't mean to talk over, you I'm, sorry, I'm, really bad at that when I've had too much caffeine, please continue.

C

Yeah, so that my fear is that all the fallback scenarios that we had done for the referrer API or design there specifically, so that all the clients would follow the same path, no matter what they're talking to and so I I don't want to get into a scenario where one client looks at the registry and says: hey I checked the version. Api I saw this 1.0, so I'm going to go down. One path and another client looks at the registry and says: hey I, try the refer API and it was available.

C

So I'm going to use it and now they're going down different paths.

C

Go ahead. Jesse.

F

Sorry, I'm bad um totally hear you I I, agree that that is one potential outcome. I think that still lands in a position where a client implementer gets to say hey. This is you're behaving weirdly um and then a client might say I'm just always going to do.

F

1.0 and I don't care what's there and if the reverse API is there, then I will use it and I'll surprise my users, then people can say hey client, you're, behaving weird right, like so I think that there's always going to be those sorts of potentials in Broad Strokes again for a client to say, are you 1.1, okay, cool I, know I now can use artifacts and refers API, that's kind of what we're looking for.

F

There's always going to be this thing where like well, it doesn't even implement it right like because at 1.0 registry that isn't touched might not even Implement that version endpoint right. That's not going to be not spec compliant for 1.0. So if it's not there, it doesn't mean that it wouldn't support the refers API.

F

It just means that a client would have to discover that by other means and use it with caution, I think because it could disappear right, so I think that's kind of the the way I'm thinking about this is we're just looking to establish a broad stroke same protocol, for just you know, trying to to hand wave at some very high level. I got refers, I got artifacts, you can try and use them.

F

um I think that's that's kind of the intent and and if that's not explicit enough, I completely understand that we could work on it, but I think that there are other parts of the spec that are kind of like that, where this wouldn't be like a big sore thumb.

C

I think I'd want to see what Behavior you want to change and what scenarios so that all clients are doing the same thing. So I'd look for this to be a little bit more spelled out than hand wavy and say we're looking for broad Strokes well,.

F

No, not client, no I, don't mean hand wavy in the clients, I mean I'm, so Hand wavy is maybe the wrong thing. I meant signal, flares or something you know some way to say: hey I've got these things and and and not really much detail right that that's kind of what I mean uh you know put put short. If, if a client can say uh what's the version, is it there?

F

It's there, it says 1.1 cool I'm, going to use artifacts and refers API like that is sort of the 80 of the solution for most use cases um you know, could you write a client that says? Is there an endpoint? Is a version endpoint? No, there isn't is the refers API there. It is okay, I'll use it right.

F

You could do that, but the it's sort of the happy path that we don't even have an answer for so every client is forced to do something and there's no way that they're all gonna be uniformly implemented right. Try this try that if this error code comes back, try this thing give up entirely. That's kind of the world that we have now.

C

So it might be more specific in my question, then um Let me throw a scenario out at you: you're you're, looking at producing artifacts um from about your three tooling I do similar stuff on my side. So, if you're producing an artifact and you're doing this against azure Azure supports the 1.1, it's going to come out with a version that says you can do refers and artifacts to this registry. You push that artifact to that registry. In that case automatically you know the user tries to create some artifact. It detects it automatically upgrades it.

C

What do you do when the user says Okay I want to copy this over to the GitHub container registry because it doesn't have that support yet.

F

What do you can you describe this I might be behind here? What do you mean by automatically upgrades it.

C

If, if you're, creating an artifact and you're, creating the artifact on Azure, the the comment here that you're making is that you want to see this version. So you know you can automatically go to artifacts and refers instead of pushing it with the image manifest right.

F

Oh upgrade the the workflow you mean like.

C

Upgrade the logic: okay, I thought you meant like you're,.

F

Actually, transforming something: okay,.

C

um No, so so your behavior changes, so your behavior is going to be automatically saying I'm going to push this as an artifact manifest instead of the image manifest you ship that up to azure and now the client says great, let me ship this artifact over to GitHub container registry.

C

What's what's the workflow there now in the container registry doesn't support that yet.

F

uh I feel like this is a quiz I'm not prepared to answer, but, like it fails, I mean. Is that bad like this? This.

H

Is sort of like okay.

F

But but that's the world, we live in right, we're if we're going to have progress, we're going to move forward, we're going to have new features that are not backwardly incompatible but don't exist in Prior versions.

F

That's bound to happen right, it's not going to break 1.0 Registries, but you would that client would not be able to just seamlessly move that thing over right. Maybe.

C

A better question is: how would you prioritize using new features versus portability of artifacts across registries,.

F

In this context, I think I would I would probably and I'm probably opinionated here. I would probably prioritize the feature over portability, I think in the fullness of time, with 1.0 being available and clients adopting it. We we will have a window and then there might be Registries that never Implement artifact support right. That's, okay, but I, think that happens in software. I think some things stay in a legacy space and and those implementers uh or communities decide to support that.

F

However, they're going to that's my take I, don't know: I bet you other people have opinions, but that's that's. How I see it.

C

I think the reason we're coming at this so differently is because I have the opposite. Take I'm looking for portability, I want to make sure that whatever I create can go anywhere. The user happens to be, but that's because.

A

F

A

This from opposite directions,.

F

I want to clarify: that's not not important to me. It's just not something. I would prioritize over moving forward.

C

Fair enough.

F

B

F

Have thoughts somewhere in the middle agreeing with either of us, not that we're disagreeing, but it is you're right. It's about prioritization.

F

B

You at the risk of taking a stab at it. There were a couple of options that I was thinking about, so one is the simpler one, which is we at least provide a header saying that this is 1.1. Another option is that um we call out a full capabilities API, which will definitely require more design time and agreeing on the fields and properties.

B

um The third item that I think is important is while reading the spec there is no indication of the types of manifest that the registry should support. The first portion of the spec calls are examples of manifest. It does not say it should support index image and artifact in any form. So um these would be parts of the discussion that I would like to have with this group, and how do they? Is it important to address this before the release? I think these are the things that I'm hoping we can talk about.

C

So yeah I was leaning much more for the capabilities just knowing that the finer grain is probably going to be more important for client usage in there, but it's also going to take a lot longer to go through the process of defying that creating that spec, whatever that is, and the question I threw at the end of my last comment. There was: how long do we want to hold up the 1.1 to develop something like that.

F

Does that help with the priority? um Does that help with the portability aspect? I I would be absolutely willing to take a swing at the cap like a capabilities PR like a like a capabilities, endpoint I I'd. Happily, do that and look to and look for both client and registering implementers to to give feedback on it. I, don't think it helps with that, though, right.

C

It doesn't and that's why, when when we were first writing this myological thought process how this would roll out was that we would roll this out in terms of you've got the new refers apis eventually going to be available, but we had the fallback until it was available. We were going to assume that a lot of clients are going to stick with the image manifest until they knew that everywhere they might ship this artifact that all those Registries would get upgraded and then they would make that switch.

C

But the refers API would be on a registry by registry basis, and so that would automatically upgrade.

F

I think that yeah, the use of the verb upgrade is still confusing me, but that's that's okay, I get you now. I might see that differently, like as a client developer. I might because the fallback is called out, um I might just implement it and then just like my client will keep falling back until it doesn't have to, um but yeah you're still left with this need to support your users around future portability.

F

um You know so so, for example, for I can speak in ACR are plans, not a commitment, but our plans are to transparently support both types of artifacts. You know both, like you know, sort of image manifest and indexes that have subject refers and use the tag schema um and then once 1.0 is there we'll support, artifacts and using a more native references, and we would keep you know, keep supporting both of those right because we'll have 1.0 only clients coming on.

F

Obviously so I, don't I, don't really even know like I'm, not I'm, I, guess I'm, not super concerned about the portability aspect I unless there's something where like we're going to abandon people or we're going to break tooling. That I would be really concerned about, but I'm not I'm, not hearing that really.

C

So we grab my train of thought here. The the one comment in there you're making was along the lines of you know the declining support. The new stuff I would definitely make a client that can read um that sees hey. There's an artifact, manifest I know how to parse as a client. I would do that right away. um So if somebody creates it, you're able to work with it, but I would hold off on creating the new one, just knowing that it takes a long time for this stuff to upgrade.

C

um Quite literally last week, I was working with a Docker 1.13.1 install and in case you haven't run across that one in a long while, because hopefully you haven't, but it is kind of the default in some of these kubernetes installs.

C

It doesn't know how to work with the oci index, the the Manifest that we've been depending all the stuff on because it exists, for you know four or five years now, but it just did not exist at the time that client was written way back in the day, and so that's from the client side, where that's usually pretty easy to upgrade a runtime on an individual machine.

C

The thing I see is going to be a lot harder for a lot of clients to upgrade is going to be their Registries that are in-house and a lot of the workflows that I see are they have an external artifact, an external image, something like that? They pull in yeah, no CPU guy that that version is painfully old.

C

um They they pull in the um they pull on the artifact from Upstream into their own registry, and their own registry isn't going to be upgraded for a long while in a lot of places, and so I'm just worried that we're going to break that workflow that if you start creating s-bombs and other stuff Upstream, it's just going to take a while before you're going to be able to import those into a local registry. That a client is running because it's going to take the long while to upgrade that registry.

F

All right, um I will I completely agree with everything you said, but I think I'm still, okay, prioritization wise coming from the you know the background that I have lots of Legacy software supported over 25 years, like I, get that pain. But it's it's a decision and it's okay I mean you know it's kind of okay for in my book, for new features to pay for new new ground um and I I really do I. I. Think I would like to make sure that we try to like separate these two concerns.

F

They're both valid I would like just to say, like I. Don't think the portability thing relates so much to just having an endpoint or capabilities like so I think I think trying to tease them apart is.

F

um That's good, no, it would so Tiana just just to be funny. 113 was the final destination for the Solaris Port I did speaking of LTS and the 25-year yeah, so that that's that's the real joke. um So uh if anybody was gonna pick up, LTS yeah um and it got backed out just to be clear, um yeah I, don't know like do you.

F

Do you think it's fair to say that we should separate these two things and just kind of try to talk about them in in different contexts, because I think there's one as like. You know portability best practices and client development guide and another one is: can we have a sane way to determine what version the registry is or its capabilities.

C

So I think the need to do that difference of cloud behavior is kind of driving the first conversation. So if we get rid of the need for the client to make that change in Behavior I think that we eliminate a whole need for that whole discussion. That's why I've been pulling this thread a little bit so just to be clear on my my client use case out there. It is when they ingest this stuff. Their registry isn't upgraded, but their clients are their clients, can absolutely use an s-bomb.

C

They've got all the tooling out there, they're building the secure Supply chains. They just don't own the registry server, that's a different part of the company that servant can be upgraded for one two three five years, however long it's going to take them. So if we push the artifacts in a portable way, they can still run a secure supply chain, pulling an s-bombs pulling signatures validating all that stuff which would be broken if we do it. This other way. What.

F

So why would it be broken.

C

Because they can't import an artifact, manifest they're.

A

C

F

Oh because they're right, no no I mean the other way like so so what this implies is that a register will move to 1.1 and drop 1.0 support or the ability for the fallback to work like like that. If you create yeah.

C

If you're creating an artifact yeah and the.

A

Creation artifact.

C

Sees sees the registry supports it. Yeah then.

A

F

C

No longer portable to an older registry right.

F

If, if you create a 1.1 artifact right that and that's just to be very.

C

Explicit vendor oci.

F

Artifact right, if something, what whatever a client pushes an oci artifact according to the 1.1 spec right that is not portable to a 1.0 registry, full stop right, like that. We agree on that. What I would be concerned about is pushing things to a 1.0 registry that cannot be then pushed to a 1.1 registry 1.2 into the future. I want those artifacts to not be stranded in the past and to be carried forward.

F

I really am not concerned, and I might be the only one. So that's why I'm asking for other people's input like I'm seriously, not concerned about a new feature not being portable to the past? That's never a thing that we've ever done in software right. So that's the part that I'm confused about so just to be clear portability, very important, hopefully to everybody, but portability of older artifacts forward is kind of the Focus right. It's never about making something sort of look like a future thing and then moving it back right.

F

That's kind of the thing I'm getting caught up on is like the fallback. The tag support the way to like kind of mock up an artifact s.

C

F

C

My understanding, though, is when you're creating your artifact you're saying. If my registry supports it, I'm going to create it with a newer version, I'm going to create it with the artifact manifest. Yes, at that point, we're no longer talking about the case of Ukraine on Old registry and try to pour it to a new registry, we're saying you've created on new registry and now all the old Registries no longer support a copy. This to that's.

F

Exactly right, yes,.

C

And and that's the use case that I see happening a lot in the field.

F

Right but I think that's what I'm saying is that I personally am okay with that. So what we're saying is future thing can't be brought to the past past. Things can be brought to the future I.

C

F

With that, but.

C

That future thing is useful to people that are using the past registry, because people are using the password industry have a future client I.

F

I, get that like I, totally understand it, but like you, we can't I, don't know how we change that other than we. Never. We never move forward with Native support and we always just do fall back forever right, like I, just don't I.

C

Don't know yeah the approach I've been pushing for was just hold off on pushing to the newer version of the Manifest until you're comfortable at all the places you might copy that artifact to in the future had already been updated.

C

And it would likely be a user side switch. It would likely be something that the client itself will probably default to for a long while and then at a certain point in the future. You would say: okay, we're we're comfortable that enough time has passed, that we think that everybody that's copying. These around is going to be upgrade on new registry, we're comfortable using the new, manifest type, but I saw a whole lot of hands pop up, so I think Michael was first.

F

I think it was disha.

G

Yeah I think so um so um uh the risk of sounding dumb with the like, maintaining multiple versions over years.

G

um Here's a scenario so Suppose. There is um like a registry implementation that is only like that gets newly developed by somebody um and it supports um it supports like the newest, like release. 1.1 somebody sees release 1.1, they see the spec, they implement the registry according to the spec, a client that uh is written for that kind of registry. Would um you know just easily say if I'm talking to that new registry like at this domain, then I will um you know, use this method of updating the of using s-bombs or whatever.

G

But if I'm talking to like uh oci conformant 1.0 registry, then I will do a fallback and that's the typical workflow I would think from the client side. But that's all that's all I can imagine in my head, I I of course, like you know, uh Docker is the the heavyweight kill. So I am not really sure. If that is um that's an issue that we should be concerned about, my feeling is that organizations.

G

Seem to set up their own internal Registries and um they'll just use distribution, um and if there's a newer one out there, then they'd be.

A

G

We could try that as an experiment.

C

I think uh when Jesse you're on the same page and the yeah.

G

That that's why I'm wondering like uh what is the scenario where a registry is um like at the current state, which is I, don't know uh 1.0, plus whatever it was before, oci was ever created and then they had to you know also also support. 1.3. Would registry implementers have a problem implementing that right now.

C

The scenario I see is that clients don't pull images directly from Upstream to their production clusters. They pull those images in internally. They run it through a vulnerability Scan. They do an internal Blessing about an image or whatever they're going to do, and then from their internal registry.

C

They run everything against their cluster, and so the cluster policies might want to say make sure the stuff is signed, make sure it's got an s-bomb make sure it's got all the secure stuff that it wants, but their internal registry can't support that if the artifact itself is shipped with the artifact manifest instead of the image manifest.

G

um So I'm having a hard time uh picturing in my head, whether that is something that we care about, like what the scanners do and um how scanners, how scanners interpret whatever you store in a registry um is that is that, like a I understand that there's like a whole like software security ecosystem that is around, you know scanning container images but like if, if it scans something- and it says it, I I, don't know what this is. It's a document I don't find any vulnerabilities in it shouldn't that be fine.

C

If you have an s-bomb from Upstream a lot of times, they want to import that s-pomb as well, and so they they want to pull down that data. They want to pull down the signature as well to say this aside from someone Upstream, and so they can generate their.

A

H

Internal scans.

C

But they can't copy that s-bomb if they generate that s-bomb with a non-portable format.

G

No uh so who I'm the way I'm thinking about it is somebody like suppose, a client generates an s-bomb uh using uh you know whatever s-bomb tool, and they push it to a registry using the fallback method. With the tag reply, we're doing.

C

This we're looking.

G

C

Microsoft puts their stamp on something. That's pushed up to Azure azure's got the 1.1. It's got the new artifact manifest, so their image has here's my s-bomb here's, my signature. Here's all the details, all the digests match, but it's all using artifact manifest if I'm running my own internal registry, it's a 1.0 registry I can't import that into my registry.

G

But is that a problem like can't the you know? That's that's a client issue and and I feel like as far as client implementations are concerned, that's kind of an easy thing: it's not like really you're, not standing it up, you're, not um you're, not maintaining it. It's not like exposed to the Internet it's kind of sitting in some place and going like oh I'm, just gonna make a call uh I feel like the registry has like more responsibility and like taking.

G

Taking care of its artifacts the way it wants to take care of its artifacts so suppose the registry has like is only the 1.1 uh and it's like not supporting this extra tagging thing or did I get. Why.

A

G

Misinterpret so a registry that implements 1.1 will automatically be supporting 1.0 is that right.

C

It would for that maybe I should draw a picture. People like my pictures.

F

Don't they more than you know, muted Michael, I.

G

I, like pictures Brandon, please go ahead and draw pictures. I still um yeah I still feel, like you know,.

G

Maybe I'm more uh more on Jessie's side here, like I, feel, like other at least like you know, clients have more our client implemented, implementers have more latitude than registry implementers.

C

I may take a second do some drawing I'll turn it over to Michael for a second and then we'll come back to this.

I

Is my mic working now I tried to say something during that, uh but I'm not going here. No nerd um I think I still think that there there's sort of two separate issues here. There's there's the question of whether we should make it easy for clients to understand what a registry supports and then there's this question of like four people who are Distributing public artifacts should they use manifests, which we think is more portable, or should they be pushing artifacts as subjects and I I.

I

Don't think that it's fair to say that, because if you want something affordable, you have to use an image. Manifest means that clients should always just place. The image manifests, I think there's a there's, a lot of use cases where portability is actually.

A

um If you're seeing your own images.

A

G

Don't don't need Michael? Your audio is like slowly going away.

I

Can you hear me now is that better got like three microphones? That's.

A

I

A

I

Like I think I think my question is: is just there's a lot of there's a lot of people who are going to push images and sign images in private Registries and never Port them anywhere and for those clients? Why should we make them worry about portability?

I

uh Why can't we just have a way for clients to know you know. Does this? Does this registry support the new, the new stuff or or not.

I

I, don't I think it's it's a it's an option for people if they want to put things into compatibility mode, but it's not necessarily A requirement.

C

All right that was long enough for me to draw um the scenario that I've got and I see this a lot. It's. It is not an isolated scenario. um Is that a producer out there? Sorry can we just.

I

Not every use case involves portability. I I just want to answer to that question before we before.

C

I

Move on to this.

C

So if you're producing to Azure and everybody's pulling just to azure, then yeah, if you upgrade that it wouldn't be a big deal.

I

And and I think I mean most artifacts just get pushed to private registries and we never see them like they're, just in someone's private it registry somewhere they're verified when they try to run the image and and like they, never see the public Registries at all. So so, what's the so the question that I thought we started with was: can we have a way of determining what a registry supports you're saying if we want portability, if we want to distribute this across six different Registries, we need a compatibility mode.

I

I get that I'm saying why can't clients have a way of for like default normal. You know your sort of day-to-day artifacts just pushing to the registry and the format that the registry supports.

C

So my push is: what's the need to jump so quickly to a different, manifest type? That's so few Registries out there support and yeah get. Maybe the big Registries out there will jump with support earlier, but I think there's going to be a very long tail of a lot of incompatibility out there, and we already have we've got today a manifest that will work across everything.

C

It's it's already out there. It already exists it just we're forcing a change in the Manifest and there's not a value. You know, there's not a value. Add there's not a requirement to use it.

C

We're just doing it because it's the new feature we want to have it and the scenario that I'm really worried about is that we're going to create this scenario where everybody out there that has this artifactory 1.0 can't pull in base images Upstream for everything, because all the signatures, all the s-bombs and everything for all those images, they're importing for all the tools they want around their cluster they're written in a format that they just can't use, and so quite literally, I see this kind of scenario very often out there, and the solution is real.

C

Simple! Is that you can push it with an image manifest instead of the artifact manifests and everything just works, and so that's, where I'm getting to the question of do we need to have this discovery automatically out there so that we can support a scenario where we just automatically change from an image manifest to an artifact manifest if there's not a real requirement to do so. So that's that's the question I'm throwing out there, knowing that, knowing the downside, so I didn't have the attendees up so I, don't know who raised their hand first.

F

um It's still Michael and then just me as far as I can see Michael you all set I, think so. Okay, so I guess, for the sake of time, like I I appreciate the drawing I, don't know that I didn't understand this use case. I also want to be clear. You got a lot of registry implementers and and kind of um client software Professionals in the chat right now, like we I think we all get it like. We all see this.

F

um Nobody disputes that this is a thing that will happen.

F

I think the question is: does the community want to move forward with new features right and so I would posit that spec work is always like this I did this in the storage space for about 10 years, and it's always a weird thing where you're like well we're gonna, have you know, client confusion and we're gonna put a new thing out and not everybody's gonna want to use it and it just kind of comes out in the wash over time, because, ultimately, these are client decisions, client software decisions, software Stacks providers, they'll all make decisions to me, applying my sort of storage, greybeard hat I, look at the registry as the storage layer right, it's not even client server.

F

It's a disk and I worked a lot in in storage back in the day and we added new features and whole new protocols over time, and so our rule of thumb was always what I had said before. We must make sure that artifacts are portable forward.

F

That is a mandatory requirement on Registries. We cannot abandon customer data. We cannot abandon users artifacts so I. Think in in that spirit, I I think I would like to write a PR um one or either a version or capabilities on point, and in that I will refer to this concern and I will try and say you know if we go this route and Brandon I'm inferring here that the the worry about such an end point is that it will promote adoption. It will make it easier for clients to adopt uh the new features.

F

That, to me would be a goal. uh However, there is a concern, and so I think as part of anything that introduces such an endpoint.

F

That makes it easy for a client to say: oh, it's 1.1, let's do 1.1 is that that client implementer must be aware of the portability risks that they're taking on for their users right you're, saying if you're doing this, it means that if they're running a 1.0 registry they're not going to do it I think that should be in the scope of a PR and I think then we can see if more voices join the conversation too, and you know if, if everybody's okay, with that, that's I, think we could put a pin in it.

F

Unless we have more to talk about um and then I just have a question.

C

I think kind of the comment you throw in there is as a client decision. They can just upgrade their registry. um They often can't they.

F

Often no I I didn't say that I meant client as in client like client software. The.

C

Producer can decide not to create something new.

F

uh This so this would be whatever tool the producer is using that implementer needs to understand what their, what they're choosing when they choose to use 1.1 they're moving into the future. So.

C

That's what I'm saying the producer doesn't choose 1.1 the producer pushes their registry and if the registry happens to have upgrade last night, suddenly those artifacts are no longer portable to all the places they were before.

F

So I think that's something that we can talk about in, like a in a PR, potentially we're talking about something like no automatic fallback like maybe you want client software to like always be implemented as a mandatory fallback, which again would be a client decision right but like as far as the storage. As far as the storage system goes, this is always going to happen and I know. This is the first time the oci is introducing new features, but like we're going into the future, we will leave the pass behind.

C

That will keep saying you're worried about. If you upgrade this, you want to be able to support the old stuff. So if you upgrade from measure 1011, you want to be able to support the old stuff, that's a guarantee. We we put that in the spec. Nothing in this has changed in that side. It's the flip of that of saying, okay, once this goes to 1 1 everybody that works with this is now forced to upgrade whether they wanted to or not.

F

Nope uh I think the better way to say it is. If you want to bring that artifact somewhere else, you better make sure it it supports 1.1. Otherwise, it's not a destination. So it's not.

B

F

Anything to upgrade.

B

F

B

Give sorry the moment for them to probably them to actually just they make a call.

F

Hey anybody can speak, it's a there's, a lot of yeah there's a lot of people on this call.

H

Thanks Sanjay um quick question: according to this diagram right, so let's say: if there someone pushes an image with a 1.1 um on ACR or Docker Hub anywhere right and if they're, older Docker clients which still are on 1.0 they're gonna, not be they're, not gonna, be able to pull that image. Is that correct or they're they can still be? They.

C

Can pull the image? The image itself is still going to be the image manifest, but they can't pull the s-bomb and the signature and stuff like that. But that's okay, if you're pulling directly from here, because the older Docker client doesn't know how to pull an s-bomb or a signature, it's it's only when you go from here across to here and then to something that needs that s-bomb.

H

Yeah gotcha, okay, sorry, that was my confusion.

C

Great question.

F

I, don't think it can hurt to open the pr, so that's kind of what I was looking for. It's just. Do we and and I can just make a guess at it. We can talk about it there too, but we do we like a version or a capabilities endpoint just like generally quorum.

F

Both neither neither Yeah well yeah I mean you can just keep running at 1.0. That's what I have to say to you. You just keep running one we'll support you forever.

C

As long as the clients are out, there still run Docker 113 on me.

F

It happens and, and what do we do, what do we do when they're running a 2.8, Linux kernel, we say: oh, my God, please update. Maybe they can that's. Okay, um okay, sorry is Nisha or Nisha. I want to say it right.

G

uh Nisha Nissa.

F

I was doing it right, cool all right, so I I will Point uh a PR out of capabilities, endpoint proposal and we can just talk more about it.

G

Yeah, that would be awesome. I'd like like to see how that would work.

C

And do we want to get that in before we release 1.1 foreign.

G

Yeah, it's I, don't know how much of uh stuff needs to change in order to stick in a capabilities. Pr oud. So.

A

F

G

Big then it may not go in before 1.1. That's.

F

The worry, I'd have and I think implementation. Wise I mean none of it's rocket science, but for Registries uh version endpoints a lot simpler than capabilities.

F

That's why I started with version, but we can talk about it there we can have maybe either I don't know but uh yeah, maybe that's actually. Maybe this is a discussion. Do we do discussions on the repo and.

G

We can do it. Yeah I think we.

F

Can do an issue.

G

I think there's a discussion thing, but uh they're.

C

Easier to miss.

F

Issues are usually more obvious, maybe I'll do an issue and we can discuss more and then that can lead to a PR and in the issue, I'll make sure to mock up what that would look like for both. Does that sound good to everybody?.

B

Is there a problem reusing the same issue, because it is versioning data for one, not one yeah.

A

B

Whichever you prefer I'm on fire.

F

I, don't know that's 365 right, yeah yeah, but I'll just do it there and then that could lead to a PR. That sounds great Sanjay. Thanks for the reminder.

A

C

Until next week,.

F

Thanks everybody thanks.

A

F

For completing.