Kubernetes Storage SIG COSI, 29 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Storage - Object Bucket API Review Meeting 20210429

Description

Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 29 April 2021

Meeting Notes/Agenda: -

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

A

Purposes, you'd rather um uh be not running in a container you'd rather have the sidecar in a container, but the the driver itself running as a binary right. Just because it's easier.

B

A

That way, so um was the old way more conducive to running, not in a container.

C

A

C

So in this case I mean, if you're developing, you don't have to run it in containers, you don't have you don't need customize at all. You you're just.

A

Right but but we have a bunch of guys that have never touched this stuff and they're trying to figure it out. So I'm trying to.

C

A

The simplest way to get started and then, of course, they'll tear it all apart and put it back together in a way that makes sense. Okay, so.

C

How about this? um Okay, so I'll, add a developer's dock uh like building and how to run it locally without uh putting it in a container. Would that help? Okay.

A

Yeah well, yeah and um and just a quick fix. I guess for that quick start guide what we should put on the third line instead um and yeah over time. Of course, we'll want like a full suite of developer docs that tells people. You know how to write a new driver- and you know, but yeah.

C

We're doing that so I don't know if you've looked at this website containerobjectstorageinterface.github.io and then you scrolled up to docs, and then you looked at authoring, cozy drivers, it's it's a it's a it's a reflection of what's there in github by the way, so it needs to be updated. But we are. We are working on filling this up.

C

Awesome, yeah,.

D

E

Ben, it's it's good news to hear netapp's gonna look uh is gonna, be um riding a cozy driver. I wanted to also just share in the meeting that we have a guy at red hat. Who is working on a ceph uh object? You know rgw stuff driver. I did an initial pass at the code. It's it's rough right now, but you know it's going to get better and we'll contribute that as soon as we get something working.

A

F

A

F

Vienne who's also on this meeting, is doing the same for scality storage.

C

Very nice, I'm happy to hear all the vendors are actually uh my.

A

C

It is it's a great thing, yeah, I'm very happy to hear this. um I was waiting for this to happen so now all of us can push the api together. Then.

E

C

That's the that's the important thing.

E

um This is flushing out any weaknesses. We have we're gonna, we're gonna, discover them now.

C

Right right, no, it's very important. We do this now. This is the way to improve. So here's the thing uh all the vendors and everyone. I think we should. We should all get together and uh ping uh uh tim um yes to do the api review.

C

um So what I'll do is uh I'll start a new email thread um and and include everyone here um and and we'll go from there with tim and and I'll ask him to take a look at our api one more time and and if any of you can can reach out to him through other channels. Other means, please do hey sid.

E

I just had a thought when you said that, do you think we can make a more compelling case with getting tim's time? If we say we already have a driver working.

C

We have we have uh scality is also working. I believe scality driver is working right.

G

Yeah yeah, we are working.

E

On it I mean, maybe we should um highlight that that you know it's at least some um validation of the api being reasonable right.

C

Yeah yeah: let's do that. I think that's a good point! Jeff, let's, let's, let's, let's put it that way! I like that. Let's do it.

C

Okay, so um yeah: let's do that? Let's let's do that today. So after the meeting I'll draft an email and uh have you all, uh uh you know cc'd and uh you know- maybe maybe uh if you have links if they're public- and you know if they're open source projects send me a link to them so so I can also include those in the in the email.

C

So the idea is may 13th is our feature. Freeze, we don't have very long and tim's time is going to get even more uh expensive. uh The closer we get to kubecon close we get to that date. So so we want to. We want to um keep trying until then well, isn't kubecon next monday.

C

So we have. We have one day then.

E

Yeah, it's it's the third fourth, fifth, third, fourth, something like that.

F

Yeah officially starts wednesday next week, but there's monday tuesday or the the pre-event.

F

Yes right, that's.

D

C

C

Okay, so so um so ben uh we will update the docs um like a developer documentation that says how to run these things locally um and- and I think that will help you get started.

C

Your team get started.

C

That's what you'd like right that should do it right.

C

