Cloud Native Computing Foundation Runtime Special Interest Group, 8 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF SIG Runtime Container Orchestrated Device Working Group Meeting 2020-12-08

Description

CNCF SIG Runtime Container Orchestrated Device Working Group Meeting 2020-12-08

A

B

Looks like it's just the two of us.

A

Yes, it is actually strange renault sent to agenda items and didn't show up yet, but let's, let's wait him.

B

Oh, I hear it say it's on and slack at least so.

A

Well, for me, his slug still shows what he's away.

B

uh No, I meant, like I, just saw the message he sent yesterday ah yeah. The meeting is still on today.

B

C

Hey there, I was having issues with the password again.

C

C

C

Everyone and see, what's here.

C

Might be better on there.

C

C

C

C

C

Well, I'm still waking up.

C

All right and let me pull out the mini.

C

Notes, let's start sharing on my screen, and nikolai is here actually so um I saw that his topic was here uh was on the agenda last time, so probably gonna bump it up at first all right.

A

Well, it was not really a question. It was just a discussion I'll just capture it. What what we discussed yeah.

A

You have additional questions. Welcome.

D

uh No there's no questions this time. No, no! It's fine! I think that we get a good discussion, exchanging of ideas and, what's going on in various communities out there about this, so yeah, it's fine for now, thanks.

C

All right, uh do you wanna, like? Is there any topic, you wanna, sorry. Is there any specific question you wanted to like um talk about.

D

uh I don't know if this is directed to me, but no, no, nothing, nothing specific. We kind of did pretty big. Let's say extensive.

D

Say: walk through various topics. Last time, okay, I kind of stole the floor last time. So, okay, I'm here to listen now.

C

Anyways all right, um I probably forgot to do the meeting introduction so hi everyone, my name is renee today is on the 8th of december, um and this is the fun container orchestrated device work group meeting on the agenda.

C

We have cdi next steps and we have kubecon europe. Are there people who would like to add any items to the agenda today.

C

Cool, um so this might go faster than time, um so I added these two topics. Actually um I wanted to figure out. um I think, just generally, what's our strategy to tackle, um I think cdi.

C

One of the objective I was hoping to get done by this year was trying to get an alpha version of cdi and maybe pondman or continuity, and wanted to figure out, basically whether we should pursue um trying to put nri in both pod and container d or, if um I think, the path forward might be just a bare integration of cdi and pondman and trying to figure out how to integrate with an ori in the community.

C

So, unfortunately, uh I'm not seeing mike brown in the attendees, but I am seeing your vashi um in the attendees, so maybe uravashi. um If you have a an idea of um what would be the process or what would be kind of steps that would help make a decision around nri and pondman.

B

um Sorry, I think I missed the first half of the question. Can you repeat that here so I think, like.

C

um The the the the goal that we're trying to get to here is: um how can we get cdi right and to me, there's like at least the way that I'm looking at this is that there are two paths we could either try to do this bare cdi integration inside the base, and I think, like I had one example where it gets you an idea of what kind of changes you'd be looking at. I should.

C

Yeah so or the other alternative, so this one would be um there's like a package, that's added that would be like imported from a different project, so it's kind of uh not what you'd be looking at, but the package basically would expose something like a um a get spec for a specific device. Node.

C

um Let me actually walk through this properly, so this is something that I presented, I think back in september or october. um The idea was to just get it given a a rough idea of what would be the changes that would be required if we wanted to integrate cdi in a project like cloudman.

C

So, instead of playing with multiple repositories, I just added a a directory cdi at the root of oddman. um The goal here is not to add a directory cdi at the root of men, but to load this directory from or this package from um the cdi representation. But um it's a rough idea um where or it gives you a rough idea, one two two two I mean this is basically an mvp right uh trying to like get to get to your demo as quickly as possible. So I have this file here.

C

That exposes two big functions: um get specification and update specific one has device and update specification, so get specification walks through all the runtimes in the runtime map and basically says this is the device um and basically says I have this device where I do not have this device right and for this device. If I have a device, then this this is the specification that you need to have uh has device basically says uh gets back. It just says: well is the specification different from now and then update spec for a given oci config.

