Kubernetes Storage SIG, 22 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Storage - bi-weekly meeting 20210422

Description

Kubernetes Storage Special-Interest-Group (SIG) bi-weekly meeting - 22 April 2021

Meeting Notes/Agenda: -

Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage

Moderator: Xing Yang (VMware)

A

Hello: everyone today is april 22nd 2021. This is the kubernetes six storage meeting. So today we have a few design reviews. So first we'll go over this uh volume restrictions for part security and the psp replacement cap.

A

Then we will go over our 1.2 planning.

A

So this is a good opportunity for new contributors to learn how 640 works and if you are interested in anything, you can speak up during the planning in this meeting or you can also pin um one of the leads michelle young or myself after the meeting to sign up for some work and um looks like we also have uh another design review on secret production.

A

Okay, let's get started uh so tim. Are you there.

B

Yeah hi, thanks for uh hosting our topic today,.

A

Should I make your uh co-host so you can you want to share.

B

B

B

Second, um all right: can you see uh the pod security standards, documentation.

A

B

um All right, so let me um just give a bit of a a bit of background for folks who don't know what we're talking about here um so today uh the standard way of limiting um uh limiting pod permissions is through pod security policy, um but starting in 121 we've deprecated pod security policy. We sort of have known this was coming for a long time, but didn't have a good path forward. So we were waiting off on that.

B

um So pod security policy is deprecated in 121 and we'll be removing it in 125., um so we've been discussing. Actually let me switch over to uh the cap um been discussing for a while uh what the best way to replace it is, um and we've come up with this uh proposal. That's based on these pod security standards that we have documented here and one of the key differences between this new proposal that we're hoping will replace pod security policy and the previous pod security policy is pod.

B

Security policy was very configurable, so you, you, define your policy and you say for each of these different control features like host network or privileged containers, or capabilities or whatnot.

B

um You can say: is this allowed or disallowed under this policy and define as many policies as you want and bind them to different pods in a somewhat convoluted way um and the new policy instead just defines these three privilege levels, so that's privileged baseline and restricted and privileged is defined as being totally unrestricted, as if you don't even have the admission controller turned on baseline is defined as allowing a minimal pod spec.

B

So in other words, if you uh define a pod or if you, if you create a pod with just um a pod name, uh a single container that has a name and a container image and don't fill out any of the other pods back that should be allowed under baseline and, of course, anything that's more restrictive is also allowed under baseline and for things that are elevating privileges beyond that baseline pod, it's a bit of um it's a little fuzzy in terms of what we allow.

B

So some things like a privileged container is clearly more privileged, so we disallow it, but when it comes to volumes which is actually what we're talking about today, we allow all volumes under baseline, except for host path volumes, which we completely forbid and then the restricted profiles. The third one is much more heavily restricted and follows what we consider to be best practices.

B

So if I scroll down to that, one of the key differences from one of the key differences from the baseline policy is running as non-root.

B

We require the secomp profile default second profile, which I wish was enabled in baseline, but since it's not, we enable it and restricted, and then notably, we are much more restrictive of volume. Types and the philosophy of the volume types was sort of um for persistent volumes. uh Rather than using the built-in inline volumes. um Persistent volumes should be going through the persistent volume and persistent volume claim features.

B

We do allow the built-in ephemeral volume types so empty gear, projected volumes, secrets, config maps, um but we try and uh disallow all the others, um but in yesterday's meeting about um as we try and kind of lock down these the definition of these different profile levels, we had ended up having a discussion about the csi volume type and whether we should allow that and restricted.

B

So previously, we've been thinking that well, csi volume is another type of volume that should just go through persistent volume types where you have a more privileged user, defining the volume um and then you can claim it to the pod.

B

But we realize that actually there's a lot of ephemeral, csi volumes that should maybe be available under the restricted volume type.

B

um So yeah, that's so that's sort of setting up the background um for this discussion um and where we'd like appreciate input from um storage.

B

Does anyone have any questions on what I talked about so far um or jordan? Is there anything you'd like to add.

C

uh This policy is for poor namespace.

D

B

So um so the the way the um the new policy is bound is through a label on the namespace. um Let me just pull that up here, um yeah. So, basically, we put a label on the namespace that says um what privilege level the namespace should run as um so, we would have something like uh um pod isolation policy, uh slash, allow um restricted or or um baseline, and this is yeah, so this is label on namespace and applies to all pods in the name space, with with some exceptions through another api.

