Cloud Native Computing Foundation Runtime Special Interest Group, 23 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF SIG Runtime Container Orchestrated Device Working Group Meeting 2021-02-23

Description

CNCF SIG Runtime Container Orchestrated Device Working Group Meeting 2021-02-23

A

B

C

Hello, hello, everyone, hello, hello,.

C

Hello, so, let's hopefully today we'll get more.

C

D

A

C

There is one time long time haven't.

C

E

C

C

F

C

I don't know heroes.

C

Looks like runoff has some.

D

D

Seems so I hope he can hear us.

F

Hey sir, my internet is acting up a little bit.

C

Hi good morning, no problem.

F

Good morning, everyone um maybe we should start um all right, so welcome everyone to today's cdi meeting. We are the 23rd of february on the agenda. We have the following topics: um the logo, the first draft and a demo. Are there any other items? People would like to add to the agenda.

C

Well, we added also listen. uh Remember we sold topic about non-root uh containers and usage for devices, so we just need to agree about a few next steps.

F

Okay, um logo and draft implementation I'm just going to skip over them. Basically, please go look at the slides and give us feedback.

F

um Feedback can be done either through slack over the slides or just as an email to this to the to the to to segrent uh as an answer to to the email data sets uh the drafts of implementation.

F

um There's nothing new here. Just please take a quick stab at reviewing it uh it'll embark on implementation um and that's it alexander. Do you want to bring up your topics.

C

Wait a second so regarding the first implementation, so it's uh your your references just were part of cydia like cgi park, but uh have you already published it with podman pull request or if you created something no.

F

Problem because I mean we- we have a small apartment implementation that I showed like um last time, uh but I didn't make a pull request because it relies on um the pull request that is for cdi to be actually merged.

F

Okay, just to get the wiring rights, you know about the import.

C

Okay, so ronaldo next question regarding were demo, so we have almost the same set of people. What we've had in past time? uh Do you know if, let's say kevin from your side is going to join? I know what no now kevin, unfortunately, couldn't.

F

Join um and but he'll be able to join next time, um and I think um we.

F

uh Ronald needed to can't join these meetings anymore. He has a standing conflict, uh so we might.

E

Need to reach this game. I spoke with ronald a couple of days ago and he wanted to rejoin the meetings because it's getting no concrete and the implementations on pogba and cryo. So I think next time he will join. But uh let's see.

F

C

I'm just thinking like do we have, uh I mean, does it make sense to repeat them or just use the previous recording.

F

What do you feel I mean if you don't like it's it's okay to to not redo the demo we can. We can always like point to the recording. I think it's on youtube.

C

uh Well, I'm I'm just curious uh how much people are interested to see because, like I uh okay well, let me ask differently like zwonka and rodney, uh you are two new people who previously haven't seen what them are. uh Do you want to look at it and description about it or you want to look at offline in our recording.

C

Both both ways for us work, fine.

E

Both ways for me work as well. If, if we have time I I would love to see the demo okay one, let's go, it needs to be a quorum. So if other people are not interested in it, I can take it offline hi, I'm interested in seeing the material.

C

Okay, well, let's, let's do it all right! So, let's let me switch.

C

Shadow screen this one.

C

A

C

All right so uh how we structure, we think uh I will do some introduction words just to explain a basic idea what we are trying to achieve, and uh afterwards we will see two parts of a demo like that. We'll show how it works for fpgas and duker is going to show it how it works for uh gpus.

C

So, first of all, we are talking about how to use vcdi so right now, and the cdi is uh on the level what uh how we describe where devices uh in a form what it can be consumed by the runtimes and attach it to the containers.

C

uh What we want to show is a step further, so how it potentially can be used in kubernetes world. So.

C

C

So where the main idea is what we want to get to is to have uh crd objects, which will be describing devices and well, sir, the object is something what port can consume so using of exposing devices, as crd objects gives us a lot of freedom of how devices are allocated, how devices like life cycle is managed and so on.

C

So we have preliminary idea of how it maps to a few objects, and let me walk through so first of all, we have idea of a device class, so this kind of objects will contain information about uh the vendor, like set of devices which are compatible. So, for example, like several generations of gpus can be the same or like several fpga. Cars might be compatible with multiple functions, so this part contains for information.

