Kubernetes Community, 19 May 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Community Meeting 20160519

Description

We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.

https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY

BlueMeric demo; Why does CoreOS contribute; 1.3 Blocking features and Timing

A

As I say every week, this is a public and recorded Cooper Nettie's community meeting today is May nineteenth. It turns out I found out. It wasn't May twelfth just this morning and we are having a pretty full agenda. We are doing a demo with bloom Eric this morning and there's a possibility that we will be having a new little segment that I'm adding, which is.

A

Why do we contribute, which is a five-minute segment from different companies that are interested in and contributing to Cooper Nettie's, just giving us what their vision is and what their motivation is. But Brendan was delayed getting out of Austin's morning, so he may or may not be able to join us so that we might or might not have that segment today, then, let me try and find who needs to learn. You.

B

A

Apparently they found themselves that even to commute- and we will do a new so that new segment we may or may not have about. Why do we contribute from Brandon Phillips and core OS? Then the big meat of today's meeting is going to be the 1.3 blocking features and timing and brain grant and ten Goldberg are going to be leading that and then we have a cluster ops meeting or a close cluster ops report.

A

I am looking as always for note takers to help so that we can have good notes to be published in this document and then longer-term to be published into the community space on github. So if you have the opportunity to take notes, that would be super awesome and the link for the agenda document is available in the so. First up is bloom, Eric and I solving a fini on here. So then I think our new game to introduce yourself yeah.

C

Sure so, good morning, everyone this is, we don't need I learned the company of bloom Eric. We are a, you know, Seattle and a bangalore-based company, so we are building a solution. For you know a platform for micro services so go. Paddle is a platform that we have built using the containers and the container technologies. Today, I'm going to acquire demo off the platform today, um soldered, like can I, didn't share my screen. Yes, please and.

A

I will mute myself, so I think we're I think we're good to go. Okay,.

C

Hopefully my screen- okay, um so I'll give a quick introduction about the platform that we have built.

C

So this is the portal like we have for the design deployed functionality of doing the microservices serviced in place through a portal where you can actually bring in your application artifacts from either from a source control here us or you, can even import equipment still plate and or you can design services from scratch and then deploy them on to conatus cluster, on either Google container engine or on a ship lot or you can register an account of cluster and then deploy it on to that.

C

So as you do that we also this build is integration and deployment, and you can even build a pipeline using our Jenkins plugin and same time to give up no control over the infrastructure in terms for providing continuous monitoring and more like it's all inherent at the moment like if it moves company does all of this comes along with that I have plugins.

C

This is about the solution.

C

Wow recently, you know announced a technology preview for sure where we can launch the latest cluster from our hotel and then why being applications on set today, I'm going to do a quick demo of this means in which we can build a service design and then apply them on to assure okay. So I have a recorded video because I know, like six times, are doing a launch: an application for ransom, so I'm going to just do a quick video here.

C

So this is your azure portal and what we do is that we create a resource group where the clusters are being provisioned. So in this case we have a resource group in assure- and we have a two node cluster running and assured so this provisioning can be done from our portal directly where we can just launch the clusters.

C

This is the cluster that I'm going to use from our portals, so you can do a single sign on with the Microsoft lock, and you can see the clusters registered in our open.

C

This is the cluster that we are going to use throughout. As you can see, there is a means to register an external cluster as well. So if you have your on-premise clusters, you can expose the IP and the port and then register with our photo.

C

So now the first mechanism of.

C

The first day of you know creating a design is either you can bring in the source source, repository, scared or or you can actually build it from a container or import the templates, so in this case, I'm going to build it from a container.

C

So I am just taking a very simple example of a ghost application here and then I have to set the ports. The template is ready by adding an edge I mean like we are exposing the network ports to the outside world or opening of the firewalls.

C

So now this attempt this is a service template now like this can be launched on a cluster. So we would choose the cluster that is in the azure cloud.

C

See alternate port is a the replication controller board, and here you can see we can. We can Auto scale this. We can set the policies like auto scaling or continuous delivery or opening up the car. You know cluster firewall puts in order to access these services outside. So if a continuous delivery is enabled, um you know if it is a source control repository, we automatically detect the changes and then propagate a the continuous build and the continuous deployment.

C

So this is one way of building the service template and launching it now. The second way is through importing the clusters. I mean the inputting. The existing cabinet is template, so in this case, I have as a file which has a couple of yamel files in it. So these are nothing but our COO benitez yamel files.

C

So this brings in the services that are available within the templates and we will have to just link these saw edges, and now this is a multi-tiered app, so you can see that all of these properties, certain the yamel file, is imported into the designer.

C

Ok, so the way of launching it is very similar, so I'm not going to do I'm going to skip that part now. The third way is through source repositories.

