Kubernetes SIG Windows, 9 Oct 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Windows 20181009

Description

Kubernetes SIG Windows 20181009

A

I better go ahead.

A

Hello, everybody and welcome to another sick windows meetup. Thank you all for attending the gotten.

A

A few notifications lately from the communities released him and essentially, as you guys, are well aware of the 1 to 13 release of vanities they're, trying to target it to be a stable release and, more importantly, they're also bringing in the timeline the goal there is to by the time kuba Khan comes around is to have the release wrapped up so as putting a little bit more pressure or the individual seeks to get there working and and basically don't work on any important or major features.

A

So with that in mind, we've been asked on a variety of different work that we've had either ongoing or at least in the individuals, deeper kind of clarify how many of those are happening or not, and Patrick and I were just discussing the the feature issue 5 for 7, which Peng PHA and some of the other team members are working on, which is around the add support for Windows containers in CRI Patrick.

A

You know, based on what we discussed earlier, I mentioned, that you might need to wait to see if we are gonna need this work and how much of that has been started already, and we don't have the details yet.

B

Ok, all right so I'll go and get Sur on that. So we talked about that issue a little bit last week.

B

So if you scroll down in the notes there, because I should specifically asked about that one, and so we had already implemented the CPU and memory limits for Windows in the in the queue blood and the docker code path and what was proposed in that work item was CPU share, account maximum and so I think we have something. That's going to. You know work at a basic level, but it's it's not quite as accurate as we would like it to be on Windows.

B

So unless he's already got a PR there, I think it could probably wait, but the one thing that I think we do need to figure out how we want to track is actually bringing a container D up.

B

So over the last you know, couple of weeks I've been looking at what it's going to take to get Windows Server, 2000 19 working well with kubernetes and get things as stable as we can and one of the things that Windows Server 2000 19 does. Is it basically updates the interface that that HSM is implementing and it enables some new calls that are available, including things like single file, mapping on Windows containers and so I think you know all along we've been expecting to that. We would move to container D at some point in time.

B

But if we want to get all the bug fixes that are there in Windows Server 2000 19, we basically need to move to container D. Now, because that's where those code pads are hooked up and oh yeah, then that's just message me and also the network namespace separation that that we did to clean things up is also using that new code path through container D and so I think we do need to go ahead and file, an enhancement that will track the PRS that are needed to able cry container D.

B

And then my expectation is that this should be testable within the next few weeks and then we'll be able to determine if it's, if it's good enough to use as the default to stabilize with or if we need to focus on docker sham. But you know, given that there aren't, we already know.

C

That there are.

B

Code code fixes in 2019 that won't work with the older docker versions, then I might think we're gonna have to go with cry container. Dude stable anybody have any any thoughts on how on on that move or how to track it.

B

That would mean that if we're focusing on cry container D to go stable, then we would need to. We would basically only be able to pass conformance on 2019.

D

That sounds fine to me.

D

We don't have I, don't have any use for sixteen or eighteen, oh three or moving to the newest version. I don't know if anyone else has.

D

A

High level, like you really this all I, just don't know how many of you know: I, guess you guys from Microsoft are the only ones I have data, how many people are using Windows server containers with earlier versions of Windows, right, I, think in the kubernetes community, since you know we're not stable, yet you can kind of enforce and then the version and tell them.

A

This is what you need, and this is what these things we're gonna work great, but you know how many people are using containers so far and and might be a little bit hesitant just because they adopted the corporate standard. Well,.

B

But the problem with the 1709 and 18:03 releases is that they're both going to be expiring next year, yeah.

A

Yeah I understand that yeah.

B

A

Like I said: I'm, okay with it, but I don't have any data on customer base now I become. Who can make the call on me I think eventually they will just wait a little while and eventually that OS will come into their laps.

B

Yeah I mean when it comes to getting something: that's you there. We could. Basically you, across the finish line with I, think that 2019 is going to be the most viable platform, because you know we know, we've got those file system and network namespace fixes that we that we need and there's no way to back port those you know.

B

So we could make a you leave the code for the other ones in there temporarily, so that people can use it as is, but you know, there's going to be some improvements that are just not possible, although services so.

A

I'm; okay, with that decisions, I think we're good. There.

B

Okay, yes, though, once we get 2019 actually out there and usable I'm gonna recommend that the people of Microsoft move to using that one as the default I'm still waiting on an ETA on that it sounds like there was a bill that was supposed to be final, but there was a problem with it, so I'm still waiting on an updated date on that, but in the meantime, basically updating the scripts in using manager. So that way they can deploy container D instead of the docker release that doesn't contain container D.