C

What is where common parameters? What is the vendor specific, provisioner or controller which uh handles these types of devices in the cluster when we have device clean so practically? This is how workloads says I want to use particular device and inside that object. What we want to have is set of parameters exactly describing what actually, what kind of device user wants.

C

So, for example, like it can say, I want to have device from the class fpga or gpu, but when it can provide a set of parameters like I want this particular amount of memory on with one web device. uh I want time slice if it supports for sharing and yeah based on the devices. It might be a lot of different parameters.

C

So when we have a controller which actually handles with claim and based on this claim parameters, it does it creates an object or with actual device allocation.

C

So uh this actual device allocation contains information like actual information about the device which can be consumed by a workload. So practically it's a part of json file. What needs to be created for cdi to be consumed, but as well uh topological information for kubernetes, for example, like on which nodes it can be available if some additional information needed to be exposed for kubernetes as well and one is going to be consumed by report.

C

So, as I mentioned with json file, which is created from device allocation, it will be using your standard by our proposed cgi interface uh as part of uh one or multiple containers within the report.

C

So to demonstrate all of this concept, we didn't want to re-implement everything from scratch. What uh what we thought is what the current kubernetes csi components. We have all the needed components which we can, I would say, misuse to demonstrate this kind of concept.

C

So we are pigging back on uh csi, like controller and no legends uh persistent to demonstrate uh like simple device allocation and ephemeral storage uh primitives. uh If you, when we want to demonstrate like uh a bit more complex, like deployments with multiple ports where you have it like a template and every port is actually allocating uh similar kind of devices or workloads. So, on what step I'll hand over to ad who can show actual actual thing.

B

Hi everyone I'm at barter uh and I'm going to to continue with the demo, but before the demo I would like to let me share my screen. I would like to show kind of a location, workflow diagram, so it.

B

Let's start from the cdi component, so the dcdi uh actually contains uh two main components: the controller and node agent controller usually runs on master and node agents. They are responsible for collecting device information, so they they need to access the devices, and so they are running on the nodes.

B

And then this is actually implemented as a csi plugin, so it has like similar components so yeah, as sasha said, we are pigging back on on csi implementation, so we we didn't touch the control, plane, components like scheduling and so on. We just implemented it as a csi driver.

B

So on the workflow we have this storage class, which describes the the device device type device family. If you wish, then we have this persistent volume claim which is kind of device claim, so it has a specific allocation parameters. They are passed as a pvc annotations.

B

So when the port is created, it's uh it's referencing. Pvc and pvc is referencing storage class. So, on the pod creation time we have all the information like from from storage class and from pvc and and from both of course, uh and that actually put creation triggers uh two csi uh calls. First is a create volume, so it comes to two main csi controller and controller. At that time it it has all the information about all the devices in the cluster, because uh node agents actually provided this information to it.

B

So it has uh all the information to to understand which node can satisfy the the parameters, the like the end parameters. Again, they are coming from storage class, pvc and port, so it it picks up the the node contacts. The c cdi node agent and cdi node agent uh actually makes necessary steps to to mark the device.

B

As in as allocated and like when, when pod finishes, then uh the the allocation request actually the it's uh uh it's uh it's going like the same way as as a location just other way around so and the next call, which is also called uh when the the port, the pod creation is actually started, is node stage volume. So in csi world it's.

B

uh The aim of this call is to mount uh the volume on the on the node, and then it can be been been mounted bound, been mounted into the the pots uh files uh file systems like when the when the pod is created, so that happens before the port is created, and that is that call is handled by csi node agents. So what what it does it's? Basically, it has an information about the device they allocate it and it just creates the cdi json file on the node file system.

B

uh By the way we are using like cdi spec uh well at least that that part about the devices so and this file contains the information about the devices first and then about these parameters, and parameters can be passed as a as environment, for example, in environment variables like to the container, and then we have this run c roper uh it when it's called like.

B

I, I actually admitted all these uh uh cri things, because it's it's uh it doesn't matter in in this picture, so like at the end of the day, run c is called, and it's uh reading this json file. Reading the information about the devices that that should be accessible inside container does it.

B