C

C

A

A

Did we live in a penis audio I? Don't.

C

A

Just sucky yeah.

C

So this application, the ghost application, is launched and we can. We can check the application using the access URL there. So now we launched the third way of far you know: creating the service template so through source control. I have one jet hub account registered with us, so I'm going to build a service design using the jet hub. Our repository.

C

Okay, so we just provide the repository you are of here and we authenticate so that we can. We can enable continuous bills and then, in this case it's a tomcat application.

C

So the script are in the script. We can actually give the build scripts or starter stop scripts. So this gives the flexibility of writing a shell script to start the applications or stop the application.

C

And now we are building a second tier, which is a MySQL.

C

Database and then we'll just link these self service system.

C

Okay, so this is the third way of doing it. There is a fourth way if you see on the left-hand side of the designer. There are services like flask and noches. These are services which you can create from scratch. We create a mock service and we are, you know, store the artifacts in the jet hub repository that you have registered. So this is the fourth way of creating the service which I am NOT going to do a demo today,.

C

Okay, in the meantime, are the other. Two applications are ready.

C

C

Okay, are the template, app is ready and they should be able to access it.

C

A

Okay, there are question or audio leakage.

A

Seems like this leakage.

C

Yeah, so if we go to the detailed view of the app we get all the information about the app. So these are the services that are running.

C

We also get the CPU and the memory utilization, so in this case it's little different from the container raw metrics that we usually get so in this case, it's very specifically to the service that is running within the container, so we can get the CPU and the memory utilization.

C

We can also see the launch logs and the even locks are for debugging purposes, and if we want very specific application logs, we have introduced flow ND, which is which is which can be deployed as a demon set within cooper, natives and then application logs can be monitored.

C

A

Never is not Nina see me, go on me.

B

A tour I need to go.

A

Thank you. Did we lose UV Matheny, no.

C

I'm, okay, so uh yeah fluently is one way of monitoring the application logs. So you can, through our designer, you can actually launched a fluently or demon state within the cluster and then you can watch the locks and we also have a you know: mechanism of are creating a deployment pipeline using the cluster and the designs are using our Jenkins plugins.

C

So you can use the plug-in very much like um you know any other bill deployment pipeline very much similar to the usual way, but in this case you just use the cluster name and the the design name and then I'll create a pipeline. So we are looking forward to contribute to the open source community in terms of building these templates and make them available. So these templates can be used in your own car clusters or you can import them and reuse it in not go paddles. So that's all from my side.

C

So any questions then it put some on the demo I'll.

A

Have one question which is: how can people reach out to you if they need to and then we're pretty close on time? So maybe one more question.

C

Okay, so they can reach out to me directly or they can email us through info at bloom, eric calm and one of our support engineers will get back to you on that.

A

Any other questions from anyone and.

C

And we also have an online that chat mechanism, so most of most of the times of one of our soft I mean support. Engineer will be available, so you can ask you a query directly through the web chat and we'll get an immediate answer.

A

Fantastic thanks for joining us and thanks for showing us this demo veena p. Thank.

C

You sarah thanks for giving me this opportunity. Yeah.

A

You're most welcome alright, so up next is more about the community. So if you did notice earlier and if you're not on earlier, then now you can take a peek one of the video feeds that we have in the community meeting right now is that of the oskin hackathon for Cooper Navy. So we have about 20 people in here as potential new users, potential new contributors and they're talking with a bunch of the Gubru Nettie's contributors and community members as well.

A

So that's super fun up next on the agenda is Brandon Phillips in a new little segment about why we contribute to Coober Nettie's, and this is to give the vision of different companies and different groups that are actually contributing. So Brandon do want to give us the background and why core OS contributes sure.

D

Can you hear me all right.

A

Yes, just fine, okay,.

D

Great, so yeah I just want to give a little a little bit of a taste of why why we work on Cuba Nettie's upstream? So, if you're not familiar core OS is a small venture-backed company more in San, Francisco, New, York and Berlin and screw our vision is that companies big companies start to run all their infrastructure and what we like to call Google like infrastructure, everyone else, which obviously is very much in line with a lot of what Cooper Nettie's is trying to accomplish, and so as a small little company.

D

The reason we contribute to Karina days is that we want this project to be successful, because we believe that large large swaths of the computing market should be running in the way that Cuban Eddie's visions, compute should run, and so the ways that we want to expand. That market is essentially making it a no-brainer for people to choose Cooper, Nettie's and there's a bunch of different places where we think you Nettie is really great today, but needs to improve and that's what motivates a lot of our contribution.

D

So, in spite of the like v13 release cycle, we've been focusing on things like authentication, backed by open protocols like open ID connect which allows users to use our open source projects like Dex to back the authentication or existing identity providers like Google or github or etc, places where they actually already have identity for the infrastructure.