C

So my understanding is, there are only three types and is: is it customizable for let's say one of the type.

B

Yeah, so one of the goals of this is to have these policy levels be totally predefined.

B

The idea is that we want to have kind of well-defined, basically best practice policy levels that we think apply to the majority of users and then for someone who needs more fine-grained control or has kind of advanced or more complicated policy requirements, we're just recommending that they use a third-party admission uh web hook so, for instance, um oppa or gatekeeper, or one of those other options.

E

Is it possible for.

E

um A third-party option to also uh build on top of the the ones we provide like. Can you use these profiles along with gatekeeper,.

B

Yeah definitely so, um if so, the way mission control typically works is each admission. Controller can say kind of um no opinion or deny um so once one admission controller rejects the request, then that read kind of rejects it flat out. So if you want to layer on additional restrictions beyond what's here, then it's easy to kind of have this work in parallel with a custom admission plugin.

B

But if you want to potentially relax the restrictions here or kind of come up with your own definitions of the policy levels or something like that, then you would want to disable this admission plugin, either through one of the exemption mechanisms or just kind of disable it globally for the cluster and implement your own policies and to make that easy, we're going to be providing a web hook, implementation, a library, implementation and also kind of this well-defined spec, which is noted in the pod security standards, documentation and kind of a suite of tests uh that test.

B

If your implementation meets that spec.

F

So the the specific question we had around csi the inline, the inline csi volume source for pods.

F

um If you go back to the restrict the list of restricted volumes that are forbidden tim, um we don't want pods in the restricted profile making use of all of these various persistent disk types.

F

I know that there are csi drivers being implemented for many of those persistent disk types um and we weren't sure. If, if we allowed pods to use the csi uh volume source, could they effectively make use of the persistent disk implementations csi drivers like? Could they could they create a gce, persistent disk or a azure file, persistent disk via the csi volume source, or does that only allow using ephemeral, csi drivers.

E

So the answer is possibly um the the way that these csi ephemeral volumes are implemented. uh Today is the driver needs to explicitly.

E

C

Implementation.

E

Of it and I think for the most part, we have tried to sort of encourage the use of this for ephemeral, use cases and discourage the use of this feature for persistent use cases. But um you know, I think some drivers may have already decided to go ahead and implement the persistent case using this api, even though it wasn't really the intended option.

E

um So it's the answer is, it depends on which driver and I think most of the drivers on this list that are in restricted their equivalent csi drivers have not implemented this part of uh support for this feature. But I think there are like a handful, maybe one or two that have um is.

F

That is the table of like the inline volume sources like I know, only a subset of them even have csi drivers, and then it sounds like only a subset of those uh provide ephemeral capability. Is that table? Does that table exist anywhere.

E

Yeah we can, I think we can definitely um provide the table. um I I think, though, there's also like this other concern that there's actually a bunch of new csi drivers that are, that don't have intrigue equivalents um and but they may have also implemented support for this.

F

In general, is it reasonable for like an ephemeral volume, if that is created, uh does that does an ephemeral volume mean the volume is provisioned for this pod and then torn down when the pod goes away?

F

Yes, and does that mean that it would be safe for a restricted pod to make use of that? Or does it really depend on like how dangerous the volume attributes are that the csi driver does stuff with.

E

Yeah, I think it depends on the actual attributes that the csi driver exposes, if say, the csi driver exposed attributes similar to how the entry inline volumes exposed their attributes. Then that would be a problem.

G

uh The persistent volumes they use volume handle to identify the volume in the storage back end, and we don't have that in the inline csi volumes. As far as yeah.

F

So the volume candle is generated and is unique per pod, but the.

G

C

F

Like, depending on the csi driver implementation, maybe one of the volume attributes it consumes is something like what host path should I mount this thing to? We don't know yeah, of course, yeah. It's also.

E

Yeah, like we don't give the volume handle, but it's also possible. The csi driver could have exposed their own custom attribute. That is essentially a volume handle.

B

So the the philosophy that we've gone with for a lot of kind of the extension points in the pod is, um if it's something that's controlled by the cluster administrator um or like a you know, requires kind of cluster scoped highly privileged permissions.

B