It actually updates the the spec the uh sets uh devices there like and sets environment variables and and then like it, creates the container the run scene, not a wrapper, so roper is just to read the csi json and update the spec and the run creates the container and container has the access to the device and it has access to the environment variables uh which are coming from from parameters.

B

So that's that's the the picture, at least how I can see it. uh If you, if you have any questions, you can ask along the way. So in the next step I I will try to to demonstrate with the fpga devices how the allocation works and- and it's like very simple demo- the the next part would be like more uh complex demo and and this one is just like simple uh as simple as I could come up with.

B

So it's screencasted, so I just run a screencast. So we have uh two nodes.

B

um We actually control plane, ports running and we have this cdi controller running and cdi node. So if we have more nodes, then like more cdi, node components would be running here and then we have two devices on on the on the node two fpga devices. So the first one.

B

So I would like to to point out to these two parameters. So first one is interface id. It actually describes the device class in this case it's uh area, 10, fpga device and accelerator id is uh basically the function which is programmed into the device currently, so it's programming program device. So that can be changed like this.

B

One also can be changed if you like, upgrade the firmware and stuff like that, but we consider it as a kind of uh constant for the current device class so and we have another device which is basically the same device, but as you can notice, the the function is different, so it's it's programmed with different functions and what we actually want uh when we like specify uh that that that we want device, we want some accelerator function so, for example, like j, zip or whatever, like some compression uh another compression algorithm, so that is specified by this id and that that, like this id, we we will be using actually in the in the pvc will be using this id.

B

So we are expecting this uh first device to be allocated and accessible inside the container and and this device like wouldn't fit the the parameters, because we want this accelerator function.

B

So, uh let's start from like creating storage class, so, as I said, it is describing uh the device family. So in this case like device, family area 10- and it has this interface id parameter so which is common for both our devices.

B

We create the class next step. We will create a persistent volume claim, so it's it as a device device request and just creating the claim doesn't actually trigger any device allocation because we don't have pod yet so as soon as we have pot that that is referencing. This pvc, the the volume or device in our case, uh like volume, location request or device allocation request, would would be actually created and processed by the csi machinery.

B

So we created pvc.

B

And next step we will create a port. So let's look at the port, how it's referencing so as as we are using csi, uh we have to use like this mount pass and volumes scene and the the way how it's referencing the pvc is through. This persistent volume claim parameter, we create a pod, then everything goes as I try to describe on the picture, and then we can just check if the device uh the first device like which ends to zero is accessible inside the container. It is so that's, that's practically the demo.

B

So again we had. uh Let me switch back to this, so we had one parameters passed from storage class parameters and we had another parameters: the the function id passed as an annotation like through these calls, and in the end we had this device accessible inside this container.

B

So that's that's it and next demo is, will be uh showed by by ukri.

C

Thanks and just small comments, so just because we are using the csi for for this demonstration, like some of the parameters are passed as annotations, but the end goal is to use like the proper share keys. So we can have a custom fields. What lenders can specify based on where device requests or device needs.

D

D

G

D

D

um So this is the same thing that I presented a couple of weeks ago. um I took the uh cd, I think, to a gpu context, and basically I was interested more in figuring out how it could improve on, let's say, sharing of gpus and things like that. Getting like multiple ports running and a bigger deployment than how it works in situations like that.

D

So, instead of trying to exactly match a device like it showed, I uh created resources for the gpu like memory and mili cores which, which could be consumed by ports sort of dynamically until they run out and see. If I could do this, uh in addition to this sort of exact matching of allocations, and in this demo we've got more nodes, there are uh basically three nodes: we've got cfl nokia knocks three of them small nodes with one gpu each, and we have a cmls machine over there, which has two gpus.

D

You can see also one machine at the top, which is running the cdi controller port, but it could be any machine in the cluster really typically the monster like headset, but anyway, in this case, it's not so the uh the cards in this. If we look at the device files in the nodes through ssh are here and uh like I said, the nox only have one gpu in them, but the cmls machine has two two gpu cards and um for these uh gpus uh there is no.

D

