Kubernetes Storage SIG, 19 Jan 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Storage 20170119 [Partial Recording]

Description

Kubernetes Storage Special-Interest-Group (SIG) Meeting - 19 January 2017

Partial Recording: First half of the meeting was not recorded due to technical issues.

Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.i826834fjflp

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

Moderator: Saad Ali (Google)

Chat Log:

09:15:12 From Luis Pabón : If I volunteer as a revier, do I just add my name to the column? Like #4 ?
09:15:22 From Luis Pabón : reviewer*
09:17:45 From Matthew De Lio : Luis, yes, please feel free to add yourself to the spreadsheet
09:18:50 From Luis Pabón : thanks! :-D
09:19:10 From Luis Pabón : Do we need to have a repo at all?
09:19:25 From Luis Pabón : Isn't the point of an external provisioner to leave it to the caller?
09:20:06 From justinsb : One repo seems like it leaves the option of splitting into more repos later if/when needed
09:21:11 From aditya : Is there a design doc/repo for external provisioners I can refer to ?
09:21:56 From Luis Pabón : github.com/kubernetes-provisioners/...
09:23:33 From eparis : do I need github.com/kubernetes/provisioners-library/ and github.com/kubernetes-provisioners/ or should I just put both parts in a single repo?
09:24:51 From eparis : +1 justsb "github.com/kubernetes/storage"
09:24:54 From eparis : justinsb
09:25:26 From Luis Pabón : +1, but is there a testing CI for that?
09:27:14 From Luis Pabón : Should https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md get updating with a TESTING section?
09:27:21 From eparis : only reasonable/easy CI is travis-ci. which really means unit-ish only...
09:27:53 From eparis : I haven't seen any team outside of core kube solve e2e testing CI :-(
09:28:48 From justinsb : oops has e2e outside of core kube
09:28:52 From justinsb : oops… kops
09:29:04 From jeffvance : storage is working on it better e2e, but progress is slow...
09:29:04 From Luis Pabón : Thanks Ardalan! Good to see another ATG guy :-D
09:29:17 From justinsb : It is complicated though (zmerlynn was our hero here)
09:29:25 From stephenwatt : Have to run to another meeting unfortunately. I’ll follow up with Brad afterwards
09:33:32 From justinsb : I would probably hold off rebasing for a few days… things are not happy

A

I think we should start thinking about those.

A

Well, I think the hope might go with this was to fall of 2017, but I think we just didn't have enough family for that meeting to do it. So maybe I will start another tab and change this one to just 1.6 planning, and we can start you know slowly. I think it makes sense. You just gather idea of. Even if some we don't para ties them or anything in from exporter.

B

So the one thing I am kind of curious about is line 19, the containerized mounts to GA yeah.

C

B

It feels to me like a big feature. I know that there was this like last. Second 15 push to get something done on ji. Ki right mom. Is that something we need to call out as a feature I mean I feel like we're going from a not alpha, 2 GA and one really. Yes, we should call a native.

D

B

D

B

Effects tons of people and is a pretty big interface. Lots of people are eventually to use yeah.

E

B

Made my guys, as we can see, sign up for review nice.

D

Okay, let's break that and put it I'll be part of the 1.6 milestone on and one more items that I remembered was that we are. We have default on George classes for quad riders.

D

The code for this has already been checked in, but we need to make sure that it is communicated widely that this is changing fundamental behavior in the storage sack in particular, it used to be that on GCE and Amazon, if you created a persistent volume claim, it would bind to exist in existing persistent volume objects, but would be storage classes that now get installed by default on both both of these cloud providers.

D

It will result in automatic, dynamic provisioning of new volumes, new TVs instead of binding with existing TVs. So this is a fundamental change that needs to be very widely communicated.

D

It also I'm not sure that the experience for being able to disable this behavior is what we want at the moment right now. It's a addon llamo file, cluster add-on, llamo file, that is on the master, and so, if you want to disable this feature, you have to go and modify that file, especially first clusters, where you may not have access to the master. This seems like a very poor user experience, so this is probably something that we want to improve before this goes out.