Yes, sorry, I was talking on mute, please, okay, I'll! Do that um yeah, yeah and and we'll update these docs to also also reflect the fact that we've moved uh uh the customized templates from uh the existing site. Car repository into the sample driver.

H

Oh, so that talk is actually from this ripple. Yeah.

C

Yeah yeah, yes yeah, I mean right now we do a manual copy, so they just has worked on it. They just hear tea party, so um he he every night he's running a github actions job if it's free uh to clone this repo and then take the docs out and then great yeah yeah. Unfortunately, he can't join us during these meetings, but but he's been a great help. um I thought I'd mention it yeah and and along with his main job he's also a lecturer at northeastern university yeah.

H

I just see that he shows here.

C

Yeah a lot of time like hey, how's, it going and he'll be like uh well I'm evaluating tests right now. Let's see I'm.

H

Sorry, okay, that's how you had okay! You know. I said he has time to be a lecturer.

C

As well he's one of the special people like, I think.

H

I thought you did, they have to be like on call or something.

E

Right, yeah, emergency guest lecturing.

C

Yeah all right, um okay, so uh so we will update the docs. I think I think that's very important. um The next thing is api review. uh I think I think we should focus all our efforts on on getting this through um so in terms of what is needed, so we're all in agreement about what this api should be for. Alpha jeff, as of yesterday, has updated uh the cap to reflect the latest changes.

C

uh All all that's left is for tim to take a look and uh well ask us questions if there any and then and then help us move this forward um and and that's what that's, what that's, what we'll you know I'll say in the email and that's what that's what needs to happen so, do you all think we should? We should invite him for a call like a video call, the idea being we can. We can quickly finish it if he joins um rather than it being this call, you know, maybe you know we could.

C

We could make the time such that it works for him.

A

Yeah I mean a zoom call is, is way better and and it could be this time- slider anytime slide. I mean okay, okay, let's aim for that uh yeah and as long as long as it works for him and like somebody who's who can push the api, I wouldn't try to accommodate anyone else's schedule. Yeah.

C

A

What matters is getting him.

C

Right right, I'm going to make the time regardless, like even if I have other meetings I'll push it um yeah. We have only like two weeks, so it's high priority: okay, um okay! So now that that's out of the way, so uh chris brought up a really important point uh last week or this week, uh and I just want to bring it up and make sure we're all on the same page about this, it's the idea of uh status versus spec.

C

I don't know if we talked about this, but uh tim mentioned it to us uh uh some time ago- that uh um for any resource where, if, if the, if the field, if any field is updated by uh the system, um uh it should be that it should be status like like, for instance, in case of pods like pod, ip is in the spec, but then it's always filled in by the system. It's filled in by kubernetes um like, like you know in a more conceptual sense shouldn't that really be a status field.

A

um Well, there are some fields that could be in principle filled in by either an end user or a controller. Those have to be part of the spec, because but yeah, something that is definitely going to be filled in by a controller, should be status all right. So let's talk about.

C

That so um so take, for instance, a bucket um in in market is created by uh cozy, and it is not created by the user unless it's the driverless use case where the admin goes and creates it manually.

C

um We have inside of the bucket status we have bucket id, which is the unique identifier for the bucket itself, and and really if, if an admin is going to go, specify the bucket manually.

C

Is it reasonable to say that, since they're trying to describe the status of the bucket, that is the current state of the bucket, which already exists outside of kubernetes, somehow provision manually whatever? um Aren't they representing the state of the bucket.

A

Yeah, so so maybe I said something confusing, so you have to think of it in terms of like a client and a server where the client specifies the spec and then the server sees that and then goes and does something and then returns just returns. The status um so like there are situations where there's objects that, where both the client and server are just different controllers talking to each other um so like in that case, the the thing is acting as the client.

A

You know something that an admin might do, or one controller might do, would be filling in the spec of the bucket object. A user will never see the bucket object, because it's not namespaced um so yeah that you would fill in the the spec there, like one controller, would fill in the spec and then there'd be another controller.

A

That would be responding to that object, which would be the sidecar and it would see the spec and then it would fill out the status.

C

