OCI Weekly Discussion, 9 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OCI Weekly Discussion - 2020-09-09

Description

Weekly OCI developer's call from 9 Sept 2020. Agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#September-9-2020

A

P.A cuddle.

B

I mean it's bad enough. We make these. You know we see these goofy things online about people doing zoom club they're, not in the tech industry. Hear me.

B

C

Much right what it is, if I restart my laptop, it doesn't pick up the microphone for some reason. I have to unplug it and plug it in again and suddenly it's okay, there was.

A

There was a series of kernel updates that did not take nicely to my usbc dock and the same was happening, but now it's magic.

A

C

That yeah yeah, I could talk about linux problems for a long time um anyway. What I was going to say was what happened. Was um I watched the video where darren shepherd talked about his issues with multi-axe, stuff and yeah? It kind of made a lot of sense to me and I kind of approached it from the point of view of writing a registry implementation and what we could do to help now. I did like write a proposal and I think I've linked out there.

C

Maybe we can go through it briefly, but the problem with the proposal is that it comes from the point of view of what can we do without changing anything?

C

Okay, so it's like what could I hack together, like in an existing registry, if you like, um whereas a better solution would be to address it, uh you know within the standard and the client a bit better, um but that being said, uh we can quickly go through it. uh Is it worth me sharing my screen and open the document there or yeah sure, and is somebody banging a bowl in the background? I'm.

A

Not sure if that's.

D

I'm actually gonna guess that's more like a cereal bowl than a bulb. You know.

C

Okay, um so can you see she might, can you see the screen yep.

B

And it does help just to kind of walk. Have you pointed things over.

A

B

A

C

Oh yeah hang on. Maybe I can make my just sure. I think.

A

I shared the window.

C

So hopefully I can just do this yeah yeah yep cool um yeah, so it's actually a pretty simple idea. um All is, is um that I have I mean I wrote this up very quickly, so I came with a stupid path. Name, um obviously, better idea to use something different than manju, but basically idea is rather than the client being responsible for building the oci index or the manifest list or whatever you want to call it. um We can place a burden on the registry, um so all is is we have a certain path?

C

And that includes the platform and the os- um and I also you know this afternoon- I was thinking. Can we get that automatically from somewhere else?

C

But I don't suppose we can because there's not no shame manifest, but anyway, so the idea was, you do docker push to something like amd 64 linux, then actually, the name of the image you're interested in um and the registry itself will take care of bill's nosia index and placing that test test multi and if one already exists, um it'll update it for this given architecture or add a new one, depending on.

C

What's the correct thing and that's pretty much it so the idea is after you've done that you can then just do a pool from here and that will be like a multi-arc. You know, that'll be an ocean index. Does that kind of make sense.

B

Yeah it does it's there's a couple of interesting things about that. Come up, I mean. There's lots of challenges too, but what's interesting is the um you've accounted for like how do you deal with the path that I want it to be under, but I want this tooling to be underneath it that says you know the mundra tool. um Take the amd64 and update that manifest so makes sense.

C

Yeah I mean it is, is frankly a bit hacky, um it's just a proposal um yeah. I don't really have too much more to say, but it's really quite quick, um yeah one thing we could do is try and make it. One thing that is a bit frustrating is that we don't have the platform and os, and I guess actually maybe actually part of like the should that be somewhere else as well. This must have been discussed other oci um stuff, like the manifest and stuff.

C

What do you mean? You don't have it um well, it's not in the manifest right. It's only in the index.

A

Sorry, I I now I see what you're saying so the manifest well, the almost whatever recursive the manifest list or yeah image index you're right. Okay, sorry name change! Yes, the image index has the pointer to the you know, with the platform os fields so yeah.

B

But doesn't I thought a manifest directly? Has it in its config object.

A

You have to look you actually you have to you have to you have to fetch the um so. If you get an image index, manifest list it'll point to an object. That's a generic manifest! Like you know, we we, I guess we could add an annotation there or something but right now. If you want to figure out what its architecture is, you actually have to go fetch the config json object and then marshal it out. Yeah.

B

A

It's not it's not none of that none of it's a straightforward operation, except for the manifest list, but I.

C

Could actually get rid of this thing, because I could just like open the config object and get rid of this plot from a western.

A

C

A

An extra hop and some marshaling but sure.

C