We sort of are saying, like trust them, to do the right thing or um implement kind of appropriate protections, if necessary. um Of course, we'd prefer to provide more guidance than that, um but I.

E

Think I think, in this case, like like, it could potentially fall under like the the csi driver author, like it falls under them to like design their apis to you know, fit the security models that we recommend.

G

We have the flag in the csi driver that tells if the driver supports this fmr volume or not.

F

Right, I guess.

G

F

Is like is it? Is it generally reasonable to say, restricted, pods can use ephemeral volumes and, if you're going to deploy an ephemeral, csi driver that is unsafe, then you need to restrict that restrict use of that by quota or by custom admission like um I'm trying to think if there are other equivalent things on a restricted pod.

F

That would open holes that someone might an admin might not realize exist like even even the new ephemeral volume type in the pod you're you're limited to things that you can express on a persistent volume claim. So you don't have that, like full control over volume, attributes that you do under csi.

G

Like I can imagine some host path likes. Yes, I have fmr volumes that could be fine for some main spaces and could be super dangerous for other namespaces yeah.

B

So we are allowing them under um under the baseline policy. So if you're doing something as dangerous as exposing host pads, then we would probably say you need to pair it with.

G

Custom admission control at the same time like I, can have super safe secret provider that uses this inline csi volumes, and I was I want everybody to use it.

F

Right, that's kind of the motivation behind us wanting to allow it, but also wanting admins to know if you've got a dangerous, ephemeral, gsi driver. You have to guard that.

E

G

E

We have, um we have the csi driver object where, when you install the csi driver, you have to declare um if it supports. If this ephemeral mode or not, um that might be a way. We can potentially restrict try to restrict things, but it would still have to be on, like a per driver per driver basis,.

B

Yeah, so there's sort of three options: we're considering here. um One is uh actually what we had originally proposed and probably over restrictive is just to say no, you can't use inline csi driver volumes with the restricted profile.

B

The next option is to basically say that's the default, but provide some sort of escape hatch or configuration mechanism, either um statically configured or through the the object that you just mentioned to say like well. We say this volume is safe, so allow this one kind of an allow list approach, the other.

B

The other option is to say we just allow all csi driver, inline, csi drivers and, if it's unsafe for restricted, then it's the responsibility of the author and or cluster admin to layer on additional policy.

H

How does this uh like? We know that this, this three policies can be uh uh added to the names just, but what decides which name specific given gets which policy like like? What is the default?

H

If I just install the kubernetes cluster.

F

So to be backwards compatible and to be able to enable this by default. If you don't indicate a policy level for a name space, it doesn't restrict the namespace. um So it's up to the person provisioning, the namespaces generally, the in a cluster where you want to lock down some users of the cluster.

F

um You don't generally give those locked down users uh like permission to create their own namespaces and like do things globally, so there's usually a provisioning step and an access granting step that sets up a namespace and then gives a user access to that namespace, and so part of that would be deciding what access level that user should have.

B

um And that is configurable or the default is going to be configurable through a static flag for manifest, but but the default default is christmas.

G

Go back to the three options. uh I admit I kind of like the existing psp or the user, where the admin like says these drivers are safe. These drivers are not safe um level. It fall in your options. You provided.

E

I think that that sounds like um it falls into either like the second option, where we have allow lists of specific drivers um or it falls into the. uh Maybe this is the fourth option, where we defer this to like a gatekeeper or some or someone to layer on more restrictive policies.

C

So if the purpose of restricted policy is kind of motor was unrestricted right, um I feel like I think, csi, because.

C

Says that driver could be very arbitrary and um we don't have much of control of that, and so, if you want to motorways on restricted side, I feel adding the csi is safer.

C

I don't know how many use cases we use in csi, informal storage, it's relatively new and.

E

I think it's pretty it's going to be pretty pervasive, especially for um there's a lot of, like I think, cert manager and like vault and other really popular um secret management mechanisms. There they've all started using this.

F

Yeah, it is new, but usage is increasing and this is sort of the direction we've been telling people who wanted to do custom injection in the pods to go. So it's kind of the only option really for this category of integration.

E

Yeah, so I guess to use this feature, um someone needs to install csi driver that supports it. They also need to set the field in the csi driver object, which is a non-namespace object, so they already need some sort of higher permissions to be able to enable this to be able to enable these kinds of csi drivers in the cluster.

B