I see I see where you're coming from so, even though it's it's filled by the system, you're saying in this case it's going to be a part of uh spec.

A

I think if there's only one controller acting on the object, then its job is to fill out the status. If there's two out controllers operating on the object, one of them is like a requester, and one of them is the responder, and the requester obviously has to fill in the spec to make a request, and then the responder or the controller that is waiting for those objects sees that request and then does something and then fills in the status to reflect what happened and that's why you're saying client and server like yeah.

C

A

I hate the name client server, because it's a bad it doesn't fit in kubernetes, but yeah like there's a requester someone that creates the object with some values.

B

And then there's.

A

Something watching for those objects that will do something in response.

C

Fair enough, um what are your thoughts on this.

B

uh Can you hear me okay, yeah, yeah yeah? I think.

C

That makes sense.

C

Okay, so does that mean uh then that this bucket id, which we move to status, should it go back into the spec?

C

H

Should have it in both places? Well,.

E

That's what I was gonna ask: does it could? Could you have the same same content even the same name, but one under spec, which is the declarative side and one under status, which is state of the world? Is that yeah.

H

That's what we have yeah, that's for the snapshot. We have something similar yeah it's. Why is the for your? It's like your? What this is your brown, uh what um uh yeah brownfield case? So it's like static provision case, so you'll have the id ahead of time, so that id will be in your spec to start with uh and then in the status. You will always have this field because in both case, this field should be.

E

There's examples of that being done elsewhere in kubernetes, where they have the same field in spec and status right.

H

Right so snapshot have something similar me. Actually, uh oh.

C

H

C

A link that I can go to let.

I

H

D

C

So you're saying on respect, we have a source, we have a class name and.

D

I understand what.

H

Is this under the snapshot handle and yeah? You see that snapshot handle you do I don't know if you find all that miaji share this.

D

H

We've put this in the chat.

H

Right so that's the this is the this is the spec and then we also have the same thing in the status. Let's see.

G

Yeah yeah, it's right. There.

C

Same same yeah, 368, yeah, okay, the csa snapshot id of the snapshot on the underlying storage system. I see this is like our bucket id yeah.

I

But the key is that the one.

A

In the status would be filled in by one actor and the other one.

H

Right not not, at the same time the status yeah. You can't.

A

Have status button so the responsibility for the two fields is split.

H

C

Makes sense so in our case bucket id would exist in both places and uh in in both cases. You know either the admin fills it up. uh Well, no in case of the spec, either the admin will set up or the central controller fills it up, and the responsibility for the status is always done by the sidecar.

A

Another sort of key observation is: it is impossible to create an object with a status attached to it initially, so anything that has to be specified at creation time has to be in the spec, because the status always starts off blank.

C

A

Mean it's a sub resource, so you can't you literally can't.

C

Edit, it only only to keep cdl, you can do it through the api.

H

Yeah api, you can do it, you cannot do it. You keep cuddle, you cannot it's going to remove it for you right, yeah, buddy, you're not supposed to have the status when you're doing your credit. I.

A

Guess I guess the key is to realize that, like it's, a sub resource so like you can access it independently of the main resource and many controllers actually do that.

B

A

Understood yeah, let's say: there's.

C

An update status quo, I guess.

C

Interesting anyway, so okay that clarifies that uh so we'll update the api. That also means we have to update the cap um jeff. I know you're working on the cap, uh you you take care of that right.

E

Yeah I um we're talking about bucket id in the bucket instance, um definition right in a bucket resource right. Yes, let me make a note. I can do that, and this is a good time to advertise reviews on the cap, especially we won't very much if we're going to get some of tim's valuable time.

E

I want the community to support the kep pr, the latest one that has a bunch of commits I'll squash later, but they're they're separate now for your own benefit, um but we have to be an agreement with that pr, because that pr for the cap is going to be the basis of tim's api review and it's not getting it's not getting much love right now, we're not getting many eyes on it.

C

Yeah agreed um so so um so the you know key members from each of the vendors. If you can go review, like all of you, should go review uh the cap and then leave a lg tm on it. uh You know you don't need to have permissions, but just typing in slash. Lgtm is going to count because tim is going to see that and he's going to see that the community approves of this. It's easier from. You know that is more convincing than us saying community approves of this.