Yeah, well, it's better than the client haven't. Do it. Although then again it's maybe nice that they're explicit, because uh so they know I don't know.

C

I was about to say it's really nice being explicit, because if you're pushing to this path, you clearly want to build a multi-arc image. So if this doesn't match a thing in the config, it would give you an error. I don't know, and the other thing I was going to say was I guess we could build. You know I could build a docker plug-in to make it a bit nicer. Potentially.

B

Is phil here um the classic problem that we have in addition to spec and other ones is um there are lots of they're different clients, but there's not too many different clients and we all use them for various different reasons. um Obviously docker client container decline, builder, buildex and so forth. The the bigger problem you have with a change like this is it's most. Registries have different, have unique implementations for various reasons, so you basically can propose a spec. You could even provide some amount of code.

B

If you you know, did go, you get some amount of registries python, maybe another's whatever, and then it then it really comes back to which registries support it, um which I'm going to turn to vincent over here and say where's the capabilities thing that you call it somewhere else. You call it because we really really really need that. So the registry is considered.

A

B

E

A

Kind of like that was the the idea of saying you know if there was extensions or features or whatnot the feature flags kind of thing, but.

B

Because I totally agree that having this on the registry certainly simplifies things because I think it was darren was bringing up that you have different build systems that are building different platforms and architectures at different types, and it's really hard to get a good quorum across all of those to know. When am I done? When do I build the index um and then there's you know various race conditions and other things that wind up happening when you're updating an index from outside so putting it in the registry certainly helps consolidate that in one place.

B

The problem is that you need to be a registry to implement it and certain features registry as well, because they, you know, there's a business and need around it for, for various reasons and others like yeah. That's a good, tooling thing whatever um and then there's the other side of what phil's been doing is basically doing better client tooling.

B

That says that as long as registry support index, which we're seeing more and more do, then um it just works, but then you're back to the other problems of how do you know when all the images are built?

B

I think the the larger question we have is this is coming up in some of the notary. Conversations is, do we have the right model like is there's something else that should be done like. If I push the same tag, I don't know I'm just totally. I hadn't even thought about this. If I push the same tagged reference to it's diff, it happens to be different, architectures to the same repo as an index automatically created.

B

um I don't even know what that means honestly, but it's like we're dancing around these two problems of registry implementations versus client, tooling. You know if we were to crack this because there's no easy answer. What would the what would it look like? Because I think you were trying to say a dream like? How do I do this without changing anything? It's like okay, yeah.

C

Yeah I mean I only came out from that point of view because that's what I could do if you see what I mean yeah, I'm gonna stop sharing for a minute. I think you've all seen the document.

C

There we go um yeah, so that was about it. um I don't know.

C

So what were you saying about um a better representation? Are we considering uh replacing those oci index or is that a potential consideration.

B

Well, anything's a potential but yeah there's. I don't think momentum around that. There's we are on discussing enhancing index so that we have the config object on it. So we can figure out what is the index represent? Is it a multi-arc manifester? Is it a uh a signature? Object, for instance, for the notably two work or is it a c nav for things that you know that they're doing?

B

I think the the challenge that we always face is how do we enhance without breaking the ecosystem um so like one of the we were talking about signatures are basically just another manifest that you want to reference another another artifact in the registry. Well, that's exactly what indexes do so, that's why we went down a path. Maybe I had a manifest that knows how to reference another manifest, but that's a pretty substantial change that would break existing kind of lines.

C

Yeah yeah and there's a multi-hop thing. You talked about a minute ago, yeah.

B

C

So I think that's the.

B

I guess what I, what do others think like there's some people that do represent other registries. You know we would would love to see the enhancement, but as we've also seen that unless something is more available across multiple registries, you know it's hard to get good adoption, because people are getting getting images from different registries and moving around for all kinds of best practices.

B

So we kind of need some consistency, or at least the ability to drive consistency. That's why I really like vincent's proposal is like here is the enhancements that this registry supports and when somebody comes up and says hey, why doesn't registry foo support this feature? Because all the other registries do- or I have this customer that needs it whatever motivates that company to do it then there's a spec. They could point at and a capability they can add and then there's custard to them to drive it.

A

Okay, so it's good feedback of.

A

A

Proposal there and now I'm trying to remember while we uh that last call that I had with like jimmy and josh and j uh derek that we thought about scrapping that um extensions proposal entirely was just uh I forget the details. I'll have to look back. I thought I'd commented on the issue, but I do there is a space for those kind of feature flags.