B

And so just to make sure we've got something filed I'll go ahead and open an enhancement on that.

B

The only change I've seen so far that's needed is that I know that the cry code path on Windows was trying to use TCP as the default, which is not secure, and so we've got a I. Think pen fee worked with someone here on the windows team, but they've got a PR open to use named pipes instead, which are which are authenticated.

B

So I think that's all the only when I was aware of right now, Dinesh deep rattling it did. You have any other things that need to be tracked as enhancements.

E

Not as enhancements, but there are some fixes, we are stability, fixes we are making.

F

And you guys hear me: yes,.

G

F

As enhancements know, since everything went in testing front, no I don't have anything I'm trying to look over the release guide Oh what whatever it's called she to figure out if the job definition is enhancement or if the the patches already sensed, they would be considered as enhancements, but the patches for that. This.

B

Okay, those are all on the Trello board here. Let's paste on the chat, encasing wants to look at it with the list of open P. Ours is there and the one to enable deploying Windows clusters on a juror went through. So that's going to use ACS engine to deploy the clusters, it's so the next step from there would be once we get those couple of stability bugs fixed, then we would submit something to enable the test job right, yeah.

F

Yeah, well, we would still- and I would want in parallel to to talk with it. This thing for guys, how do you propose that I should run a primary test? It doesn't have to do anything doesn't have to run any tests. I just want to just know how to run just one job, to see if everything's, okay, with the with their platform and so on and so forth, without authentication and whatever else.

F

That would be a good thing to have and there's a step there, but to see if they have idea of whatever methodology set in place for that and yeah afterwards, sending the the job definition with all the tests, Skip tests and everything.

H

Hey this is deep: I had a question around GM si I know them. The proposal opened at some point, but are there any plans to kind of address it in the cube side of things or are orchestrators? Oh, my god. This show supposed to handle it the best way possible.

B

Yeah so I have a appear that was started, but not, but not fully reviewed yet by the container identity working group, and so we need to bring that back up with them. I basically tabled that. So that way we could get to stable first, because I really want to make sure that we've got the windows tests running and that we've got. You know at least a first version declared stable before we start going with new features.

B

They had some good feedback on on some of the particular things there, but I want to make sure that we do something that works well with the cube platform, rather than something that is vendor specific.

B

And so currently I've basically proposing to do that in 14. At this point.

B

I've got that in the list somewhere further down.

B

Okay, it's somewhere down there in the meeting notes from a past week, but I remember which day it's on.

B

But yeah, if you do want to find that PR or so it basically I, have that something filed over under that that kept, which was the crew Bernays enhancement proposals. So I do have one open, so you could start reviewing and providing feedback there.

H

B

B

Okay, so next thing on the list was: was around the CSI spec feet, feedback so I know that's a boat and Nick we're looking at that over the last week, and did you have any proposed changes for that that needed to be opened.

E

B

But in terms of actually being able to implement a plugin like that, it would need more changes into Windows to support privileged containers or something like it.

E

C

E

Provider and not have it interest.

E

So that is not. That is an alternative discussion. Whether or not you want to put the CSI provider inside.

B

B

Was safe to say that for the you know foreseeable future, we wouldn't be able to implement it as a container right.

E

So the mounter know, if you look at the work I did for the Flex volume. Plugins I did the provisioner in the inside a container that can be containerized and that same code base that I used for the provision is the same code base that they used when they started implementing the CSI provider for the provisioning side, I see.

E

There is internal work that would need to be done by the storage team to support, essentially bi-directional mounts so bi-directional amount I would need to occur for you to containerize. The si si si si volume attacher.

B

Okay, all right that makes sense, so is there anything that we need to put on the six storage agenda for discussion, or should we just comment on there over on there? Spec that you know just dis looks good. You know we could look at, but we're probably not gonna, look at doing it until sometime. You know later in.

E

E

B

So if someone wanted to write one, they could, they could basically take some of what we had in Flex volume and refactor it to work with CSI. But in the meantime, we just used Flex volume, as is.

E

Yes, so if someone wanted to yes, I plug-in that targeted windows and host.

C

E

They could largely take the code that CSI CSI team has already written inside within the sig storage team. So when I took the provision, recode I just had to fix up compiling in Windows for.

C

E

Go provision codebase, and that was it it was. It was very minimal changes.

D

E

I imagine the same same same way. With their code, the the go will go. Code will largely just run.

B

B

B