Given a csi driver implementation um like the the actual binary piece that they install, can you toggle that ephemeral or inline field on the csi object on and off and like have it kind of work interchangeably with the same driver.

B

In other words, if a if a driver kind of shipped with the manifest that has it enabled, could an admin say well, I don't actually want to give users access to this. So I'm going to just turn.

I

E

I

I

Yeah there's a csi driver object with the field that specifies whether ephemeral is supported or not. They could toggle that, and I think all the controllers that look at that field should do the right thing.

E

Although I don't know if, if you already have volumes melted with it, would that cause volumes to fail to be unmounted or something like that.

H

By default it is immutable, but yeah you could delete and recreate it.

J

um Well for safety, you would want to create it with the feature off from the beginning, so it was never on right. Yeah.

F

Since baseline allows csi, I think going back to tim's point. If you have an ephemeral, csi driver that is exposing like behavior, you would consider unsafe or escalating like host path, or you know, consuming volume, attributes that, like give you direct control over like kernel parameters or some something like really significantly escalating, I think you would not want that ephemeral driver accessible or you would want to protect it, but with quota or ignition.

F

E

Think the biggest question.

F

For me would be if, if the csi driver is corresponding to those known inline uh volume sources, support ephemeral by default, knowing that would be helpful.

B

I think I'm leaning towards just allowing csi drivers for restricted and basically solving this through documentation on the kind of pod security side. We would say uh you know if you have an unsafe csi driver, then we recommend either disabling inline definitions or adding an admission control and then maybe on the csi documentation side, we could say we recommend only using the inline um only enabling inline volumes for things that should be safe to restricted users.

G

um My best stupid question: can we add a flag to the csi diver object if it should be available to restricted baseline or only privileged.

F

This was one of the options we were considering, and I am not a fan of that, because it makes evaluation of a policy against a given pod. Spec stateful like it, if you say, does restricted, allow this uh pod spec right now. We don't need any other cluster state to answer that question, but as soon as you make it configurable per driver via the api. Now you need to like the question it depends like it depends on which cluster you're in.

B

Which and one reason we want to avoid that is, it makes it a lot harder to run this in say, like ci tests, or you know off of your git repo without installing it on the cluster itself, and it also makes.

F

The answer change over time, so you can have cases like oh yeah, well that policy level allowed this pod yesterday, but now that attribute on csi driver changed, and so this pod is no longer allowed by this policy level like changing results over time is not desirable.

G

That also implies that the list of allowed csi drivers can be basically anywhere, because this can change.

F

Yeah, so if allowing if you're talking about policy level like what pod specs are allowed, um does anything prevent creation of a pod that has a csi driver that references, a driver name? That is not that does not exist or is not ephemeral, um or is that a runtime like it lets me create the pod and then when it goes and gets scheduled, and then the cube tries to do stuff with it? At that point it I think it's one.

G

F

It's runtime, okay,.

G

You don't have any admission for that. Okay,.

H

That's what I was saying that, like the there's, nothing stopping anyone from using a csi fmr volume as a persistent csi and then volume like provided they put the handle and the parameters field, not in yeah.

F

um I don't think that's true when I traced it it on like the when it. If it's pulling the volume source from a pod spec, it requires the associated driver to have like the ephemeral mode.

H

I mean sure it could be said, but a given a volume handle in the parameter it could be used as like we can. We pre like for sure say that when the part is deleted, the volume will be deleted, no right like if it had a handle like a vsphere handle or aws handle. Then it's it's.

F

Yeah, a given driver that says it supports a thermal mode, could always be buggy or could like I'm not as concerned about that. I'm mostly concerned about um whether whether the known csi drivers for the existing entry, inline types are saying they support a female mode or not. That's one question and then uh whether uh it's reasonable to say, if you're going to deploy ephemeral, csr drivers that are unsafe or allow like escalation like it's your job to protect against pods using.

F

Those um we don't want to take your whole meeting, so I feel like we should. There are a couple questions. I think we can get answered out of this and then circle back. So I'm happy to uh let you continue your meeting and not take over anymore.

A

uh Yeah, so we want to start with that, one that you need to planning, but I think yeah. This is a great discussion. So do we do we want to schedule another one to continue or do we want to continue the discussion on meaningless or how do you want to maybe.

E

Can we um document the the action items um here and then we can maybe follow up on those action items and decide if we need another meeting. Okay,.