B

Yeah, we definitely need something.

A

Oh, but I don't want to get sidetracked too much. No! No! No! That's good, though, because it's the same kind of stuff as far as like, if we fold notary in and I have been absent from all the notary- progress progress in the last months, but that was the main use case for it, but this would be interesting as well yeah or anything.

B

Like this, but like even the conformance test that josh has been driving, it's, like you know, the the conformance tests are pretty getting. The infrastructure in place was really hard right because we found all the kind of nuances.

B

But the next question is great: we can push holistic catalog in something registries are so much more than that, but we don't really have anything that says what those other things are. So if there was this list of extensions and then registries could light up, hey yeah, I do support this and whether it's peer pressure or customer driven or just awareness to know what's available.

B

um It would be great and that's you know I had. I actually had sorry, I'm gonna take another change. The the interesting thing about multi-arc index is trying to figure out. Where is the need like how like, if you're, building, java.net, debian, sorry java.net, you have some runtime images or you're shipping, some software? I have an accounting software package for some reason my customers want to run around linux or windows.

B

I would want to ship that software as a multi-arc image. I want to ship that run time as a multi-arc runtime.

B

That seems like a pretty small percentage of overall customers that are building images, and you know we tend to build tooling for the masses and uh and there's always that there's a detail of ecosystem is there some? Is there a larger pool of this that I'm missing of? Why we want to you know: how can we get better tooling for multi-arc images, or do we have enough and the community that's building them is doing what they need.

C

um I think harlem is going to get more and more important. I think that's the main one.

C

Sorry, what's going to get more important.

A

Arc 64 and such oh.

B

B

So it's, but those are the same products, the same images that are already built in multi-arc you're, just going to add another one to it, so they already have to deal with two or three. So adding a port just make it yet another recreating index. So now we have to add one more to that index list.

B

Are there? Is there a growing need of customers that need to build multi-arc index that we should invest like the signature? Stuff is not a multi-arc index right? It's it's definitely going to use. We believe it's going to use index, so we definitely want index to be around correct.

E

It's a different.

B

Type of tooling than what we would use for multi-arc. So I'm just trying to get a sense of what's the opportunity for multi-arc indexes and what's the level of tooling investments that we should think about.

F

uh I would say that the embedded and iot community would definitely be interested in building multi-arch. I mean they've already started looking at containers to run on raspberry pi's and things.

B

So even it's a in the iot community there's already like pretty there's so much distribution of images. It's not just hard software packages, it's just like, even within one company, my custom app. I have multiple architectures that I need to build.

F

Yeah, I would say like for edge computing. That's fair, there's, definitely a need over there. They're already there's already like work uh being done on edgex. I think that's where vmware is involved is edgex foundry and they definitely build containers and put them on raspberry pi's.

B

Cool, that's a good point. I I hadn't thought about the iot multi-arcs now.

B

So did you adrian, did you have any more conversations with phil or darren on what you were thinking about some next steps.

C

um Not really, basically, I mean I did send it to darren he's like um you know he said yeah. It actually sounds pretty much like what he was thinking, but I didn't really hear much back after that um I was considering. I mean it should be fairly simple. I was considering just doing like uh you know, adding a proof of concept endpoint to trial, to register I've been working with, um but I mean nobody really uses trout, so I don't know how much feedback I get on it.

G

Yeah this is this is not dissimilar from the idea I had of which is basically the idea that steve just pitched to just have something. My idea was a proxy that sits in between you and the registry. You want to push to when it when you push an image to it, it checks the architecture and updates a manifest list on the actual on the actual registry. But the hard part there is that the image config doesn't have enough metadata, like things like variant, are missing from the image config.

C

G

Yeah, so I love this idea, and actually I I would make it bi-directional, um because there are some clients for which specifying the platform that you want from the manifest list is difficult or impossible, like even in docker. Specifying the platform that you want to pull explicitly is an experimental feature. It requires the experimental flag enabled on your dr damon today.

A

Which most peop most people don't run.

G

Right yeah, so it in in official images, especially we've. Initially, it was an implementation detail that we were pushing each architecture to its own organizational was terrible. It repository up being a useful feature for our users to be able to explicitly override the daemon and say I need this particular architecture's image.

G