D

Other places that we've been investing is making Cooper Nettie's easier to install I, don't know if many of you have looked at the installation guides on Cooper Nettie's, but there's these little up down vote arrows on the bottom of the docs today, and we have a lot of down votes, and this probably means that there's a lot of places to be improving the way we install Coogan IDs and that's why you'll see Derek Parker and Aaron Levie and Mike Denise working so hard on the cell posted stuff that hopefully will be landing in d13 is actually an emerg cube.

D

And then, finally, we build a lot of technology to make the ecosystem around Huber Nettie's really successful. If you're not familiar I'm on the board of the open container initiative, which is really important for ensuring that containers and container images or something that can interoperate with systems like Cooper, Nettie's and other systems like build systems, etc, um we built rocket a container engine from scratch.

D

That's going to be integrated and supported in b13 with the idea in mind that rocket could be used by various operating system- vendors, core OS, it's currently in fedora, it's a merchant to Debian. It could be easily adapted for Windows, and so there's a lot of technology that we've built around qu gratis for essentially ensuring that it's successful and the reason that we really wanted to be successful is that as a small company that wants to make a business around this stuff, we have commercial offerings and those commercial offerings built on top of humanities.

D

We have core OS Linux that uses linux kernel and we have tectonic that uses cuban at ease as its kernel, and so we have no interest in making humanity's a proprietary product. We need it to be. We needed to be successful so that the products we build around it are successful. So that's my little story of Y Cuero I spend so much time and effort contributing to keep Nettie's so.

A

It's fundamentally the Cooper Nettie's everywhere philosophy, exactly.

D

Exactly awesome.

A

Thank you so much Brendan and thank you particularly because I know your flight was delayed and that looks like an airport and thank you for trying to jump on so graciously all right next up on our agenda, because I presume people. If people have questions about how this might work for their their world as well, that they can reach out to Brendan directly. So I am moving on to the next agenda item, which is about 1.3 blocking features and 1.3 timing. So this is ryan grant and Goldberg or.

A

Ryan grant in the frame up there shen, yes,.

E

F

Yeah, so in the beginning of the 1.3 planning cycle, we invited the community to to participate here in the community hangout and communicate what they planned to work on, and you know a number of people presented their very long lists of what they wanted to get into 13, and we've been all working furiously on that for the past couple of months. The original feature complete deadline that we planned into the schedule is here already it's tomorrow, the now the past two releases, one not one and one dot too.

F

We planned a three-month rly rly cycles, but we weren't actually able to complete the releases in three months. Each one took about four months. There are various reasons for that. This time we are trying to see if we can hit that three-month cadence- and you know in the future, will we're interested in investigating even shorter release cycles to make it less painful to miss release. But for now three months was our target.

F

So here we are, and we want to assess whether we are going to hit the target in terms of on the one dot 3 release, one that three wiki gage. We have some documented list of features that, if they weren't ready, we would hold the release that list. We've tried to keep very short just to the features that we feel are, and you know we have the most feedback from users that they're short and lows critical for the project and we've been working together with the community on those features.

F

In fact that the top two features are the first milestone for cluster Federation for uber Nettie's and support for saiful applications, principally pet set. There are some other features like in it. Containers which were also built in for that, but principally pet set in alpha and he'd, been working together with at least red hat on pet set and a number of other people from the community on uber Nettie's as well.

F

You know the other, the other two things on the list were hitting our scalability goals and there again we're getting lots of involvement from the community on scalability and the federated test, dashboard, which probably doesn't actually require anything directly from the release that can probably just be happenin dependently, but we do feel it's important to get the federated test results available to everyone.

F

So we can better monitor the health project, so their husband I know some communication from a number of people about where they are with respect to one, not three so I thought that would be good for people to share red hats and Caro s in particular.

F

So I don't know, Brandon, presumably is still on. Do you want to share? How are your feet currently feeling about one? That's three: where you, where you are or.

A

Possibly Mike could help with that, given that brendan is still in transit. Okay,.

G

You wanna go first, this yeah.

D

I think we're in pretty okay shape, so the authentication stuff that we wanted to get them with open, ID connect is in the merge. Q authorization is not quite there. Yet. This is up streaming. The office well up streaming. What was inspired by the open shift stuff upstream and that work is in a little bit. We solve a couple pr's open and we're having a little bit of trouble with API machinery and testing. If any folks have some help there.

D

That would be great, otherwise I think we're in pretty good shape with everything else that we had in mind authorizations the big one I'm concerned about and I think it's mostly we. We could probably use somebody who's really familiar with the API. Stop helping us out a little bit.

G

D

G