C

I agree, um and it would be good if you, if you did that as soon as possible. uh I'm I'm sorry, I'm I'm being a little pushy about this, because we have very little time and yeah yeah the cost of missing.

E

This deadline is very expensive, more important than any politics about this is that we really want it to be good and, um and collectively we're going to get better ideas from the whole community. Better points of view, different dimensions of thought. So really we we do want more eyes on it, so that we can make sure that we have the best api possible.

C

C

C

So I would actually like people to sign up uh uh ben. Can I count on you to uh take a look at the cap and if everything looks good, uh you know, leave a review yeah I'll um I'll put an lgtm on it after reading, through it, okay and uh vyani, could you also, um as a representative of uh take a look at it, yep? Okay, perfect, thank you and uh jeffrey jeff. You wrote this, so are you biased yeah? Yes, I'm biased, so I want other eyes um fish.

C

Can you uh take take a look at the cap and leave a review uh here at the time? Yeah sounds good. Thank you so much okay. So there are. There are other fields too. So one was the bucket id. The other was. uh Let me see this in the history.

E

Oh there's another one.

C

Okay, are you ready jeff, I'm ready? Okay, the other is uh inside of bucket access. uh The fields are minted secret name and account id.

E

And so and we're going to change it from minted secret name to just minted secret, because it's a ref right.

C

Right right, so yeah, um so so the thing about minted secret is uh the csi. Adapter has to go uh fetch this minted secret and then uh put it into the uh put it into the workload. The part um the thing about that is the csa. Adapter has no clue which namespace this minted secret resides in. um Is it a is.

A

It a local secret, wrap or a global secret graph.

E

Local provisioner's name space.

A

No, I mean I mean like like in the in the kubernetes types, there's a local ref which doesn't have a name space field, because the namespace is implicit and then there's a secret ref, which has a namespace field. And can it can point to anything.

B

In the system yeah, it's it's a secret ref, it's a regular secret ref. So it has.

A

Been it has a namespace build.

B

And you know where it is.

C

Now, if it has the namespace field, then we know where it is, but but with the current implementation we didn't have it so correct.

E

Implementation just had a string for the name of the secret.

A

E

A

To decide if it's a local ref or a global ref, I guess.

E

A

E

A

E

A

E

A secret not a pointer to it.

A

And, and who creates those secrets, the sidecar yeah yeah um and is the sidecar intended to create them in a single namespace per cozy implementation? Or is it meant to create them in the in the name space where the the end user is running his workload like? Where are they supposed to be.

C

All right, good, someone's good chris.

B

Jeff got it.

E

Well, if you didn't hear it, then, because I'm sorry chris go ahead, christian tell them where the sidecar puts.

B

I was just saying it creates a secret in its own name space. So wherever, like the sidecar lives, it creates it there.

A

Okay, so so, then, the site artist needs to know what namespace it's in, so that it can populate the namespace field of the secret graph and.

B

Then in cublet we'll always know.

A

Where to where to find it right.

B

Yep we used like the downwards api for that.

D

Yeah makes sense.

C

Yeah yeah, so we use that, to uh you know, put it into an environment variable and then um leave it right from and set the site card.

E

Yeah yeah, so that was one of the changes. um Can you repeat that so I wrote a note that said: keep the ba.spec dot minted secret and add ba.status.net secret. Is that correct.

D

E

Okay, so that's tells me that the minted secret could be say added manually by an admin in some scenario where the admin has to manually create a ba, but it's also cozy as updating the secret that it gets uh from the driver. The the sidecar is updating it. That's why we have it in both spots right.

I

um Yeah, I wouldn't call it minted in the spec, because.

A

It's not in this pack.

I

But it isn't the status, so I would give.

C

Static static credentials or something static, secret, credential, secret.

E

J

Static secret static credentials, secret.

K

That's long I mean, I don't know that you need any.

A

K

At all, you could just have secret.

E