D

It would 1.6 I think, there's a bug open tracking this issue I'll see if I could dig that up and add it in there as well. But I want to make sure that's trapped in the spreadsheet to a.

F

Question on the number for external provisioner, so is there a plan to who's better? The better to external original is going to be hosted in the repo going further beyond the incubator, bread.

G

That's a good question that is also a big agenda item. We have I'm with the end I'm going. Let's go left right now, I get so we have about four or five external provisioners that are in the pipeline and we've come pretty much finished, but we don't have a home I. The current breakdown of the in effects external provisioner that we're using its kind of our reference implementation. I. The repo name, is NFS provisioners.

G

So that's not really a good generic place to hold external provisioners, and we would like to break it out into a very distinct library and potentially have a different brief. Oh, where we host the channel provisioners. But we wanted to bring it to the cig and see what everybody else thought there should be synced with that.

B

I mean it feels to me like we have well infinite choices, but to reasonable choices would be an entire repo just for a goal eng or potentially other language.

B

Helper library, as we mentioned, the NFS provisioner, has a whole bunch of golang library code and then the actual NFS provisioner. So we could make the library its own repo that gets fender din to individual provisioners.

H

B

Could just make an external provisioners repo that has the library in it and a bunch of provisioners. I don't know what people like better I sort of like the one repo idea that has the library as just a part of that one repo and we have a bunch of provisioners in that repo. But I, don't know how much that helps us yeah.

F

B

F

You have all the Provisionals in that repo. Does it mean that vendo writing a new provision has to go to a code review process and go to committing to this repo I? Would.

B

Imagine if they wanted the community to help them maintain their provisioner than yes, but people who wanted to do it entirely on their own would just make use of the library portion of this repo and maintain the code themselves wherever they wanted. It.

I

And to be clear, the external provisioner is not a flex provision right, a flexible manner. No, so the exported provisioner also as a supposed to be deployed as a as a pot right like I, say it would be rendered in in in somebody else's code. There's.

G

A library piece of it that the works for been during the end, but yes good, run another pot. It can write as a standalone executable. The idea is that we have like a controller piece that could act as the library and then it calls out when it seems be non event that needs to be provisioned. For so it simplifies the you know. The coating off of an external provision arias active HD, write a provision that said: can you get the remainder, the library for free, ah ok and.

G

You miss stuff that we have in the pipeline is around. You know minneola and different, publicly available file system type, so we thought others may find useful. These aren't necessarily a proprietary file systems. We wanted to put out there, it's just stuff, we thought other people like my share and those are the library piece of it.

B

So it's kind of two parts right, there's this library that we've seen that lots of people writing external provisioners will want to be able to make use of, and then there are actual external provisioners that we would like to make available in the community and there's a question of. Should those two pieces be arranged in repositories completely separately or should we just kind of wish the library- and you know, public, open source, community driven external provisioners, all in one repository I, don't know if I have a strong opinion, I.

I

Mean aside from the common code that that the helper code to create an external provisioner read the facility or the the features of an external provision is basically vendor, provided so I don't see that being and different than something like a you know, something like being being used as a flex where we're not asking people to we're, not creating a flex repo.

I

We just you know we depend on the fender to provide the their their their code in trust that works.

H

But I guess the what is the better provisioners that I maintained by the community and that our provisions have been gained by vendors and I guess the question is about those but maintain like a miniature. If.

J

So the idea of our form some infrastructure, a crowd, I'm the eff- that is all listen. Most people will have to use my finger community-supported lethal, what it means much beneficio they are in each vendor, you promote they all.

D

So I think the key takeaway is that, even if we have a repository for these external provisioners it doesn't it's not necessary for vendors to use that repository. It's just a nice place to be able to share code libraries and for any common community, maintain provision Ares, they could be maintained there. So it's not. A requirement is just nice to have ya.