I can kind of comment, so there are some other questions which came through e mail. It CD, 3, starter, set. Cd3 is part of one to three, but is experimental. It's not going to be production, writing I, so we're targeting together with Google. We need to add more testing around text is free, jeje migration plan and so on, for it to be production rated, ah but it will be available as part of the release and stds free will be released by carissa standalone in June as well.

G

The other questions from I think six scale, for example, or on protobuf status, which doctor will be supported, 110 111. So if Google signals can provide some days ah and a better communication on what's happening, ms motor skill right, it was both. Yesterday, it's going up again, it seems like there's a lot of hearsay between different people. So one was asked was how can it be communicated clearly to community what kinda, burglar yeah.

F

Thnkx, that's a that's a good point, we'll ask our build cops to email to register with the rescue status.

A

Just generally the what they're troubleshooting and how how it's were working or not working is really helpful and should have a broader view.

H

Hey this is Andy with red I can provide an update on what we were looking for. So we we had a huge list, if you guys remember seeing that several months ago, and obviously not everything in that list is in 13 we have several or a handful of items that if we had like two more weeks, we think we could probably get them in. But you know I don't want to be a all of us saying.

H

It out of resource killing, based on low memory on a node I believe Derek from our side is hopeful to get the remaining bits in there for 13 we're also interested in seeing the downward API for resource limits go in, but there's some. The proposal is almost ready to be merged.

H

There's one I believe one outstanding point on that to get through the implementation is out of date based on an older version of the proposal and could be updated fairly quickly, but it won't make tomorrow set comp support right now, while we run in the unconfined profile and don't allow either cluster administrators or users to manipulate that at all.

H

We have a proposal and a slightly out of date, implementation that both are getting updated and could probably get in a if there was a little bit of slippage and then probably the one that's going to take a couple weeks and a couple of days is scheduled job which we'd also like to see, but I, don't think it's ready for tomorrow or Monday, and then we do have a couple.

H

Other ones, storage classes, which I know, would be a nice to have, but it's unlikely to make there might be a couple of weeks or might be further and then the last one which at least in signode we have agreed, is not going to make 13 is better disk accounting in the cube, lit and being able to do a fiction based on on that disk information, and that's going to require some refactoring before that can get in.

H

So those were the big six ones that we were looking for, and you know like I, said a couple of them. If we had a couple more days beyond tomorrow, we probably could get them in and then the rest of them are a couple weeks or longer.

F

Yeah, I think the things that are already implemented that just need to be updated and to be squeezed in in a couple days.

F

You know especially things where PRS already exists, that doesn't seem unreasonable to just wrap those up the resource downward, API and particulars pretty straightforward once we just agree on that representation in the API, so that seems low risk kind. Things that are gonna haven't even started on the implementation or things which need to be dramatically refactored seem pretty high risk, so I wouldn't want those like any major refactorings to be starting now seems like a bad idea. Yes,.

H

Yeah, so that's basically the disk accounting one but item is I. Think the out of resource Killoran, killing based on memory. That's really close downward API, like you said it's ready to go almost comp, is a minimal change to the docker container runtime at least initially, and so that should be minimally invasive. But it's not ready yet scheduled job is a bigger one, but it's a new API type, so, like I said that one's probably a couple weeks and then I don't actually have the up-to-date information on storage cause. I know.

I

H

Us to get that in the list- maybe maybe.

I

H

All right, I was just going to stay, updated status on storage classes, I have split the storage classes off Ryan as we discussed over email, so it's just label selector and there's a hole for it which I closed, and I think I actually can't open it because I push since then, but I had an implementation ready. Just laugh.

I

Okay, so so I just went right, two ND going back to your to your list, so repeating one. What Brian just said, I think monday right still makes sense, but definitely if we will do more changes after that, it will just hurt our civilization I. Just look at the merge queue and I did definitely like what I we tell here for our team is that we should stop doing that and should focus on stabilization quality dogs flaky tests.

I

This is what we are doing right now and I think that would be great, because hopefully we will meet the three months timeline right and then we can have another release, which is not that far from now yeah.

F

I mean just as one example: I already pulled the plug on the template. Api to 1.3 I really wanted that, but it's clearly not going to be done, so we already shifted that efforts to UM to work and flaky tests, yeah.

H

And my team is most likely going to shift a good portion of our effort next week, too. Flaky tests, assistance as well and I think we're fine from our standpoint for what's going into 13 and I would like to have a discussion about like one dot for planning and how we, as a community I, don't know, nominate potential features that go on the blocking list and agree on them and how we check on their status over the three months of the release. Obviously not.

F

Something we're going to use that would be great and I there was. The blockers list was discussed in the one dot 3 ely cycle, but we didn't get a lot of pushback early on, because I think everybody was confident their stuff would get done. Probably I don't know um so, but it would be good for the things which people actually really really really really need to actually make sure that those things are on the blockers list.