C

And for a given set of devices, what are the changes that need to be made? I mean update these specifications right to make the changes to these to the ocs. I'm sorry, if I'm not making sense, no.

B

This all makes sense, and I I agree with the approach. um Obviously all this would be in a separate cdi, repo that podman would actually vendor in right, um and I think with podman, it's pretty simple, that you can just use a flag. We can create a new flag and you can pass in the name of the device node or whatever. We can use to recognize where to pick the cdi um plugin from basically.

B

uh But I think the question comes like in terms of cryo and container d, because those are talking to the cubelet over the cri, so we wouldn't be creating flags there but like what is the plan like? How will the user specify the device to be used in your pod spec like? Are we going to use an annotation, or are we going to create a new field in the cri api like? Have we.

A

B

A

We discussed it, but let's not go away yet uh so regarding reflux, uh the idea behind uh initial idea was what uh we want to reuse the of the same flux, so you already have right now: minus minus device uh so where, where argument to to that flag, can be used in this library as a device and regarding the kubelet, it's possible to do like several approaches.

A

So right now we have a device plug-in mechanism which again also sends the device name. So we can reuse web functionality for now until we get something better and something better. It's a separate proposal which will be built on top of your cdi.

B

C

Sorry can you repeat that uh which part the last sentence, you said something was something better. uh One of the saturation went through my head and then like some, some got lost.

A

uh What I say it is what right now for kubernetes, we are planning to use the existing device plug-in mechanism so where the device name field will be expanded to on the cgi level, and there are some other ideas how to implement it a bit differently. But what will be done well a bit later as a separate proposal.

B

How do we plan to differentiate between, like whatever the current existing device plug-in uses, and how to tell it that okay, we want to use the cdi stuff instead,.

A

First of all, we don't need to distinguish okay, we just need to pass the argument to vcdi and, let's see if it, if it knows it and second thing, uh existing device, plugins we're sending where absolute pass to well as a device name, so slash, dev, something and uh cdi devices. We are expecting what it will be just like normal sling, no, not actual device node.

A

If, if we really want to have some safety uh and distinguish rows when we can just check so if er, if device node on the hospital is present when we assume it's normal device, if not when just let's check with cdi to see, if, if it's a guy device.

B

C

Sense yeah, so I think, in the same in very similar vein of what center is saying um today, we have the ability with the device plugin to pass annotations, um so that would be one way of enabling it at the cardio level or at the community level, um in terms of um what it looks like in kubernetes.

C

I think this is an ai that we really need to be taking in terms of like making a presentation.

C

And starting something like.

C

Or at least a rough document that leads to.

A

Account, uh I don't know we we have. uh We have a proposal for that, uh okay and actually- and actually we have even a proof of concept- it's just stuck in our internal bureaucracy for uh releasing this proof of concept code externally.

A

So I really hope. Would the nucle solve.

C

A

C

Can show it do you want to take the eye to present it, maybe on the next meeting, which is definitely not going to be the 22, the 22nd, but probably going to be the fifth.

C

A

It will be when january right, yeah.

A

uh Sorry january, which one january january 5th.

C

Actually, like should.

A

C

It one more week and put it january 12th, because I'm kind of suspecting everyone's still going to be coming back from holidays and catching up on this yeah. My day my day.

A

At least like in finland, six of uh it's uh public holiday, so yeah so.

C

Let's, let's move the next thing, I might.

A

Yeah jan 12.

A

Well well, let's target onward and I hope we will solve our bureaucracy items before.

C

um And then I think one last answer to you uravashi is that in my mind, this is something that is very similar to what alex is saying. um What happens is that the cuboid is just passing a name in the device uh in the device I mean. Basically, it's still passing a device in the in the cry api.

C

um We don't change, require api, uh let's see our api's, but we we really just pass a device and the name of the device is like, instead of being dev, uh sda1 or dev nvidia zero, um it's um nvidia's here or nvidia gpu, one right.

C