Yeah, I know general community likes shorter names where we ca, where possible, we're reasonable.

C

The name of our project is contain object, storage, interface,.

E

Yeah it's long, but it's also cozy.

A

But I mean the purpose of making.

E

The name longer.

H

B

To disambiguate.

A

It from something similar, there's nothing similar to disambiguated from it, doesn't need to be wrong.

C

It meant it's secret name like minted secret.

A

But it's not minted if it's not.

E

The status will be minted secret, so.

C

If I write, if I were to see this uh see this resource right like where to see the definition for bucket access- and I didn't know how things work, I would see two secrets- and I wouldn't know what was what, but by calling it static credentials secret. It's very clear. What's going.

A

On I don't have a problem with.

K

Someone who hasn't.

A

Read the docs, not understanding how it works. I mean it's at some level you have to understand. Some of you have to know. What's going on.

C

um I mean it also helps to make the system a little intuitive.

A

When we're talking about the brownfield case, though, I'm realizing even.

G

B

A

In this status is confusing, because if it was passed in by an admin as a pre-existing secret, then we'll copy that to the status and it will be a pre-existing secret, not a minted secret.

K

C

It came through the spec, so I think in the status it makes more sense. That's a good point. What would you say about calling it just secret in the status field.

A

Yeah, that's that's.

K

A

Unless there's going to be a different.

K

Secret that we have to disambiguate it from a short name.

E

Works, okay with mint is, is just superfluous. It's you know. Obviously it's in status, so cozy is generating or you know putting it in there, so it doesn't have to have minted in status now. What did you guys land on for the spec secret name, ba spec secret? It could also.

G

E

You're, okay ben with the I know, there's examples in snapshots where the field name is identical between status and spec. Is that what we're saying for secret.

A

I think so I mean you just have to you have to imagine.

K

A situation where you're using it and say does this.

A

Does it feel weird like like mint.

K

It does feel weird if it's a pre-existing.

A

One, but just calling it secrets like okay, I know what that.

K

Is yeah status, calling it secret makes sense to me. I think.

E

We we should do that, there's precedence and then, like you said at some point, you do have to read the documentation.

C

You know in case like and give respect, do we want to call it a secret? Is that what you're saying.

G

C

um I mean some people: why not here's.

J

C

I mean I mean having the fields be more intuitive ends up in a position. It puts people in a position where they're less likely to make mistakes, say. They've read the document which they've forgotten about.

A

C

This is an object.

A

That ordinary users would never touch the system creates these like you're, only touching it if you're doing the brownfield case.

A

Maybe you call it pre-existing secret or existing secret or your status static.

J

Secret, I don't have a.

K

A

Problem with so, but it would have to the key is if it's present it means the admin provided. If it's absent, it means that it just came from the system.

C

Yeah, that's that's where I was coming from when I said static, credential secret. I know it's a little mouthy, but maybe you know something you can help me uh make it simpler. Is everyone, okay, with static secret.

A

I'm not opposed it's fine.

K

Sound sensible.

E

Static, okay, okay, so spec ba spec will have the field will be called static, secret and ba.status. The field will be called just secret.

C

Okay, so one more thing: can we call it just static credentials and then have it? The type be a secret reference.

E

That's that's fine static, cred, credential.

D

H

So when you say.

D

Static, what does.

B

H

That you're importing it is going to be changed or something.

C

Yeah, so it means that the credentials are already created and you know they're going to be for the lifetime of the bucket access.

H

Should that be called like immutable, instead,.

C

Generally, they call it static credentials because it came from you know. It was pre-created by an admin like hand created. um I don't know.

H

I thought we are actually trying to uh not to say static because, like for snapshotting um we're not even mentioned in static, we say pre-existing pre-existing snapshots so every time I have a static there and I was asked to change it actually pre-existing. It's.

E

A little redundant because there's not a dynamic, maybe just say credentials and it's a pointer to a secret. Oh yeah, that's true!.

A

Credentials also works yeah.

E

Yeah stack, I mean saying, pre-existing or static, is a little superfluous because obviously you're pointing to something. That's there or you're filling it in with something that exists or.