F

If everybody agrees that that is reasonable, so um you know otherwise it is very hard to plan and to prioritize the code reviews and things like that and practically speaking. We also agree with you that we need better ways of tracking those things, both a regular status reporting, but also identifying the issues and the pr's that are needed to get those things in, because you know with 3,000 open issue and 500 open. Yet it's just make sure the right people are aware.

F

Those things exist, so um you know so definitely open to two ideas about how to keep track those work items better. There is, um you know there have been some proposals like the the owners mechanism features.

I

F

That features repository.

I

F

Like that, so we need to uh to put some more effort into those things and try them out so.

I

Maybe if I can suggest, maybe we should put some timeline photos suggestion, because I would really like to see us in 1.4 with that right. So we have the features of closet area. We have the honors, we need to define the process of what is the release timeline and what is expected from each milestone and that blocking lists really. I already showed my point of view on that block English, which I I think it's in essence is something bad right.

I

We just need to decide what other p 0 and we need to make sure that they are ready for the milestones and not use that as something to get after. We are, for example, of the feature complete it. So how do you suggest we move forward? Can we nominate, like I, know three people to come up with the proposal around then so we can share with the community. Well,.

A

We have the features proposal as it stands, so what if we make sure that we get all of each of the different companies or individuals who are trying to put work into this, make sure that things go into the features repository and then we at the next, the next or in two weeks meeting we sit and we go through that and we actually define which are the list of blockers a list of poesy rose.

A

However, we want to define it and come to an agreed list, and then it just stays as that and we we continue to have the essentially the technical project, managers or technical leads, who are wrangly each of the companies working and reporting out within that framework, and then we occasionally do short report outs instead of long ways here, I.

I

Think the idea was mostly to define how we're going to decide about the blocking list. I Auto 0- maybe you know, create some criteria for that. So.

A

We we had talked about a group of people that carry the vision of Coober Nettie's, what I've been referring to as the elders group, which would be potentially people that have been long contributors of the project and understand the bigger vision and they get to be the arbiters. If we make that list too long for any particular feature set, does that seem reasonable means? We have to get those people named? Yes,.

I

Yes, hey, but I also want us to make sure that we define what does what are those blocking Lisa I mean should be something really. It should be really short. Please write and.

A

I would say particularly be kept for 1.4 because we would love to do a bunch of, or I would love to see us all collectively- do a bunch of work to enable more people to review by doing say, like pair reviews or enabling more people to to get commit access and do more of the work that we are currently bottlenecking on. And so, if we make that list for 1.4 of features very short, then we can spend more time as a consolidator considered effort as a community enabling and doing that.

A

It's almost I've been using the description of new hire onboarding, you know or the growth work. That needs to be done to bring people who have been submitting pull requests and move them up a progression up to a space where they're not doing reviews or they're. Now able to do different and broader to contributions to the project.

G

Sorry kind of one quick question from caressa, so regarding authorization, it was p 0, right kind of two just to give an example right thank transplant. It used to be a busy road at the beginning of one two, three, a planning now its ways being t2. Now it's p1. So how do we determine? Should we continue kind of? Should we try to merge it in one two? Three, because you zero again.

I

I think there is a difference between p0 and a blocking list. Right p. 0 should be one of the most important thing and every team make a decision on where they start to invest. Okay, so for the full one in our team, we decided what LP zeros- and this is well resulted right. We didn't do any p1 before we completed the p 0 items he's a different question of something to be a blocker, yes or no. Okay, I think.

I

Overall, our goal is to release on time, because I think we would like to build the credibility of the canines and analysis of Cuban. Ladies and so for something to become a blocker. It should be more than just a p0 in my eyes,.

G

But I mean so okay, so they're like blockers in terms of functionality and their blockers in terms of its being really losers of copernicus, and we don't have authorization. Mekinese, right and business kind of enterprise. Users are pushing back a lot.

J

Of that, that's the difference between a blocker and a p0 I'm really confused at some point. Can you give me an example of something that you think would be a p0, but not a blocker and.

I

I can give you an example of something that I think should be a blocker, for example, I think that if we have correctness issues I think it's actually in because of that the system is not working. Ok,.

J

So I would say, that's a p0 bug, hey.

I

Sometimes it requires more that you all right right, but sometimes it requires sure.

J

I mean like there's a certain amount of like the project, has to work and we're not going to do a release. If you know everything's in the crapper, but like you know in terms of features and efforts, it seems like you know, we're really splitting hairs here in terms of the definition between PC rose and blocker. All.

F

Right, we have a definition of p0. Our problem is that people don't.

J