F

1 comment on that is, if we can separate out the library part, because right now we have a POC with where we vendor in the entire NFS publisher, and we just use the controller. So if you can submit that out, that will be great I.

D

Think that's the plan right red. Yes,.

H

It's were working towards. Another question is whether the flood LOL growth CBI is go. Ladies love a depository, also to come before the city for the storage management. That's out of the bay. That's a good question.

D

If we want to future-proof it, we should call this repository storage storage, plugins for Cooper Nettie's, or something generic instead of being provision or specific provision is just the first step to getting out of tree.

K

I mean it seems like there would be no objection, I think they're, creating a crew benetti's for storage, Rico, total destruction there. If we decide we need more repos, then we can make the case and I think people would be open to that. It feels like making the cake in advance is just front loading work now.

D

I think that's fair Brad. Do you want to take on this responsibility of setting up the new repo? Yes, cool, yeah I like the kubernetes flash storage idea, and then we could have sub directories starting off with jizz provisioner and then add in more as we need.

G

Okay and I'm going to look at probably renaming the NFS provisioner for this. So we don't have an effect for visionary kit will just how's that in the same repo, okay,.

D

All right any other comments on this.

D

All right, let's move on so next comment, is just a reminder again that all 1.6 features should have a design doc and, in addition to that, something me and Aaron have really been trying to hammer is testing.

D

Let's make this part of the process, instead of something that we think about after the fact right now, Aaron and I are planning on going through the bugs that we had in q4 Flast year and seeing if we could get a list of new tests that we can add to ensure that we could prevent regressions in the future for those bugs, but to prevent this kind of thing, let's start being more proactive about testing. So one of the steps towards that is along with your design docs.

D

Could you please also create a test plan doc to identify what kinds of testing is required before you start development, and that way, your features that you deliver should also include tests along with the code or have the test written before the code. We want to get out of this cycle of like yeah, we'll write tests later, which never happens, and, and it becomes very difficult to maintain the code.

D

um In addition, very welcoming I was.

L

Just going to add side, sorry, I'm late, that if people are questioning what needs to be added to that or need examples, let me feel free to reach out to myself Junko staff answer side on. We can help point you in the right direction.

D

Yeah thanks Erin, so the final item there is to keep an eye on what the deadlines are for this milestone for 1.6 important deadlines to remember our this coming Tuesday January 24 is the features repo free. So please make sure if there's any features that are going in to 1.6 that they're populated in that features, repo and the next state to remember- will be februari 27, which is a monday, and that will be the featured complete date.

D

That's when code freeze goes into effect, so any code that you want to be part of 1.6 should be completed by then so a little bit more than a month left for coding. Next up, we have netapp.

D

What's going on here, netapp's provisioner ah ardoin. Are you there yeah.

M

I'm there can you hear me.

D

M

Okay, this is just a quick announcement that meta relief is external provision or a few weeks ago, I talked to our design in the first to face to face big meeting. So it's a out of tree out of process, XML positioner that works very similar to that affects privilege and I read has a little it has. It doesn't rely on 2 flex, plugin api and one of the cool things about it is that a single instance of the provisioner can support different factions.

M

They cost different source platform and we've also experimented is from that app storage and it works fine. So if it interests you guys, you can check it out and see how you can integrate with your source systems, and you have the link it's on that up. Github.Com / net up, try them, and if you have any questions, please feel free to reach out to us.

D

Nice thanks hard one. Anybody have questions for him.

M

D

Right, moving on waman, you have out of tree provisioner, repo hosting I, think we started talking about this yeah. I think.

J

The back is already aggress, that's quickly, stuff, okay,.

D

Nobody signed up for any design reviews today, so keep in mind in the future. There is time for doing design. Reviews feel free to add that to the agenda whenever you want to, and there are a couple PRS that folks added off that need attention, one in particular 395 35 added by port works on and it looks like it's. The port works, vol plug-in very cool I will assign myself and rootfs to take a look at that anybody else that may be interested in it. Please feel free to jump in and.