A

Yeah so, but but crucially, in the normal case, it's absent and so correct. It's a signal that oh, this field is gone. That means there was no pre-existing secret and the one that got put in the status was from cozy yeah, so so that the the case when it's absent is actually the most interesting case from from a naming perspective,.

C

E

Yeah, that's fine and um we're gonna. Have these? The type of these fields will be uh secret. Ref right.

C

Yeah yeah, both of them so ben, are you saying it should be? It makes more sense to have that qualifier for the credentials, rather than just calling credentials.

A

I know I'm I mean credentials sounds better than secret now that you say it as long as it's still accurate um uh and yeah a qualifier or not as long as.

C

Is static credentials better than just credentials or pre-existing credentials better than just credentials.

A

Probably yeah, I have a feeling that whatever you picked, your reviewer will tell you to do the opposite. Like being said, if you.

B

Say static, they'll.

A

Tell you make it pre-existing if you say pre-existing they'll tell you make it something else. I see you know how people are when they review they'd like to nitpick.

G

C

um Yeah yeah, it's okay, we'll go through the grinds. um So let's, let's call it static credentials. Then.

C

You want static in.

E

The name in the spec yeah.

H

No, no we're asking not to use the static phrase pre-existing.

J

H

Yeah, I don't know if that that's too long, but I'm fine with previous, because if you search all the documents about snapshots and there's no static mentioned anywhere, it's all called pre-existing. Now.

C

What was that field for like what was the? What was the field being called static?.

H

I don't know what it was the reason I just every time I have that it's saying. Oh, we shouldn't call that.

E

Is it pre-existing with the e being upper case.

C

H

uh Not upper, I don't think it's just like.

E

Existing is one word all lowercase.

H

I think the lowercase is fine yeah. I don't think in a resolution. Well, you have.

E

Two lowercase next to each other, with pre-existing that so with.

H

That hyphen right, you have a high hyphen in between you.

E

Have a height not in a field name dude, not in the field.

H

No, oh oh you're, saying that: why do we do that in the future.

E

What are you doing snapshots for this field? Name, we.

H

Don't, oh, I don't think we have that I don't. I don't think we call it pre-existing in name. We just call it a snapshot handle because we differentiate that. So, if you look at our experiment, explanation there right, so you can only have one of those two fields. uh One is for dynamic. The other one is for pre-existing it's very clear. There's no confusion there. Oh.

C

You're calling one dynamic: okay, okay, no.

H

But no I'm saying the name is not. We don't have dynamic in there, but I'm saying if you look at the source one source, you will only specify that in the case of dynamic provisioning, the other one like the snatcher handle. You honestly specify that in the source, if it is a pre-existing, so so in our case this is very um clear. You can only have one off but with so that's why we don't. We don't really need that in the name.

C

Okay, so you're saying we don't even need to say that just say call it in both cases.

C

Yeah we can, we can become symmetric with uh snapshotting, uh I'm fine with this um purely conceptually speaking it. It seemed to be uh better to call it pre-existing and uh created or generated. I guess no, even that's not true, because in case of driverless it's not generated so the status. Let's just call it credentials, I think we're all. On the same same.

E

Way so we changed it, so I had written down that in the status we were going to call it a secret you're saying now in status. You want to call it credentials.

D

E

All right- and I agree with that.

E

So status it will be called, you know, status, dot, credentials, plural and in spec it's going to be spec, dot credentials.

C

Yeah, that should that should be okay. That should be fine. I mean if we wanted to clearly say that uh this was pre-created, um I mean you could say uh pre-existing or static, but I guess.

J

I guess it is in a sense, no.

E

J

E

You look in specs all the time when they reference other objects, like storage classes, bucket classes, we don't say pre-existing in there right.

J

E

It's just assumed right, fair enough.

C

So it found credentials in both cases. Okay, I got it great jing, uh that's cool, that's! Okay, right! That sounds good right.

H

Credentials yeah.

C