So my feedback on this proposal would be. I love it. I would implement it as a registry proxy and um I would change the platform specifiers to match the the platform specifiers, that container d uses where it's os art with an optional slash variant.

G

You have to make sure to extract the os version for windows. Images too, which is in the config.

F

So I have a question about that. uh If we were to choose to, um you know, have have different paths for different platforms. Would that be something uh in the spec like how to resolve those paths.

B

When you say paths, are we talking about the name space of the image that you push.

F

Right, I'm sorry uh yeah the name spaces so right now uh I am trying to figure out how to implement the namespace resolution from image and tag to the actual paths and they're different for different registries.

F

This would complicate that if registries get to say like okay, our our uh whatever x86 path is here and our arm path is there and we have our own special resolver. uh You can pick and choose. Would yours with the oc aspect, then include like a spec around pat namespace resolution.

B

So having gone through this with acrmcr.net and our integration with docker up, I can tell you that if, because we've seen people do this, including some things, the kubernetes images that have uh they build different architectures and different namespaces paths um to go. That path basically says we give up on index multi-arc index and it does get complex because different registries do implement different pathing capabilities like in acr. We actually don't limit how many slashes you put in it. um The docker client does a 256, which ones are being really long. It turns out.

B

um So I I would and that, but not all registries do that, and but I I think I would love personally, I would love to see us fix.

B

The index problem then try to exacerbate it with multiple name spaces, to try to figure out the architectures that that would be my personal opinion like because we have done this like there are microsoft ships, a number of multi-arc image types, whether it be net or java, or um even windows, with the what it does its variants, and it is a tool and painting, but it does work and the that's kind of why it's going down the tooling experiences and where the investment for the consumer, the clients just work generally, there is this.

B

There is some problems where the a single docker host can handle multiple architectures. I'm hoping continuity is going to make that better, um but the consumer, tooling of all this is, is in a good space. The problem is the authoring, tooling, isn't quite up to par, which you know a lot of times. That's just the burden of the mass problem.

B

So anyway, that would be my two cents. Is that, let's not before we give up on multi-arc index and go down a pathing place, a pathing name, space thing? What can we do on that? And for the sake of time, what I was going to suggest, since this is the wonderful world of open source community is there is no it's not like you're, making a pitch to a particular company named after something that would just convince them to invest in all the tooling um that's kind of evolved.

B

That's kind of the purpose of the open container initiative is it's vendor. Neutrality is, uh would love to see a group of people that are really passionate about the space and keep on championing it and bring a proposal forward so like adrian, if you can get, I know, phil has been invested in it. He's got some tooling around it and darren.

B

If you guys want to keep on churning on it and make a and say hey, this is what we'd like to do and build some consensus around it that that would be the best way that I would suggest going forward.

B

And then it's just a choice like? Is it really worth it to you, because I think there's something there. I definitely think you know there's definitely a there. There.

C

Yeah I mean to be honest. I see this proposal very much as a as a stop gap. um I'm not sure what the right solution is. I think it comes back to your point about um indexes and stuff.

B

But I would focus on what do you think the right answer, like we had this conversation quite a bit in this in this forum of there's the right way, but then there's the way I can just get it done and there's a certain point where we wind up with just a junk drawer of stuff, because we keep on hacking things in, I think so far.

B

The group has been really good around acknowledging what the gaps are and like we went through this with artifacts like we want to be using the config object and we went around a lot of different places and actually it kind of works um where there's other stuff with index. But we want to add the config object. That is a change, but we're figuring out how to make the change at a in a minimally an impactful way with a higher value.

B

So I would, as opposed to like there was an easy answer, just use annotations, which to me was a total hack and I hated that idea. But details are not important, so I guess my point is I'd, encourage you to come up with what you think the right model is um think about what the implications are for the existing clients that would be interacting with registries or pulling artifacts from a registry, and um I'm happy to work with you on. You know some of the stuff that we went through, but what?

B

What is the right solution? And if that turns out to be the right solution and it's worth the investment, then I you, I think, you'll get support from everybody here.

C

Yeah I mean one thing you could do is just to make it a bit cleaner is, have you know past if you want to pass it back and get the config? Have it somewhere else? So you'd have like a you know in a post, have the os and arc details or have it in a. I know. A header wouldn't be very good, but it's not very nice, putting it in the the url right yeah. You sort of need a new api here. Yeah.

B