D

Add akhiya: do you have any comments on that TR I'm.

N

Just waiting that it needs a rebase though, but I was just waiting if I have any more gum and I get any time as ever fix those and then venkatesh.

D

Ok, cool we'll try to go we'll, try to take a look at that and glad from delhi and see posted about 39, 38, 924 air.

I

Route of Ruatha started to look at that, but we could go, went back and did some work and I just care eyes to look at it again. I think it's at some point: it's testing needs to be enabled. Graphic is still not enabled yet.

D

Gotcha and is Rita festive the person who should be higher as.

I

Far as I know, yet that's fine yeah. He has some suggestion from last review and I got those taken care of, and one more so and just to be clear, we'll talk about features being added and I design, doc, etc. Does that apply to the sort of work or modern.

D

Plugins technically, yes, that's a very good point: volume plugins are considered new features, so they should have a features: repo entry, so both port works and this schedule a--oh volume plugins- should both have have an entry in the features Rico. The reason for this is because there are associated document changes and things that go along with the release.

D

We meet notes that need to be trapped, and so, if the feature exists in the future, we go all that stuff gets trapped because if it doesn't exist- and it won't, please make sure to have an entry in the futures repo as an issue and make sure that issue has the 1.6 miles some label on there and market that yourself, as owner and cig storage as the sig that's backing it. Okay,.

I

So create an issue and Leah feature reported to track. It got it one last question: you know with with every rebase there's every now and then their changes in the the upstream API. What's the best way to kind of get ahead of that and.

D

Top of that I mean yeah. That's tough, unless you're tracking, all the pr's that are flowing too right I mean I.

I

Don't mind doing the the rebate going to during the replay stuff, but maybe there was a some way to go like issue somewhere. That's kind.

D

Of an ounce of it we don't have any good mechanism right now for tracking the internal volume API changes. Maybe we should, but at the moment we don't know what.

I

Is not just the volume API and I've drawn about like so just the higher level API stuff, like a object, meta.

D

Okay, that shouldn't happen too frequently, I think the last big one was from at the end of 1.5 when they made a big refactor, Clayton and chow yeah.

I

I just did a rebase that it seemed like so moving into the API machinery packaging. Yes,.

D

That happened at the end of 1.5 being on 1.6 and I. Think there was communication sent out about that change, that kind of changed. It usually gets communicated out on Cooper native death, okay,.

I

D

All right that we probably do the nest eggs to keep track of that ball.

I

D

All right looks like that is all we have on the agenda for today. Anybody else want to add anything.

C

It saw this is the old from celion see point hey there I want to make sure they fall outfit. Based on the email group. I added a a discussion thread around CD is psi. So if anybody has some time to take a look and has made promise following up from our november vs that we had the greatest starting to get them there, cool.

D

D

Speaking of face-to-face meet up, so you want to talk about when we want to have our next one.

E

Sure that sounds like a good idea. I think I mentioned it before this is a sieve. Long with dell AMC but we'd be pleased to host the next one in santa clara, that's of interest. I.

D

Think that would work nicely for a lot of a lot.

E

I yeah I like santa clara.

I

No one is interested in florida.

D

Always get excuse to go out to florida.

J

Is that's all facing affordable.

D

Yeah, it's not little make one in terms of timing. What were we folks thinking? I know? End of March is I. Think what we end a q1 early q2 is what we were initially thinking about. End of q1, which is end of March, is q. Con Berlin, so I think folks will be out for that that maybe sometime in April I.

E

Don't know my calendar open, but no objection tangibly. Okay looks good. Let's.

D

Say sometime in April tentatively in santa clara and as it gets closer, we can figure out the details and the exact dates.

D

All right folks, thank you very much. Does anybody else have any other comment.

D

All right take care thanks.