Yeah, okay, great um all right, so let's go back here so that was for the seek. Those are the credentials now. Let's look at account id, so account id is needed as a separate field, because we need to know the handle for the account that uh you know that is going to refer to the uh to the user. That's actually going to access the access, the bucket uh in case we need to revoke access. uh This is this is what will be used as the handle to revoke access.

C

So so, when creating a bucket access manually by hand, the admin would have to fill in the account id field, so I think account. Id also should have two copies bucket and market access. Spec and bucket access status are.

E

We talking about the b instance or the ba here, the ba, that's our thought. Okay and so you're saying we're going to have ba.spec.account id for the same reason. We have a credentials in spec and in addition, since account id is going to be filled in by cozy, then we will also have it in the ba dot status.

E

Right, okay and it's spelled account and then id both uppercase right got. It.

C

Right, I cannot believe we've spent 45.

E

Minutes so far, well, you know what it's often seems wasteful, but names are really.

J

Are hard to come up with good names? Well, it doesn't seem wasteful at all. I'm just surprised, you know it's a good thing.

C

If time goes by fast right.

E

C

Yeah, okay, so uh let's make those changes and update the kip. I think uh I got.

E

Them noted okay. uh If anybody on the call comes up with an argument against the name choices, please just uh ping uh put it in uh sig storage cozy um later today, I'll make these changes.

C

Yeah yeah any discussions: please bring it up on slack, we're all always there, so we can. We can help answer them, so uh all right so so to follow up on this. uh We also need to update. uh Let's see, do we need to update the spec in any way for this?

C

No, no. The spec remains, as it is. Respect is a grpc spec and I don't think, there's any changes. Neither there we do need to update our controller and sidecar to follow this new convention, so that needs to be taken care of okay, and also this is good because it gives us a way to disambiguate between a bucket, that was that already exists and a bucket uh uh that that we need to provision like from the sidecar side.

C

There was no way to tell this before and- and there was some issue with not being able to tell um with cleaning up, I believe uh I forgot what exactly the issue was, but uh it will come back up. um Okay, so so I think we're in a good shape um in case of the api.

C

uh Let's, let's go to: um let's: let's go to our project management page and, let's see what's left, let's see alex.

C

Right now, okay, uh so all right, let's talk about development, um so so, while while tim is going to review all this, it is also important to make sure we're on uh you know we're continuing development, so uh we don't have health checks implemented for any of the um cozy um resources, um so that needs to be implemented.

C

uh Krish. Are you working on it right now.

B

C

Currently now uh so so is it okay? uh If uh you can someone else, take up the task, would you do you want to do it.

B

C

Would this require a change to the.

B

C

Think sorry, it would just.

F

B

F

Already have like the provisioner.

C

Already working on uh emitting events.

B

C

That pr should be.

B

Up later today,.

C

Okay, so uh can you talk a little bit about that because uh do we emit events on the pod that's requesting the bucket? So if I were to do cube cpl describe part, would I see the event saying bucket provision then and bucket? uh You know not provision.

B

C

That's exactly it so uh we get the pod name and finding space.

I

B

I

B

For publishing, and so we use that to uh emit events onto uh the pod when we're provisioning uh or we're.

F

Trying to mount the the secret.

B

F

There's never errors. We just like.

B

uh Have warning events uh that.

F

Say, like you know, whatever condition is.

G

B

Then we just have one event that.

I

Says, like you know, everything everything, okay, basically,.

B

I

The same process happens for uh on publishing.

B

C

Everything gets unpublished.

B

F

Someone had a question: yes, uh just on the the health checks, um the health check for a provision, or would it make sense to adopt the approval request that csi has, instead of relying on the get get info.

C

Call so sorry, chris did you you're asking is, is it? Does it make more sense to provide an endpoint from from inside the set car rather than to call get info.

F

Well, so in in csi, the there is an explicit probe request with a pro response that a driver can implement, which is called into by the sidecar to expose the health of the pods, which includes the side car as well as the actual csi driver is the grpc implementation.

F

So should we do this same or rely on the get it for a call which csi also has great.

C

So the difference is, if you, if you were to uh you, know if you want to do a health check on the driver itself, you'll need to do the grpc api for it.

C