It's it's a it's saying: it's not a it's, not a path, it's a name, and then that would be what, like you would name on your on in your cdi file right.

A

Well, no, no, no, not file, but well. Sorry I I give is, I was in cgi spam.

C

Yes, so in your ceo spec, when you define these devices you'd say, and so maybe that name that you're passing down is vendor.com devices device equals my device.

D

B

Okay, yeah. That makes sense. I think, um if we can get that pr, that you showed like the cdi stuff set up, then we can give it an appointment and like cry, I guess we can create a sort of work in progress pr or something using that and getting.

A

A

B

I don't know and.

A

I I agree actually with that approach. So, let's, let's do first like minimal pr to like cryo container gear and uh pod one and see what kind of feedback we get and as soon as nri will progress to below what we can use when we will switch it to nri yeah. I think that's moving.

C

Is easier yeah I mean, especially if it's behind, like a a feature flag or something um yeah, so I can clean up my pr, I think, uh with regards to nri um there's discussion and progress. I think I'm thinking of just making a pr that to cdi to nri to just integrate cei, but not do anything basically just be able to read the spec, the cgi spec for my plugin um and update it, but not pass it up to cubits.

C

I think this is more something that michael crosby would be more familiar with and I'm less comfortable like getting in there. I think he has more experience with that.

C

um So concretely, the next steps sort of okay. Let me know about it- I I I don't get here.

A

C

For on man, what we're saying is need to get a pr.

A

C

I think my next step is basically going to be so you know how there's like container d changes and then there's nra changes, and then there would be cdi changes. That's kind of the three main repositories that we're talking about.

C

uh What I'm talking about is today, there's no link between nrn and cdi right. So what I'm suggesting is just make a pr that makes the link between nri and cdi so that nri plugins can talk cdi. Does that make sense.

A

I was actually thinking I was like wow way around, so cdi becomes a plugin to nri, so it gets hooked to pre-create container and when get was spark, we modify spec, but the problem.

C

With that approach, is that, um basically, if cdi is an nri plug-in, that means that cdi needs to be doing these different operations to update the spec manually. So, for example, uh invoking or uh changing the c groups right.

A

Why no no no like uh well the same approach so uh like nri should call cgi as a plugin saying like this is the container I want to create and password, uh or should I spec down yeah and us as a return, it should be getting likely modified. Spec.

C

So, oh yeah! Yes, so that's what I'm saying? That's that's what I'm saying. uh I think what I'm saying is that the nri subsystem that I know I repository should be invoked- should be able to talk to plugins using the cdi protocol, basically, meaning that an nr dnrs system should be able to invoke an nri plug-in right and that plug-in returns. A cdi message.

A

uh Well, it's I'm talking about a bit different thing, so I.

C

Think we're saying the same thing: yeah, I'm struggling finding the right words.

A

And result is the same but communication a bit different. So I'm talking about a bit more generic approach, so it will on an nri side. It will be no hard coding or no assumptions about the cdi itself.

A

I'm just saying like in on nri site. It should be just a generic hook, which says this is for container I'm going to create and any nri plugin.

A

Not a cgi specific, but generic uh mechanism.

C

Yeah, I think I think we're seeing something exactly the same thing is just having stroke, I'm struggling finding that right where's this um is there any differences. We can probably figure it out in the in the pr, um but I think yeah, I'm. I think I'll. Take you a step-by-step approach for container dnra.

C

um Actually, if, if people want to start contributing like feel free to do so and prompt me might just focus on that.

A

Yeah regarding we're contributing so uh as we discussed it earlier christian created, well our comments about where nri in nri repository so yeah. I think, like your issue was like number two and I was like number three or something like that.

A

Yeah, if you have time please, please have a look because practically what uh what we summarize it in that issue. It was exactly this like generic mechanism, where we can uh well intercept like majority of things um in uh in and right yeah. So this one.

C

Yeah yeah: I need to subscribe to it I'll I'll log into github a bit later. Yeah.

A

So please, please have a look on this issue and if you have some comments, please comment.

C

C