um There isn't a proper prop uh memory, query or you know, figuring out of the capabilities. I instead just hard coded those things, and I created two resources, memory and mili cores, so each gpu gets 1000, millicourse and basically four gigabytes of memory through the hard coding, instead of figuring out the capabilities, and these are then just you know, then moved into map a map of parameters by the way, if you're interested in in the demo code go there, but let's go back to the actual demo.

D

At the bottom left corner, you can see your deployment yammer now, since the cluster has four gpus with 4 gigabytes of ram. Each.

D

That's a total of 16 and we've got a deployment here with 10 replicas. It's trying to get 1.5 gigs. So that's 15 in total, which you know from a number point of view. It should fit. But if you look at the gpus having four gigabytes each, uh you could basically only fit two ports for each gpu, and that means that for gpus uh equals eight bots that should get up running the mili-core amount here, since each gpu has 1000 shouldn't be a limiting factor as much as the memory and we're using fml volumes here.

D

Just because, if we didn't, we wouldn't be getting individual volumes created for each board. This is a little drawback of using the csi.

D

So the expected end result when I launch this deployment is that we get eight boats running and two of them should end up pending if the resource management works.

D

D

D

And it seems that it is still working and also the expectation is that since the cms1 machine has the two cards, it should be running more ports and we can see that we should have four ports running in there and that's correct, and these knocks only have two ports, so everything seems to be fine.

D

There's still one check we can do. Let's see we can check what kind of a device has got mounted into these um ports and again, the expectation is that we should see only two bots using the card number one.

D

So we have j4lhq.

D

Which is over here, and it should be the two card machine and it is and there's another one over here which is lx4gb, so that should also be cmls and that's correct.

D

So it kind of works as long as you don't try to allocate more than one gpu.

D

That's basically the place where we have a little bit of issues using the storage, because if you try to allocate to they don't get allocated and considered at the same time, and that creates issues.

D

Now, if I would try to add an another deployment there, it should end up bending and if I then delete the first one, which may take some time, the one that was bending should eventually end up running again.

D

So it's like this. Basically any kind of params could be created, but now which you chose to do memory and melee course in this sort of dynamic fashion,.

G

I got a question: um how do you test this? I mean, um let's say that you have an application that requires some cuda access to the library. um How do you expose the content of those drivers inside your container? I'm sorry inside your pot in this case, so that they can reach and make you know they make use of that library that make use of a specific hardware.

G

I mean: how do you test that? That's basically the question I'm asking.

D

Well, I would like to direct any cuda related questions towards nvidia, really, if renault can fill in how they do it, but we try to in intel. We try to do our stuff in upstream and basically.

G

No, I mean it's not specifically to cuda. I guess that what I'm asking is um this framework that you guys are thinking about um has to take into account the fact that there are some sources, some code, some libraries that might need to be imported. You know or supported um into the pot, um and I'm just I'm just saying that we have to think about that, and how is that going to be? um You know done um within the context of this framework.

C

But let me answer that so in in general, uh like importing well, adding anything to the container it's possible like with cdi specs, allows you to add any new mounts to a container or any, uh let's say, pressed out hooks. So, for example, how nvidia does it is? What uh inside cdi is json file? It will be injected to information about like indie, config scripts and tokuda libraries.

C

uh It's it's of course, like certainly separate questions like shouldn't be done or not, but it's it's a fact of life and yes, it might. It might be that way. So the idea is what this json file for cdi is created by vendor specific node agent, so it will be like similarly to csi drivers.

C

You have uh two components which each vendor needs to provide: the controller which holds where, like the custom vendor logic about the whole cluster allocation and then one node agent, again vendor specific code, which transforms the allocation object to actual cdi json.

C

So if any vendor have some specifics, for example like this library injections, when it will be on the node component, which with beats will be injected.

C

G

Yeah, yes, it does it answers the question. Thank you.

D

Right and from my side, this is mostly what I have to demonstrate.

D

uh We didn't get much further than this for the time being, with the storage as our tool.

D

So I'll suppose I'll stop sharing here.

C

Yeah and again, storage is just a show to show a concept where the final idea how it should unbox is what we are considering to use for series and when we need to come up with a way how those series can be specified and report as a consumable resource.

C

So on what note I will stop.

F

C

F

E