um If you want to do the health check for uh the the sidecar, which is not the driver, the sidecar itself, then you don't need that now, given that the sidecar and and the driver have to run in the same part, and and given that uh you know the the pods and sorry the containers in the single part have to share the same life cycle.

C

I think it's okay to say uh you know just have the health check in in just the side, car and- and you know we can- we can punt the uh driver level health check uh for the future if needed,.

C

Does that does that make.

F

Sense: uh well, yes, if the sidecar is not doing any grpc call and to to handle a health check request right now,.

C

Yeah yeah, that's what I'm saying, but we don't need it yet. I don't see a good reason why we need it.

F

From krish is that it is doing an actual call into the the driver. Oh is that what's happening chris.

B

C

J

Nothing's happening um so like it's still open for design. I was just.

F

Thinking about basing it off like you know, the liveliness pro for csi drivers.

B

F

Of the same idea where we have you know, I think those.

B

Ping, um let me check, I think it's like okay identity.

D

B

Wait, let me see.

J

C

B

J

B

C

I'm referring to okay, I don't think I was saying. Maybe we don't need that so so. Yeah.

B

I think the problem can be optionally. It's.

F

D

Enabled I think.

B

E

Like that, okay.

C

I'm not sure, okay, okay, so let's let's go with that. I I think that's that's a better way to um I. I don't see a strong need for the driver itself. You know to have a health check endpoint. I you know if there is a use case, obviously we'll implement it. The effort is low, um but I think it's okay to just have a healthy for the side car, because they're always tied together.

C

If the cycle goes down, you you want the driver, I mean the driver doesn't work basically, so um I think one health check is enough having it just in the sidecars, okay or or like csi. Does it's csi has a separate uh uh liveness probe um like like a health check, uh microservice.

D

C

B

C

B

Adapter right now.

D

F

Yeah, I actually wonder whether we could simply reuse this one in various drivers. As long as the protocol is implemented by the cozy grpc implementation.

C

um I I think that should work I mean, but we were saying we don't we won't. You know we won't do the grpc thing, we'll just add a slash healthy endpoint to uh you know to our to our driver.

C

We don't, we don't need uh the liveness probe.

F

Right so then, you basically you're saying that every driver needs to implement an http endpoint as well. Next to the grpc one, no.

C

Not the driver, I'm saying that if the sidecar has it that's good enough.

C

Because the life cycles are tied together.

F

Didn't that be enough.

C

Why is it not innovative csi?

C

I don't know I'm asking you what's the use case, I don't see a strong use case in case of drivers. If you tell me what it is, then we can talk about.

C

It does anyone know ben or shane, like do you know why there's a separate pro call in csi.

A

I think that the the idea was to handle cases where the driver itself gets wedged.

A

I mean like liveness rubs in general, are kind of funny, because you know it's it's it's like you can just see if the process is still there and if it is, it must be running but like it's meant to detect some sort of a deadlock or a live lock, where you know that you come in through the http endpoint and you actually maybe perform a slightly deeper check to say yeah. I'm still processing requests such that like.

A

If, if there was a state where you could be running but not processing requests, you could fail your liveness check and then that would be a signal to the higher level that I need to bounce. This whole thing, um maybe.

C

That's not yeah, that's actually, I would say that's worse than actually having it fail.

C

Having what fail having the whole system fail, because what we're doing by doing by doing this is we're having silent failures like like every time, let's say: there's a there's: a live lock or a deadlock. uh What we end up doing is we restart, so it contains. The deadlock goes away, comes back up and let's say it happens again uh and it'll keep spinning like that and unless you're looking at the processes, you're, probably going to miss that uh it's actually going down and coming up.

A

C

A

I mean it's, it's it's the same justification as why you would have a liveness probe for anything in kubernetes right I mean the idea is sometimes you want to programmatically deal with things deadlocking.

A

If you don't want to you, don't implement it, but it's a mechanism that you can use.

A

You know just it's just another tool in your tool. Chest.

C

Okay, so I think I think yeah, I think I think, to begin with, uh let's just have a slash, healthy endpoint, like like our server listening to slash.