F

I put one which was the table of entry drivers, csi drivers and whether they support ephemeral.

F

I think the other was more of a question which was like. Is it? Is it okay to say if you're doing ephemeral, csr drivers that are unsafe, you should protect against pods using them like you're responsible for that.

B

um I saw that david uh eads just joined the meeting. He was the one who originally raised this uh this topic to us.

K

Yeah, I plan to watch the recording uh the weather's already in progress, and it definitely was so I'll watch the recording. If I have questions I'll, probably start on slack.

B

A

Okay, thank you.

A

uh Tim can you, I think you are still sharing.

B

Oh sorry, that's.

A

Okay, okay, thank you.

B

It'll probably drop off, but uh thanks for having us hey.

A

Thank you for joining under bring this issue for discussion.

I

uh Shanks, since we have 20 minutes left, should we just do the other design review? That's on the agenda today. Get done with that and then move the planning session to the next meeting.

A

I

L

Will be it's kind of weeks.

A

Yeah is that the like the cube cubecon week.

I

Oh, I forgot about that. uh Okay, in that case, let's just get.

A

It we should start a little bit, I think a lot we, we may have a lot of uh new contributors today. So probably we should uh even just get started with.

I

So, let's do it, how did you see how much we can get.

A

Through okay, all right uh all right, so this is our pluniche um yeah. So I think, as I said, you copied this one from the 1.21, so we start with this. um So basically we will continue the uh the items that we didn't finish in in 1.21 uh and then, if there are anything new that are not included here, you can feel free to add um on this uh spreadsheet so just to go over this. Let's see how much we can uh we can cover and then we'll continue the next meeting.

A

Okay, so the first one is uh delegate fs group to csr driver instead of cubelet. This is uh so. This is a harmonic this we will continue to do alpha in 1.2.

I

A

I

H

The enhancement is already merged. Just we are blocked on css spec change, I'll, try and get that done. Okay,.

A

Oh cap is off yes, the cap is already merged. Okay,.

A

Yeah and the next one is uh csi online offline, resize, um okay, so this one and the next one those are related right so come on.

H

Fix some issues- and we have to- I- have to write some new caps or update existing caps, so I'll be working on this for this quadrant. Okay,.

A

So this is your basically, we keep it yeah, okay, beta yeah, you may okay.

A

And then the next, the next one we are, we targeting alpha for the next one we still design, let's recover.

H

Her yeah, we should target alpha for that. One: okay,.

M

Let's keep okay.

A

All right and then okay, then we should change this target. Oh okay, so this one changes to 22 um this one.

I

Can you clear the status as you go just for? Oh so now that we've.

A

I

Could just delete both of them for now, honestly, let's leave them out.

A

Like okay, just delete those two columns, you mean.

I

And no just uh empty the cell, okay sure.

I

Perfect. Thank you.

A

Okay and okay, the next one uh secret links recursive permission handling, is young working on this still for the 4.2. Are you still working on this.

G

ah Jan is not working on this.

A

G

So we can either well, it still needs to be fixed, but I'm pretty sure I will not have time this quarter and I didn't find anybody else who would know about the syrinx. So we can either put it somewhere down the bottom of the list and perhaps not do it this time or even delete it.

M

G

May find somebody later, but since this is only designed, we can always introduce okay.

A

G

Without the issue.

A

A

Looking for the owner that or for someone else.

A

Thank you and then next one is the the csi entry read on me handling uh this.

N

Yeah, so for this one um for the one pr that was outstanding- I know uh humble I think, is here as well. um If you don't know, if you don't have time to work I'll continue that pr, I get I'm happy to push that forward as well, um but I think early on when we discuss this item, if I remember we were talking about, there might be a larger csi entry, read-only refactor.

N

um If I under, if I understand correctly um that one uh I I don't think I would have time to work on.

A

N

So for the pr yeah for the pr I'm good to go, uh I can continue working on that.

A

A

And next one is issues related to assuming volumes are mount points. uh Jin, do you know the status for this.

A

Is gina still on the call.

C

Yes, yes, okay, so, like I mentioned last time, there is pr was reverted to the rest.

C

I think merged the pr reverted, but uh it's not ready to merge yet because the risk condition between model management and pot is a no issue. So we don't have a good solution. Yet keep that item like in mind and we work on as soon as possible. Yeah.

A