And we've been doing some stuff around using headers and you'll, see some subconscious into the distribution, pr notary that um we're going to pass the media type in as in the header, because the encoding doesn't really work anymore. So there are some good places to do that.

B

B

All right so um awesome, I think yeah we're definitely interested. I think the big question thanks. Let's I'm happy to work with you offline with you and darren and, however you want to do it. I think the big question you have is: is it a client tooling, which is what phil's been doing or is there a registry side that you know both of them have their pros and cons? Yeah.

H

B

H

With having a multi-org api for registries,.

B

Yeah um all right, I think then who's next here.

B

Set comp thing.

I

Hello, oh yes, I added this under agenda. Can you hear me welcome yeah cool? uh Yes, because I'm trying to add a new feature in uh fancy and in crm time spec. So I put this document describing.

I

What it is about and a diagram about how it will work, so maybe I can go through that or.

I

I don't have a god to show.

I

I just started work on that, um so this is about psycho and uh in there is a new feature in the linux kernel to instead of this heading statically, to accept our object, a system call is to defer the decision to to another process, and so it's on the message to another process, an admin that will make that is about to make the system call on the bear for the process in the container and that's something that nxt is doing.

I

They are pushing the code in the kernel to support that and uh now nxt has this support as well. So um what I want to do is to do the same in run c um and it needs some change. Some updates in the oci spec for that.

I

So in the document I put some links to the linux commits that are necessary for that it require a very recent linux channel for the last features like linux 5.9, which is not released yet on other things too.

I

um What I would like to do is is not tied to a specific feature. Yet there is different use case for that, for example for lxd. What they do is, for example, support months.

I

Usually when containers are not privileged, they cannot mount anything, but there are use cases where they want to be able to mount some um fine file system like tmpfs or park fs or whatever, without giving more privilege, and they use a seg comp to to catch the mount system color and send it to the adjust outside of the container that will perform the mod on the continuous behalf, and there are other use case with a ppf system call on.

I

So I don't want the different different use case to be tied to oci or currency, but to provide a mechanism so that people can write the oci, config.json and call an external agent to do a system. Call on the behalf of the container for specific use case.

I

I don't know if actually that's something that other people in this school or elsewhere have tried to do pharmacy or is it if not not.

A

I

A

Think it's I don't. I don't think so I mean you, don't you don't have a lot of run scene maintainers on the call tonight but or today, but.

D

A

General, I don't think has has really surfaced.

B

Okay, so alvin just um it looks super interesting.

B

It helps so what we've been doing with the weekly calls, because they're weekly and there's just completely random content from week to week, meaning that just it's just different groups, so we've been trying to make sure that we get the agenda up beforehand um and I I try to send them out by monday at the latest and amy reminds me and says I'll be having this video or not, um so that people will know to actually come to the meeting this week.

B

So like I didn't, I don't know when you posted, I missed it until I just saw it now. um There's a dev, alias uh it's a debit opening containers. I just typed devon, auto complete.

A

B

um If you just send this information there, and maybe let's say two weeks, you know come back, uh you might be able to get the folks that really dig into this spot to kind of call and have the open discussion. Because, like I said I was looking- and I don't know mike and I'm trying to think of who else here would actually.

A

Tiana tienen might dive into this one also if he gets a wild hair, but.

B

Okay, yeah, that makes sense. We all have wild guys these days. If.

H

It wasn't ssc comp, I'd, be really excited.

D

H

On, if you go look at github.com container d, slash nri, there's a a new interface service, that's being promoted as an alternative to the hooks process uh in run c, the um you could probably do an sec cop, you know uh plug-in in nri and it would be fairly interesting as a way to model how to do this. I think um very similar to what you have, but you wouldn't have to use autolog right.

H

You just install your plugin and vote right. Then we get run.

I

Can you give a link to the github page you mentioned.

H

Yeah, it's just container d. Slash nri is the uh is the brand michael crosby's working on it and I'm sure he'd be very welcome to have more people testing it out right, adding any new types of plug-ins, just just a thought, just a thought there, um because we had talked about not not just a few months ago um for the cod stuff, where we're going to add additional device support, we were going to do it via hooks process.

H

um That's bernal and morale p and a bunch of the intel guys and nvidia, and all the other kubernetes cod guys and michael sat back a little bit and said: wait a minute. Let me do an interface okay, um so you would take a look at an nri. uh That's the uh node resource interface and see what you think. Okay! Well, you know I'll put it in the chat.