I need to digest some things, but my my first thought was: uh every every gpu vendor will implement sharing in another way uh amd with c groups. uh Nvidia with mick. I don't know how intel is is partitioning their gpu, so in the in the last screenshot you you, you are requesting resources. Why amelia course and memory? Are we going to talk about an interface, how we are going want to uh request those resources?

E

I mean mili course could be the right term, but uh most of the gpus have like cu units or compute units. uh Are we going to do a abstracted interface for requesting those resources it could be gpu could implement, sharing with time sharing or the amount of ceus it provides.

E

So this would be my my question: how are we going to talk about the interface, how to request the resources so.

C

Ugly can talk about what in more details, but my genetic answer to it will be such so. You are correct, so all vendors might have different uh variants how to control additional parameters so for devices.

C

So luckily for gpu, at least in upstream kernel, where is the discussion going on what like at least like where upstream kernel drivers will have the same unified c groups, interface to consume or to specify those resources?

C

It's a long question when it will be merged to upstream kernel and when it will be stabilized, but at least like some intermediate patches exist and um at least on our site. We are. We are testing these values, uh however, for for different classes of web devices, for example fpga.

C

I hardly believe for that will be some standard interface through with c groups or true kernels, so it we might end up in with scenarios what, in some pre-start, hooks or pre-create hooks uh like some of the parameters for the device will be handled in this uh like scripts, which is executed before the container is actually started.

C

So, for example, like we are handling the programming of a device to draw those, but for for our type of software devices it might be somehow vendor-specific logics.

C

So the whole idea is what we are trying to provide the mechanism where, first of all, the user experience will have the ability to specify all kinds of parameters which required for van buren for particular device type and when we have a whole pipeline to deliver those uh parameters down to a point where it can be actually consumed and put into into use, for example, like two kernel drivers or through any other mechanisms because practically think about it. So the same concept might work for devices over the fabric.

C

So you just need to provide this parameters to the fabric controller, to prepare devices based on where these parameters and those needs.

D

Yeah the parameters shown in this demo were just examples and there was no intention at all trying to force them down anybody's throat.

D

So we tried to make this demo at the moment able to use any kind of parameter names, so there's really no limit there. What they could be. uh It's an interesting thought to actually try to unify some of those uh for gpus, but uh at least I did didn't have any kind of a intention towards that at the moment, but we're open to any kind of discussions. Of course,.

E

Yeah yeah: it was clear that this was not like the final stage and you don't want to have mili course for every device there, but thinking of gpus there is some abstraction, as you just said, we could anticipate to have uh but yeah it will not fit for an fpga. It will not fit for for a let's say, a nick or something else. We cannot say melee course or memory or something like that. That's completely uh fair to say: okay, yeah and that's why I asked.

E

Are we going to think about to add a interface to some specific devices, or are we going to leave this completely open? Are we going to make this somehow configurable and the controller will pick it up and manage any of these annotations that we are adding there? So I'm just thinking about uh how to move forward. Okay, great thanks! Well,.

C

My initial idea, when, when I initially thought about this, is what I I don't want to limit vendors into specific, like set of parameters or some set of things. So if you look at the existing csi layer, we can see what like there is a hard coded set of parameters or set of fields which needs to be filled. So, for example, like you need to request the size of something uh like regardless, what kind of storage it is yeah?

C

I don't want to repeat the same slider here.

C

It should be like really specific controller to reserve this to actually process this hammer process. The parameters and then just say, okay allocation is here, and this is the point of to object which handles relocation and node agent on the node knows how to handle that object and expand it to where cdi json.

C

So that way we can have like any kind of parameters. So, for example, like imagine we can say, uh let's say, network device added, so we can pass from like list of new ones which needs to be pre-created for those devices and when exposed or something like very let's say we can have like optional devices.

C

So we can have uh devices which can say okay, we can be shared within one node, but we which won't be shared between multiple nodes or we can be shared within one port, but not within multiple containers, like this kind of um like flexibility of how how it can be expanded um so well. The goal is like to to give you flexibility and give a flexible interface. What vendor logic can handle allocation not only within one small piece of node, but also across the cluster.

C

So multiple devices over fabric uh scenarios uh and one uh flexibility of uh what kind of resources it can be consumed within report, so scheduler knows what it's accessible and how it's handled it's handled by a long time.