Apply it correctly and I think that that part of that is just it's honestly, you know and I've been beating this drama I've been trying not to be shrill about it, but um you know we just need to communicate better around this stuff. I think the clarity of what the status is, where things are. What's in, what out what you? No decisions have been made. How they've been made like I just found out the other day that chron is no longer an extension it's now built in as a core API right.

J

That's a big change that came in late. It was hidden in an issue someplace. We just need to up our level of communication here by like three or ten times to really make sure that everybody understands what's going on in a project. You know not saying that that's the wrong decision using that as an example, it's just the type of thing that we really just need to be able to communicate those types of critical decisions very widely. Sorry,.

I

Nins you write a gun deck, but sorry, sir, about the pcr on blocker, and I think it's more important so before to meet the timeline and enri some time and we need to decide if there is a p0 that now will take two more weeks and we'll actually and put at risk all the other p 0 items and will make them delay 90 for weeks I. We need to decide and the other is turning.

J

Any any type of project management that's going to come down to a set of people. We need to name that set of people.

J

We need to make sure that we have the processes so that they can operate in the open and transparently you know and that decisions get communicated widely and we need to have the process so that we understand, what's in scopus, out of scope, delegate as much as we can, so that not everything has to go through that group of people, and we just need to take the time to do that with with receptor releases. The other thing that we've been talking about and Brian you mentioned this idea of a faster cadence here.

J

I mean it's some degree. We want both the slower cadence and a faster kids right. I mean you know any enterprise user. They don't want to be doing an upgrade every month right. So that's a slower cadence right. They want things to be boring right, but then people want to get features out there into a wider audience, so that argues for a faster cadence and so having the the stable. You know versus testing some sort of long-term supports everything we just need to pick a model and go with it and I, don't think it's controversial.

J

We just haven't, had the structure in place to be able to make those decisions and communicate them widely and just sort of call that decision done.

J

I'll stop talking now, but I think these things are all related in my mind. There's.

A

Another knock on effect to what Joe is describing, which, with the turn and lack of communications, which is we end up with a lot of refactoring or changes or not completely communicated decisions that people end up reworking things which means they can't work on other things. Are they can't work on even like core maintenance stuff in the can put effort toward that?

A

So you know we want more reviewers when we say that, but if somebody has to reimplement a feature or multiple times, rebase it against against change code because we're not able to move as quickly through it or give meaningful feedback on it, then we lose that time. They could be more applied more effectively.

A

So we, these are all clean up things, and this is why, in my opinion, we to put the 1.4 list as as small as as possible, so that we can spend a bunch of time and effort on this sort of thing and training people to break up these bottlenecks.

H

I'll agree with all of that, except for the keeping the 14 list as small as possible. It sort of intellectual chat. It's just that. I have a concern we'll see if this plays out, but in the next 3-4 weeks is the v1 3 milestone issue count going to balloon like crazy in an upwards direction, or is it going to maintain a steady state?

H

I genuinely, don't know the answer, but it seems like what would give us more confidence as if we knew for a fact that the milestone for the upcoming release was front loaded with way too much scope so that, as we approach the release date, we could kick that scope out.

H

I know that sort of why we have a separate spreadsheet right now to track sort of the small here smaller issue count, but we're once again getting away from the issues and the metrics that we could use to sort of steer us in one direction or another. um That's my only reason for saying, like front load as much as you can in 214, and then we can have a discussion about kicking stuff out, leads to less.

B

D

So when little concern about that, like how do we, we only have like a few people in community, you can actually label bugs. So it's your suggestion that we all just polish is for 14 and then we just hugely front load. Somebody has to then go Tagle issues as b14 sure.

F

With nothing automating our way around github slain apples- and we have ideas about to do that. We just need someone to build the auto labeling machinery.

F

Right so we've taken some steps already to reduce the power of people with right since right, access to the repo is required to manage labels. The one thing that that remains is to control the power of the lgtm label, because that's another way that we work around gibbs co, exact model. So you know once the owner stuff is fully implemented, then we should be able to give more people write access.

H

Just in the small it sort of seems like you could make it on calls duty to make sure that there's not just a team label every issue, but that there's also a milestone issue assigned every issue and by the.

F

Hog- it's not actually practical for various reasons, but and we I'm definitely open to discuss brainstorming about different alternatives in that space and already it's the case that human assigned team labels are pretty much random as far as I can tell so, and we need to figure out a better way to more correctly assign things or they just fall through the cracks.

G

I'm still Ryan I mean is a kind of it. Overloaded before right, Cora ask you'll, contribute a developer to owners file initiative starting beginning of June. Once we phrase everything from outside uh that'd be awesome.

F

G

F

So we're happy to do.

G