I

Cool thanks: I got that.

I

Okay, yes, it makes sense and I can come again in two weeks so whenever.

B

To talk about the second yeah, I was just suggesting because it'll give some time for people to look at your doc and get some people to talk about it. If you, if you got people interested, I want to come next week by all means put on the agenda. um Yeah I'll.

H

Give this a review, I'm curious. I am curious.

I

Good. Thank you. Cool.

A

um I don't think we have anything.

B

A

Also, we, you know it's it's it's worth noting that this recording will end up on a youtube channel. So we can point to this the point in time that you've already given this overview, and uh they could hear that you know the 10 minute pitch as well. If they don't just read the notes and whatever other supporting docs.

B

Actually, that's a good action item for us to take. We've been horrible at taking notes during the meeting, but we've been getting the videos if we could at least put the time when we change topics into the notes. And then people are doing the video.

A

Yeah, it's it's! It's kind of neat and I've wished that google uh youtube would get better at the transcriptions, but um yeah it does help. Sometimes.

B

Cool uh any other freeform topics that anybody wanted to share.

F

It's good to see everyone.

A

Nisha says with her camera off.

F

There's a reason why the camera is on yeah.

A

That's that's fair! That's fair! I'm not pushing.

B

As a teacher, some things that come the website making some pretty good progress on the notary work, um we'll have some more distribution. Spec proposal changes, including the refactoring work around the various manifests and go libraries. We've gotten some interesting conversations about what should be moved and so forth, and um the metadata api stuff that we've been toying around with as a conversation for a long time, is coming up again. um There's.

B

uh Basically I so I've got some proposals, I'm trying to get something written down for people to review, but uh that I'm hoping to make some progress on as well, um which I'm going to remind vincent again. If you don't come up with something better, I'm going to propose an uh a dictionary list with a clearing house of names of like registries can just say: yes, no to a list of strings or something so.

A

Yeah it that's that's pretty much. That was my original thought with that with that extension proposal, and I think we went off the rails and into the weeds as far as like the the big, the big thing really became the sticking point and it got nicely.

A

Philosophical, but the the reason is that we were thinking that there would be some top level, like extension, so that, if you're, adding actual api endpoints like rest api endpoints, everything would be nested under like a slash ext but effectively. That negates or flies against the acls of any other repository. Where we, you know, you might say, vbats, my app is a private app and so all the other api endpoints are nested under vbat.

A

Slash my app slash whatever else, and so it became of the mind that, like effectively, one of the goals of every registry owner is to manage acls and if you have something like signatures or whatever else, and you have all kinds of like information, exposure or even just flush, flush attacks or whatever, that would should be nested under the acl. So now you have this extension that describes endpoints that just go back into the base um base api.

J

A

J

Just having just having.

A

Some like basic json array or dictionary that says those you know like like. If you do system ctl system cuddle, dash dash version, you see like plus fips plus ima, plus se linux- that's what that's what I was hoping for, but the fact that it would push those things back into the main name space or base main endpoints was less than ideal. So I I wish I could rethink that, but um maybe there's a.

B

Incremental step, because we will hook that with notably two I forgot about that part of it. I was thinking just what is a registry support from capabilities like you know, for instance, artifacts all it really requires. Do you have an index well actually not index. Do you support additional media types? That's all artifacts really requires a registry operator right, but so there's no api change, but to your point.

A

When you do have, or even even even that, even that query is going to be tricky since some of them do, you know allow lists, and some of them do deny lists that you can't just say: you'd almost have to like incrementally say: do you support this mime type?

A

B

It's fair, that's fair and I think uh mike somebody had given big feedback on one of the apis that we're proposing. But the point is that you would kind of take it to the next step of saying great if you're going to have an extensibility on the registry and you need an api. Where should you put it- and I I've forgotten around that aspect- that we will hit that because there are two different styles there's: a registry domain is broken up amongst people through a route name space and then there's the other registry pattern.

B

Is the registry is owned by the domain and everything in the root is, but even that we're we're changing even an acr, because we're going to be adding like an org management cut feature within a single registry.

A

Right yeah, which is fine if you want to tier into that, but that still means that if somebody adds an extension for new api endpoints, it's it could push at various points from that.

D

A