Okay, thank you. Next one is wood capacity trucking, uh so.

O

Yeah it just entered beta, I think I know change is planned for 122.

A

A

And do we still have anything else to do for this uh pvc line? For more, is this completely.

O

No, it's it's. It's also beta, so the same same same status. It.

A

O

It will stay in beta in one twenty one. Twenty.

O

Two, I see that you straw stroke out or uh I would almost deleted the csi ephemeral volume.

A

Yeah this one was deleted already in the oh, this brush. I don't know why this one is. We bring this back yeah.

O

I think you should.

A

Because it is beta.

O

It has been beta since 116 yeah.

C

O

Not I'm not sure how long we have to do something about it.

A

O

Other new guidelines for beta features.

A

Do we have okay is matt working on this.

P

No, we are not here. uh We don't have plans to do this before the second half of the year, which will miss 122.

A

Okay, so maybe.

A

I'll change three then, but okay uh or does anyone else want to work on this.

G

Do we know what is missing there.

A

G

A

Don't see any concerns, we I think we are clear on the the differences now right. Do we have any.

E

I think there was some suggestion uh about um changing the api a little bit. Oh.

O

Yeah we, when we discussed the generic affirmative volumes, we said that the existing fm csi type is just too confusing, which should be renamed. uh The the enhancement issue for it has has captured those discussions, but yeah there is an api change proposed.

O

uh The other more technical or processed procedural issue is that this whole feature doesn't have a cap in the current format. So cable reviewers might ask before making changes before moving into.

C

O

To update the cap actually define some some ga criteria but which, because all of that is currently missing,.

A

O

We know whether it's ready for ga. We first would have to define what that means and then there's this api change. So no, I don't think it's currently ready for ga.

A

Okay, so probably you do like a second beta is that, can we go directly to beta just if we make some api change.

M

I don't know how to do that.

M

Okay, so still, okay,.

A

So this one still needs some need. Some work.

P

Okay, um a question I have around this I mean, given that I understand these pieces for this. Like are around like search and secrets and stuff I mean I know in google, there was someone there was a security team that was using this or interested in using this. I don't know, if other I mean, I guess that my point is like someone who's engaged in one of these actual use cases is going to be a lot more motivated to drive this forward. I think than um it sounds like anyone here.

A

Okay, so maybe we will okay, so so we were looking for a new you've been looking for a new owner. Then.

P

M

P

Like I I you know in the second half of this year, I may be able to engage with um those people. I know, but I don't know if anyone else here possibly michelle knows you know, has been talking to people who are.

E

I'm talking to the same people, you are.

A

Okay, so we'll see uh if uh we got a new owner, otherwise we continue in one window. 23 then.

E

Like maybe um would it be worth it to? Maybe we don't have to do this here, but it might be worth it to like separate this spreadsheet into like items where we're potentially looking for help or owners owners on um that could help us, like you, know, kind of ask for help in certain areas.

A

Or maybe add another add a new column saying this is like meat owner corner or something yeah that could work too or when you call them okay, you can check out videos later.

A

Okay, thank you, uh okay, so the next one yeah. So this is a spreading over filler domain and the next time. What in group api for consistent groups, those two related, the spreading one, is actually dependent on the second one. um I think um I still there's still uh some design issues with the supporting group. So, um let's see if we can get the half merged, that'll be great, uh so I think I'll leave that in design for now.

A

uh Next, one is uh cs out of three movies: cozy driver is this: uh oh, this is christian in progress. Okay,.

Q

Still needs to it needs to be carried into the next release. We got the iscsi driver added to the staging the six storage staging, but we still need to add the automation for building and promotion.

Q

Okay, I should be able to address this next release.

A

Okay, thanks and okay, so then we have uh our fs parishioner and fs client provisioner, so those uh okay, so karen are working on those. um It's current here looks like it's. Just a dog update. Do we I don't know what else is uh needed for this one other than doc?

A

Let me show do you know this is? Is this a complete or we still have the.

E

Docs, I think it's complete um yeah. I think we don't need to track this okay and then.

A

The next one too right next one is also complete. Oh then, we'll just uh yeah.

E

A

Sell this too, okay, thank you.

A

Next one is the pvc one snapshot, namespace transfer question so continue you're trying to do alpha for this one or.

Q