That and but then the other question is kind of right. This combined spreadsheet, with high-level issues right there about 35 issues. We change progress 403. What would be the right channel right now to go and figure out? What's making one two three what's going to carry over 200 for right, so I mean that doesn't seem likely that out of this 35 ish is everything going to converge tomorrow and there's.

F

Just high level.

K

G

Not all the detailed pr's it just a little proposal.

F

F

What we need is all the owners of the issues to go, triage them and assess whether they're going to be in or they're not going to be in I. Don't know that one person can necessarily do that, but in the past releases we have. We started having burned down war rooms a couple of times a week, so I think we will need to start doing that to force people to accurately update things that are attached to milestone is.

A

Tj I'm Nicole cuz, he was leaving those last time. Okay, we can get those scheduled up again, I think they were Monday, Wednesday Friday.

G

Yeah I mean I'll try to calm down everyone, who's indentify, his owner on this spreadsheet and get started some day by I, guess monday. By now, I mean.

F

They're 165 issues on the 13, milestone and I can come up with a number for I.

G

Mean there is a big discrepancy between github, what's marked as 123 milestone and signal seek documents which I I compile the list with. What's marked one two three, so should we what the truth.

F

Was a record of 31 three milestones not attached, then it's not on the radar. So we need to fix fix that. If that's the case for some of these issues, okay,.

G

L

If you're, referring to that spreadsheet you sent out to the sig leads I mean I, know I haven't updated that since at least signode last met this week, but I mean I'd be happy to go through an update. The red hat items on that list, giving.

G

Way, wait. We were trying different mechanisms right to compile at least high level view of what's going on as Brian mentioned without automation, detailed view is next to impossible, but so this list is based on six right kind of what cigs identify this and I go into one two, three and I keep asking single aides to update it right as much as possible to bring it back to editing.

A

So at this point, what are our action items we need to define who gets like veto power? Roughly speaking off of 1.4 feature lists, we need to compile a an inbound list of issues from 41.4. We need to understand in scope what stays in 1.3. We need to define a date for freeze on 1.3, because it sounds like we're slushy again, which is fine and blank. Why.

I

Do you mean you have slushy again slushy.

A

Wait so much yes, not we're not freezing on Friday, because there were a couple of things that might come in over the weekend. It sounded like.

A

What else do I mess? That's like the four action items as I see it so far, I.

H

Guess, based on the other thing that was going on in the back channel I would love for an action item for somebody from signode two sorted more officially broadcast this policy that true benetti's is moving away from recommending a particular version of a particular container engine and instead going to provide testing around the stability of particular versions for particular container engines.

H

It sounds like this is something that was decided within a cig meeting, but has it yet haven't been broadcast out of a broader group or made its way to github issues or whatever and I would love to see that as just another example of tightening up communication, there.

F

Was a red box mounted on the site somewhere I.

H

Nobody was able to answer that question in zoom chat anyway, and on.

J

L

H

Walker there wasn't anything there. There.

L

Was a community I think the community's dab discussion on what we want to do with respect to 10 10 verses, one not 11. I know I spoke up for red hat and at least saying that we were not advocating a move to one, not 11 right away at this time. Part of the challenge on this is that sometimes doctor 111 might not be available on all OS distros, at the same time that Cuba nanay's one not three releases.

L

So, for example, if cube when that three comes out and says you know, the must-have version is dr. one dot, 11, and yet no rellis derived platform has 111 available in the stream. At that time, it's kind of a difficult position to leave some vendors in and given that there's no behavioral requirement to that's exposed up through cube and one not 11 verses, one, not ten, forcing folks to make a particular recommendation at this time seemed not really prudent. I I.

D

Understood the problem is different as like whether 111 would work or not like our problems with 111 that we're not going to fix or we'll fix it. Looking.

H

At it from the perspective as a potential cluster operator, I've got a window of about four weeks here before I'm, coming up on the next release of true brunette ease and I'm, starting to plan how I want to most effectively deploy the best cluster with the best stack to make it work appropriately. And so this seems like the amount of time, I need to sort of plan that out just giving folks a heads up that the policy is changing would be helpful. Yeah.

L

So that's very OS platform, specific right so like on on redhat derived platforms, we often will carry backported patches in two previous versions of docker that might influence our recommendations for what you do and say: rel vs, federer, vs sent OS right. Other vendors, who might provide docker packaging on different platforms, might feel differently right, so I feel like you should make the right choice for the right OS platform, you're running.

H

Okay and how that's I never liked on the otha blade that eats you, it's.

J

All about testing, if out.

F

Of curiosity Derek, while we're discussing packaging this cintas used, the same packages is fedora and rel fedora.

L

Leads Roe and Santos mirrors real.

K

But the different mirrors, because.

F