So that's something to consider, but on the fundamental I do like saying here's this concept like multi-arc, like signatures that like yeah, I support that go here for more information on how we implemented it um and even if that's like jason, schema or something, then I don't know that I could get really creative really quickly, but that that part I like the managing how it handles with you know: acr.

D

A

Docker hub clay and and not making a security nightmare uh is, is a the next hairball.

B

All right well we're going to walk right into that problem, because we are introducing some new apis for getting a referral list and notary stuff, so we're going to have to break through that problem regardless. So, let's, if we can figure it out there, then maybe we can figure out how we can define that for new extensions to add apis.

B

So hopefully this isn't a once monthly conclusion reviews all right, we'll give people this. If somebody else has any other topics.

B

Going once coming twice.

A

Yeah and our two speakers, it was very late before so thanks for adrian albon.

C

A

Adrian you're, here in scotland and when you're in germany so much thanks.

H

C

What are you about to say, josh.

E

I was just gonna uh point out that we did get the reorganization merged, so there's still a bit of work to do before we kind of release, candidates and peter- and I are working on that so- but a lot of great progress and thanks to the maintainers for helping push that through.

B

So a silly question: what happened to all of us that have docks that reference, markdown files and anchors? All your anchors are broken yeah. It's all broken.

A

I mean all of it's broken.

B

I would yeah I was assuming there's no magic redirection, that's.

A

That's what you get for pointing at a pre 1.0.

B

Well, if somebody over there would actually ship this door.

A

I think I think we tagged an rc 0 for you.

H

I think there's still a spec file, it's not going to be as bad as you think.

B

I was just I was what I would wear josh. You were talking about doing some kind of magic redirection.

B

A

No, no, no, that's fine! I guess that's something. Just let's do it. Josh has worked miracles, but I don't think that miracle is in the is it.

B

Some frog tour or something I forgot, what it was called. It was some weird name anyway. um Just I think the probably the best thing I would say is just declare when you're done so people know to update all their links, so we have to update them.

E

Yeah, if, if you have any problems with like the with links, breaking just open an issue and we'll um help you out.

A

Well well, broken links within the document. Yes, but yeah.

E

If you're pointing to the spec.

A

Then wait for 1.0, that's what's going on here! If you ever.

D

If you're ever referencing.

A

A master, you know, you know main trunk head whatever, then expect it to be broken. So.

B

Actually, it's a good point can because I just did this on artifacts and auras and a couple: are we ready to take change master domain in this move too?.

E

Yeah, I think I think there was a github thing in the works last I heard.

A

Yeah, the the last time I investigated it. There was some issues with everybody: who'd opened a pull request against master, it would close them or whatever and I'm pretty sure they worked through that and I have not investigated since then, so we still have openvrs on.

B

A

Yeah, but I just no no, but the topic hasn't particularly been surfaced as a change to maine. I know that uh can folk we've already started renaming repointing some of our branches to maine, um but that that was one repo low-hanging fruit repos that didn't have open pr's. So.

B

No, that's fair. I I I actually don't know if github is trying to do something where, if you open something and it's mastered, you change the name. Just redirect so um that'd be an obvious cool thing to add all right, I'll leave that one alone. So uh where are we since we do have a couple of minutes? Where are we in declaring I wanna?

B

B

Hot potato on your plate, that's what you get for sean for disappearing and jump back up.

A

Yeah, fair, okay, josh wants me to say yesterday, um at least by the end of the month now um the they're they're I I have not compiled that as a timeline in my head. Just now, um a lot was going into the mini updates that were broken down, that josh just alluded to or were merged.

A

um I think there's a few cleanup. There was some hope around the extension proposal, but that was post 100.. um There is.

A

C

A

That that that that that is something that I've had sitting in my inbox for a little while and unrelated that also runtime spec 1.0.3, um but the the distribution spec 1.0 is obviously got eyes on it, and I don't have a estimation on that.

A

Josh josh could honestly tell me. Josh could probably honestly tell better what he sees as a blocker for 1.0.

E

um I um I, if I'm being optimistic, I think an rc1 is in the span of a few weeks, considering maintainers are available to review stuff, so.

A

There was a meeting we had. That was like here's a.

E

Few outstanding stuff we knew dependent, so I'm working on that now and if that can get reviewed and merged, I think we're ready for an rc1.

E

Is 182 ready for review?

E

A