E

Okay uh makes complete sense. That's why I also mentioned that every vendor will have like their own way of sharing and we need to adapt it to to their needs and not lock them down in any anything.

E

The plan going forward is is to is it to extend then device manager and device plug-in to resemble this. This functionality, you you created here or do you want to create a complete new instance running running kubernetes, like I own cda agent and the cdi node thing.

C

So I don't believe what existing device manager us as it's implemented right now, it will be capable to let's say, step by step to to do migration.

C

What what I'm thinking is actually to create uh similar to csi part inside kublad the mechanism? Well, actually, it's not only kublet, it's it. It will touch across the whole stack things. So, first of all, we need to have in pod spec mechanism to reference to crd as a consumable resource per container or as a pod resource. Actually, it's both violet cases.

C

Second thing uh we will need to have on the scheduler part uh like similar pieces of algorithm, which says uh like like like currently scheduler, is handling where storage, so the port is not scheduled to the node until we actually get where clean uh fulfilled and when we have actual allocation.

C

This topology information where uh this volume is existing, so when the scheduler makes the decision to to place report, so here we will have the same thing. So a scheduler should wait for when this allocation will be fulfilled and afterwards it uh it will schedule to to appropriate node where this allocation is available and one for the couplet.

C

So the couplet needs to have similar to csi uh mechanism to to do those few things like publish, prepare uh those base, basic things which needs to be done, like the steps before the container is run um and like where devices is the major use case, but in reality in reality, what we're talking about is actually it's a primitives. What can say what pod can reference as a consumable resource, any other cfd object?

C

It might not result as a like actual attached resource to uh to container, but it might help with just like, obviously like scheduling, login or extending um logic of kubernetes.

C

So right now here these are the things on top of like the pod is the most smallest thing when, eventually, what what we will get if we will implement these things, what we are showing here is actually the crd will also become a consumable object with input.

E

C

I I don't know, how do you feel? Is it good idea, bad idea.

E

uh As I said, I need to digest everything, but but looking at the concept, it looks good to me for now. I need to think about more and yeah and, as you said, there's definitely the connection to the scheduling, uh topology hints device manager, device, plugins, topology manager, cpu manager, all those connections to be made as well.

C

E

C

Just to nitpick on on this thing, so right now we have a big problem. This topology manager, cpu manager and device manager, is what uh way do we decision and what those decisions are not based on where like how? How big problem of migrating of workloads between the components so, for example, like making a decision for devices heavy thing like you can't like, if you have a device, you cannot move it it's physically attached, but something is like some resources like cpu cores, it's easy like it's almost instant migration memory. It's a bit more complex!

C

You require to move from memory and it's more expensive thing. So and with all this mechanism, we have a problem. What, for example, like existing storage layer, it's completely not visible to topology manager, so you might end up what you you have like. Yes, your pod is consuming the device and it's efficient, but when you have a storage which is completely connected to different pci bus- and you are this one workload stressing the whole system, so um there are several ways how to do it differently.

C

uh I don't want to be well. I don't want to include it in this particular discussion, but if we want to have really efficient resource management, we need to consider also how our storage is handled and when you know how this resources allocated to all across the node.

E

So you are involved also in the topology aware scheduling thing for so I suppose you have this cdi use case in mind, going forward with all the caps and and uh that we have for topology we're scheduling right.

C

We have but again.

C

Have to say um it will be multi-stage things, yeah.

E

C

We we can improve, like small things right now, with the current design, but in very long term, when we will need to revisit some of our decisions.

C

Okay, but at least at least for, like my my way, sorry, not mine, but our ways of thinking about what is uh currently what like, swati and alexey uh are doing is what we're trying to make sure what were information exposed to scheduler will be enough to make the good decisions, but as soon as we will start to add- uh let's say vendor specific logic.

C

So, for example like this nvidia mig right, so it's a it's a fabric of interconnected devices, so where, let's say inside, no topology might become a completely irrelevant when you are building like multi-node workloads.

C

So we need to have some flexibility how to expose what and how to use it in scheduler, but it might be not as trivial as this current device plugins interfaces. What we have right now.

B

E

Okay, I agree. Okay, we are almost at the top of. There are any other things we should discuss before closing this.