We've had repeatedly had issues that, like Santos, is, has a 120 alpha release our communities components. I was.

H

Your question about the cabrillo, these rpms versus.

F

H

The docker, our pins, yeah um I, don't know offhand what, since into us specifically I know that Fedora has been building and rel has been building. What we ship in open shift, the version of cube that we should have an open shift so I'm guessing you referring to that issue about the docker vlogs problem in one of the vagrant boxes that comes from a red hat product, so yeah I mean if you've got like specific things.

H

We can take a look at that, but generally what Derek said is true: that Fedora is going to be in front of rel and sent OS, and when r l releases, a new rpm sent to us will either be very close to the same day or it might lag by a little bit. But the versions are basically meant to be the same between Robinson to us. Okay,.

F

K

I guess can this is robert falcon somebody clarify if we're saying that one, the doctor 111 is required or is it so I mean there's a certain degree of.

C

E

And M minus 1 Bobby.

K

Myers, okay, but but tested, so if somebody's on it. So then it made. This is a little bit mood because somebody could just keep using 110 and Pat and when so, they don't have to have access to 111 and.

F

We have been testing 110 continuously up until very recently. I guess dish said that were so.

M

We're currently testing one line: I'm just wishing to 111 a Darcy I I see so we did this 110 and we know it works, but it hasn't gone through rigorous testing. Like the other versions, yeah.

H

We we rolled back to see I infrastructure away from 1-10, because at the time the latest 110 version was 110, dot, 2 and that had some nasty race conditions in it that were later fixed in one dot, 10 dot 3. But at the time it wasn't even sure if doctor was going to do that release. So that's why the CI infrastructure went back to 19.

H

You know this is why I'm so confused without, like the stability of docker, the right container engine to run right now. This is I'm just.

K

Sort of asking.

H

For, like somebody who knows what's going on I know, signode was sort of trying to put together some et tests or their head at some point in discussion of like validating the particular stack for your particular node. Just a brief update on sort of where that's headed, specifically with an eye towards locking down a decision prior to the 13 release, would really help increase confidence. um Does that make sense.

L

So I think it makes sense. I don't know if I can give you the answer that will satisfy you and I would say that, no matter the darker version you choose, there is going to be various issues that are found, which is why just the output of testing is the best that we've stated for right now. Right.

F

L

F

Have a dashboard or something with the test.

D

Results, that's.

M

What I was getting out, the test results, so the best tensions that we make today, at least from google side like we have our entire class for tests, and we basically use that to validate dhaka versions. We are working towards more specialized this just for the doc edema, but those is not ready and then probably not going to be ready for 103. So until then, it's probably just a compilation of few tests that you're going to trust so.

H

If I were to synthesize, I guess with a sufficient answer and derek's answer, it sounds like it's up to me to bring my own testing to ensure I have confidence in my stainer manager prior to running Q. Burdette ease on top of that is that correct.

K

M

You are knowledge of a given version, and the community can like Derek from Red. Hat can give his knowledge on dr. 110 and we'll give our knowledge on 111 and it's up to the user at this point to choose their poison.

A

So we write about three minutes: I know that this could go on. I suspect this could go on a bit more but Aaron's all good, ok, John, Dillon, jamba, lazim, sorry, our documentation person has an announcement and then we've got like I said just about three minutes left. So, let's see if we can get one too quickly, yeah.

E

um Just wanted to note that I know it I know the weekends are precious time for everybody, but actually on sunday I will be at a conference called write. The docs up in portland and I will be leading a docs hackathon there um for communities and I should have a whole table full of people. Tech, writers from all over the country. You've come there and working on the docks and I'm going to be enticing them with bounties.

E

But one thing I'm concerned about is that if they have questions on Doc fixes, it would be good to have subject matter. Experts on hand ie, you guys so I'm not asking for much, but if you guys have time on sunday, 22 just monitor I'm going to send them to the slack channel, cooper, 90c users and just look for questions there and because you'll greatly lubricate the docs hackathon on Sunday and I know it's Sunday and that sucks, but I'm just begging for help basically begging for alms.

E

So thanks very much and I hope to close a lot of issues on sunday with everyone's help. Thanks John.

A

Okay, anything else in last minute: I.

K

Just that cluster up sig actually started a draft of the reference architecture. Sorry, if we're looping on the audio and says, give me that look and the please I put the link in the things in the in the doc. So please click on that. Look at it. It's a draft but we'd love your comments, we're trying to figure out how to how to help with people starting up Cooper Nettie's and what they need to know. So it should feed into docs and we'll pull together. Some information thanks.

A

For that and apologies for missing on the agenda all right anything else in our last minute or we get well, then I will say: reporting live from the Cooper Nettie's hackathon at oz con. Thank you and we'll see you all next week.

F

F