All right did anyone have other topics for today.

B

So I think that's everything on my list. If.

D

We decide that the container D makes the most sense plus 2019 for GA for kubernetes on Windows. Do we think we can get that done for for this release, or would we consider pushing it out to the next year pushing out the GA target.

B

So my concern right now is that the types of stability problems we're having.

B

If they're still reproducing in in CRI container D as well as a docker, shim code path, then I think that you know, if we don't have things stabilized by early November, we would have to push it out. I mean I, don't think it matters which, which way we decide on this.

B

But you know one of the benefits I have on the or the container D. Is that I can you know, take advantage of the latest stuff that was testing on the windows side, because you know to be honest, you know nobody at Microsoft has been doing extensive work on on docker xem. You know it was sort of you know being kept alive, but it's not an area where they want to invest long term, whereas, whereas container D, you know is, is where they're currently doing their development to work with the new version of Windows.

B

So it's sort of the you know going with you're using using docker shim would sort of be using a code path. That's not actively maintained and I. Think that's somewhat true on Linux as well, because it seems like most distributions are moving to either cry container D or cry. Oh I,.

B

Mean do you have any experience in that area.

D

C

It sounds like what you're saying is.

D

That the choice of container D versus dr. shim is kind of orthogonal to the stability issues were working on right now,.

B

Yeah I think it's sort of what orthogonal, but it would be easier for me to get issues resolved on the cry container path, just because everything that we need is out in the open, whereas the the docker build that's being used on Windows today is built from a closed source branch.

I

Hi can't hear me yeah.

G

I

Usual funk kugo, so I have a question about container D. I know this won't work in doing continuity to run Canadian windows. I know there hasn't been much in the CRI continuity, which is the CI plug-in itself in community to run on Windows yeah.

B

I, don't think those PRS have been opened yet, but they are working over in not over in Justin's branch. They find it.

I

So I guess another question is since, like you said, there's not much time left for this release. Does that mean we're trying to do both dr. shim and testing, both dr. shim and also CIA continuity, to see which one stabilizes so continue working on both what.

I

What's the strategy here for Alexis.

B

So my proposal, I think we've got basically two two paths. One of them is we could stay with Windows Server, 1803 and docker Shan get as far as we can, but with the understanding that there are a few known bugs that we will not be able to work around, and so we need to probably exclude some more test cases, most likely in networking or storage that are fixed and Server 2019. But we're not able to get get those fixes in 1803, so I mean.

B

So what it's a difficulty there as we'd, have to basically get some additional tests excluded and get that you know approved through sig test infrastructure or whoever looks at the conformance list. I.

B

Think if we're on 2019, then we've got a path where we can get to where those should be feasible to get resolved and so I think it's a matter of in the next probably two weeks. We should know whether or not cry container D is viable, which would mean we can move to Server 2019 and get those fixes.

B

And so I I don't really have a good good answer there, but I would say that you know moving is a risk but not moving is also a risk, and so you know I'd really like us to look at in about you know week or two and say you know, which code path is more viable, spend the last two weeks leading up to code slush trying to stabilize it. And then you know if the tests are passing, then we move forward else. We moved to 14.

B

Okay, does anybody have have other topics or any other questions on that.

D

One more thing, I thought of: is there there I think Microsoft is also releasing an 1809 core. Only Windows Server. Is there any difference for our purposes between 1809 and 2019.

B

From a technical perspective, no I think there may be something a little bit different from a licensing perspective.

B

So I know that, with the 2019 release you can either deploy with the UI or as server core, and then the 1809 is server core only. So there is a little bit slight difference in deployment model because you could choose to deploy with you I with 2019, but other than that. I haven't looked at the licensing Docs to know what's different between the two, but they should be compatible.

A

Also another thing to know this: 18:09 will have an exploration example right. Well, 1719 can go for as long as that. Several ways which we support over 12 years or so yeah.

B

Yeah and that's where you're part of I me around licensing, because I think that 18 and I and I think it's done to license through Software, Assurance or service provider license agreements, whereas 2019 is also available, retail, which is a you know, perpetual license, but I'm, not a licensing expert. So don't don't quote me on that.

B

But do you have well okay, so I'm not I'm, just expecting that probably both of those are available on the cloud services or is only one of them available.

B

B

So I did Ruby, say so: computer.

D

B

No problem, okay, well, I! Think that's it for today, signal meeting is starting right now, I think so anything else.

B

All right well, thank thanks. Everyone I'll talk to you next next week. Thank.

A

You all bye, hey.

B