I I think alpha would be a bit aggressive. We still there's still some blockers that we need to address and I'm not certain how to address them, and this all deals with transferring uh csi secrets and how to respect those boundaries. So it's something that I would like to continue working on the design in this next release.

A

Okay, so design, so let's just do okay, I'll just uh so we'll keep that.

M

A

um Okay and that next one is the boarding house, so this will be staying in alpha. We have a meeting tomorrow to talk about use cases and what are we going to next so we'll decide yeah if uh we're going to? uh Yes, I think there are a few use cases that I uh that I heard about heard about, and we can talk more about that in tomorrow's meeting.

J

Is there any chance, the feature would go to beta, depending on the outcome of those discussions or.

A

So I think I think beta is still yeah. I think beta is also possible, but the the thing is right now I don't know any anyone anything that has implemented yet I'd like to see at least some sisa driver has implemented that right now only the we only have that in this hospital driver. Okay, so so we'll see you know if the so maybe we'll see um if the driver.

E

Station yeah yeah, it might be good, um it might be good to like send out an email to the csi announce list or something like that saying that this feature is now available. Please try it out and give us your feedback.

A

Okay, yeah good idea.

E

A

Yeah, so I think uh so one thing is the existing feature. I bring it to beta and then the second thing is, uh uh I think there are some requests on making this feature available, so we can actually do some reaction when something happens, so that will need some changes to the existing design, but I think that can be like a new uh new feature gate or something or see what that is, um but the existing one. If it's just events, I think that's your helpful.

A

We can yeah, we can bring that to beta if we have people actually use that thing. That is useful, okay um and the next one. Okay, this is the volume populator ben.

J

Yeah this one did not go to beta and 121, so the goal is to go to beta 122.

J

So we this just needs a re-review of the cap and a small chord change and all of the out of tree stuff should just be able to be. You know re-released as beta unless changes are required.

A

Okay, thank you and then cozy, okay, so uh yeah.

R

This is trini, I I can give you an update. uh We are waiting on tim still to get the api review. um Hopefully we we need to get that done as soon as possible and uh about the community meeting. We had long discussions around the credential rotations.

R

uh Essentially, we decided that most of the cloud providers are uh not providing support for that. We would probably provide a support with the basic service account-based auth. uh Our current focus is on the development and we are ramping it up.

R

We have a community web page, that's coming up which will allow us to onboard more people to write drivers.

R

I have a report that uh created for media driver and the pte is in progress so that we could test with media driver, as our reference driver.

R

That's pretty much. It.

A

Thank you and then we're talking alpha right. You want to change you.

R

That's right, that's right! Thank you.

A

uh Okay, changeable tracking, I think, we'll still be doing design. This is uh quite a few things. We need to sort out.

A

Next one is uh the new reroute, only access mode. uh Do you have chris here.

L

Yes, uh so I have a prototype of this working. uh The cap is filled out for alpha and received first round feedback on that uh and I'm currently working on documenting the version. Sku behavior for this.

A

So we are targeting alpha right now: okay,.

J

What about the csi spec change, um but what about it? Yeah that would be a prereq to get this in right as a csi space am.

L

I able to do that within the same time frame yeah.

A

M

A

M

Early right, yeah early.

L

Got it okay, okay, okay, yeah sounds good.

E

There is a, um I think, there's a proposed um 122 schedule and I think the feature freeze is tentatively like around end of may, um although they are, I think there are discussions about moving it two weeks earlier, so like mid-may.

A

It doesn't seem, I thought it's uh four months, but it seems to be still pretty well.

E

Code freeze code freeze is a little longer. I think code freeze is going to be early july, so so you're going to have.

C

Like I thought, maybe.

E

One or two weeks more for code freeze, but the actual enhancement series, um I don't think is gonna- be really extended in terms of yeah.

A

Okay, so where does the extra time go?

A

Testing after the code phrase yeah.

E

Probably okay, there's like one to two weeks extra for code freeze and then probably more more time for testing and documentation and stuff like that. Okay,.

J

All right thanks, so we got to do a time check. There's a meeting after that.

A

Oh yeah, yeah, okay, pre-order past time; okay, thanks all right, so uh yeah. I think I think we went through more than half of this, so we're continuing our next meeting um yeah. So for anyone who are new contributors who are interested in contributing you know if you have any questions or or to help with anything feel free to reach out to us after the meeting all right. Thank you.

A