C

Yes, we have actually one uh one more item, which is uh non-root containers and it's great what mike at least joined it so maker. If you want the stage is yours.

A

uh Yeah, so I just wanted to follow up this topic, so it's a it's a it's a long topic that we discussed, I think like more than six six months ago, I I prepared this uh documents june july time frame. We had uh some conversation. I heard some feedback about uh about the document, but then it's been mostly silent on what the next steps should be.

A

What I did I I think it was like uh a month ago, or so I I created two pocs based on on the proposals that I laid out in in the document and sent a reminder to seek note, made english about getting feedback, uh getting feedback about all those pocs that I built, but I I got zero feedback to those as well, so on the two, and I have the the conversation, what the what the next steps should be on this.

A

My poc is, I I created them based on, or I created um my my poc, using called container d. So if mike is here, would you be, and I'm really willing to take a look and and give your feedback? What I have.

H

Hey miku, yeah I'll, take a look thanks.

A

I can I can send you the the links I I have them maintained in my private github repository one. One thing that I was discussing with sasha today was that uh I could also create a pull request for for the container the repository I just uh rebased, my poc to the latest master to today and everything everything seems to be fine. So would you be.

H

Fair, I want to.

A

H

The status then, on the on on the open issue in kubernetes mkk.

A

Oh okay, I can do that. I can do that then, and.

H

Yeah I'll just follow the link and yeah I'll review your. If you want to push that code, that's great we're a little swamped.

A

Which way so I can, I can create the pull request to container the repository as well, but right now it I. I have the the code living in my private fork and I have the.

C

I have, I actually suggest, let's create, also a pull request to cryo, so we have like two tuple requests to both major implementations. Yeah.

H

We want to do that the same way.

A

Yep, okay, so I can. I can certainly do that, but um let me share kind of the update to this uh kk issue. With with the latest code, I have, and I can also submit it as a support request to the container container the repository and then to the kind of the same for for cryo as well.

H

Yeah did did yeah, I haven't looked at your document. Did you did you choose? I think I put a couple options there. I'm not sure if you picked one, I I to be fair. You know that was june of last year.

A

Yes, yes, it was it's, it was long long time ago and it was kind of the time I was starting my summer vacations and then, when I got back right.

H

Memory of reading through it and making some suggestions, but I don't remember the details so I'll- have to refresh my memory and then uh and get back to you, okay, but yeah. If you'll, if you'll put something in there, that updates it a little bit just a reminder and then I've got it on my screen, of course, but yeah and yeah. We could definitely use the help on pr's. Here I mean that's: okay,.

A

But so we can, we can now kind of keep the conversation go going and I'm like I'm at least committed to kind of getting disclosed kind of wanting to to have the problem. Sort it sorted out. So it's uh you guys. It sounds.

H

A

Did it both ways I yeah my I have to? I have two pocs. Both both ways are implemented. Our preference is the kind of the opt out model and the original idea that we would use the uh run as user run as group as as the user id and group id device knowledge.

H

Yeah, I hate to have to do it over annotations, but I think that's the only way to get it through cleanly right now until we've moved cryo. I'm sorry cry to you know to pass beta and we'll and when we get to a point, one we'll be able to update the security contacts fields.

C

But uh mike we don't need to update the security context fields for this particular change.

H

Right, that's correct! That's why I'm saying we can just do it as an annotation.

C

And uh well mika, say it: what we have two implementation and we experimented with both and uh I think just.

H

Just gotta pick one all.

C

Right yeah well, both works. uh We just want to like we pr what maker is going to create that we'll just include the one which uh we think more user-friendly and uh device plug-in developer, more friendly yeah.

H

That's that's fair. I didn't. I didn't really care which direction it was if you guys want to pick, go ahead. Yep.

C

Okay sounds great.

A

But I I I'll post the update to the issue and there was somebody asked in the document so yeah. It is available as the google doc link in in the the kkk issue. So.

H

Cool thanks mika thanks for taking the taking the lead on this thanks mike thanks.

C

All right, so we are top of our thank you, everyone for joining today. Thank you for listening for and watching our demos and asking your questions. Let's continue our emails and let's chat on twix, see you all. Thanks. Take.

A