I should just close that sorry, given the fact that, unlike some of the other ones, we were kind of working from something that's fully in in industry adoption. We were just making it. um We had good iterative conversation, but we also were basically working with cleaning up what was already fully adopted.

A

um I don't, I don't foresee that we're going to go through the same kind of rc cycles as we did for the image spec and runtime spec. I think that's been long agreed and that's part of why the incremental rewrite that josh and peter just went through was so meticulous. Was that making sure we didn't lose anything there, but it's basically what already exists so probably we haven't. I could imagine, having like an rc1 rc2 and then go, um but rc1 in the next couple of weeks would be super.

B

So something that's come up a little bit when, when folks last time we talked about adding config to index and moving the schemas up into artifacts to kind of pull it out of the image spec.

B

We also noticed that there's some duplication of things from an image back in distribution. Spec, there's some go. Libraries, oh.

A

For sure and definitions and some of that.

B

Yeah, hopefully,.

A

We address some of that, but yeah there's definitely lots of carryover.

B

What is everyone have a couple minutes left, so maybe I'll make this a topic for next week, but I think that was the question is: do we do we clean up some of that refactoring so that we don't have weird duplications and then.

H

We did two answers right, one would be to say this is from some other place. Some of the some of the text was built. So take it back three answers. Some some were code built some some were you know this is cited, we're not you know no edits here. Please and, and others were yeah. We probably couldn't delete that right. So there were definitely three answers.

A

Or are you saying and we need to see, we need to filter through.

H

It we need to go through the you know, line by line from the original and make sure. Are you saying that we do that for the image spec as well.

B

Well, for me, I'm not saying what what was interesting. I mean with respect.

H

To this one, I agree with you vince this. This won't take as long it's not going to be as hard as tedious as it was to get the image back done.

B

Yeah, in this case, what we're just saying is do as part of the cleanup do we lift them up into artifacts and start using that as a focal point for where these live, because they get used in multiple places, um but instead of being duped, and do we want to put that as part as the windows spec of distribution, and do we want to add config to the one of those spec of distribution?

B

um So that's that's a conversation and I'm fine either way. I think there's some motivations for one or the other, but um we should figure out. I I just think we believe that signatures is a pretty big thing, that people are looking we're, seeing more and more and more pressure on a on a weekly basis. So um well I'll tell you what I'll put that up for next week's conversation?

B

uh Well, I'm hoping to have the metadata pi conversation next week and the uh some of the distribution spec uh conversations on which fall out of that uh fall out of notary and maybe we'll just I'll see if I can get something pulled together on the various go and schema library, references that are over there.

B

All right, well, that pulled up the last couple of minutes of the hour. Thank you again for our pack.

A

Are the videos getting auto uploaded or is that a task.

B

Is an auto upload of amy? Oh maybe is our honor.

D

Actually, I think phil's been doing it recently, but I'm happy to be able to drop some in.

A

D

Yes, it is all very manual, I'm.

A

Just making sure it's it's shareable at some point in the next days. That's all yeah.

B

We've been getting better, we've been getting better about it and I really like the idea of let's: let's keep notes of the agenda items at this minute into the the call. So this way it'll align with the videos amy does the video, I guess, does the video start on the hour or the start when the first person.

D

Whatever the room opens.

A

Yeah, it's pretty great too, because you'll get some like drive-by somebody forgot they dialed into it and just like one person sitting there for five minutes, it's pretty great. I like to call through that recording box every so often.

B

All right, so I will take a look and figure out does: does the video does the recording have a reference to actual time or to be like 15 minutes in which could be 10 minutes after the hour, because somebody dialed in five minutes? So what happens.

D

Instead is that youtube will give you an auto transcript of what was said at which point in the video zoom itself does not give you any of that.

B

Yeah, okay, so what I was thinking we would do was in our notes for next to each agenda item we'll note down what time that topic started this way, somebody can scroll forward to that point in time in the video. The problem is: is that if the video started 10 minutes before the hour, then we're going to be off by 10 minutes? If I just note the time, that's why I'm wondering if there's somebody to correlated time time coding.

D

um I would actually suggest being able to have people look through the auto transcript of um youtube and find like the point which they're actually looking for, because that's a really easy way to scrub. Okay,.

B

All right all right, let's see if we can I'll, take a look at what we have and see if there's uh something other than this thing, or maybe maybe the transcripts are good or not better cool all right. Well, thank you. We'll see everybody next week.

D

B

C