I think he didn't see the issue by the way unless you paint him yeah, probably not at least we haven't got any comments on europe. Do we want to submit something, especially considering two things? We are less likely to get a spot, given that we just presented a talk at uconn us.

C

um The deadline is next monday and I don't think we've made significant progress that would kind of deserve a different topic.

C

um Also, it's a lot of work.

A

So uh if, if pr to be spodemon, cryo and container d can be merged quick enough, when what can be a part of a topic, so like a deep dive on how it's integrated to cryo, podman and container d, how cgi files are like look like and how how common line user issues look like.

A

So this kind of presentation can potentially work.

C

I I wonder if this is something that we should present like a year from now, uh it's may.

A

So we have about like five months is it I thought it was.

C

March think it was my yeah.

B

I think it's in may may.

C

C

A

B

C

To take the lead on uh issuing a panel or.

A

Alex I'm not sure, I'm not sure what a panel will uh will be possible, we can try or or we can or we can try to ask it as a maintainer session. I don't know like within a runtime struck as a maintainer session.

C

Okay, um I think like do you wanna. Do you wanna be pick on this one and um try to figure out what's the best path for this uh feel free to reach out to our people? I think the only thing that I would like kind of suggest is to keep the group up to date on the segment time seriousness.

C

And everyone that's interested in participating, feel free to reach out to you, alexander.

A

So uh ronald, I I don't know like um so normal cfp is for like normal track sessions, but I think, like all kind of like maintenance track like introduced, dives and so on. I think we are following some our process for submissions.

C

You don't want to get a dedicated session, uh we get to go through the normal, the same track as everyone else. um I talked about this with um ricardo, um the who's, the um the chair of cigarette time, and um that's just like we're a work group. We don't get a dedicated uh session.

A

Okay, because I I thought would well at least when I was more involved in where c cluster life cycle. I I remember what were like uh with sub projects like uh pube spray giveaway, and we had.

C

This is definitely possible and I can see that because of the size of these projects and probably the fact that the community has evolved, I think we might not be there yet exactly.

C

I don't think we've got the same doctrine as something that could.

C

Happen, oh yeah, I mean feel free to reach out to ricardo by the way um he's on the cncf slack so and he's he's very approachable, ricardo and last name.

C

uh Iran uh he's also you have his name also in the aravinda. Sorry about that uh he is on the cigarette time. um His name is on the cigarette in time.

A

So uh so, with web session, uh I can probably draft in next couple of days some small abstract for that uh yeah, um who wants to be a co-speaker so right now I assume you are. I don't.

D

A

Don't you don't no, why it's.

C

European time.

A

C

I also feel that's not like it's not like as the shepherd of this community. I feel like it's not my role to always be uh the person speaking about it. I think it's a great opportunity for other people in the community to um to to to have exposure and to participate.

A

Okay, so or wash what what about you, or maybe you can talk with me now if he wants.

B

uh I mean I'm, I I'm down to talk, but I'm also down to not talk, so I'm gonna leave it up to you to decide.

A

A

My idea for talk is something what like we have. We have devices.

A

Well, we have spec, we can show how the devices are uh defined when we have uh container runtimes which actually consume it, and for this second part I need somebody who is more familiar when he is without so uh I don't know like somebody from container d or from cryo would be the best candidates.

B

All right I mean I'm fine with that. Maybe we can also ask mike brown like if he wants to do it as well, so.

A

Okay, I'll probably send in which so I'll draft abstract, let's see how it looks like and when uh I'll send it in our slab chat. If it's a panel feel free to invite.

C

Michael crosby.

A

Oh absolutely, yes,.

B

And I can always help edit the video again, if needed,.

A

C

Cool, uh I think that's the last one. um Thank you, everyone for joining um and I think you're all getting back. 25 minutes so have a great day or end of day for people in europe, and I have no idea how that works out for other people in the world. But I know that uh alexander is in europe. So that's why? I'm actually here.

A

Well, christian annanti is, from our company same time, zone finland,.

C

All right, well, everyone, everyone thank.

A

C

A

D

D