Kubernetes Community, 15 Feb 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Community Meeting 20180215

Description

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

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

A

Also, if you are not speaking, please remember to mute your microphone so that we don't get a whole lot of background noise, the so for today's community meeting. We are going to start out with a demo of Apps Z by.

B

A register stum.

A

Who is going to show off this tool register? You want to go ahead, yep so.

C

I'll go straight to the demo, so my name is again: Richard Krishnan, so the co-founder of cloud bond. So what we do is we take cuban at ease and we created a platform for enterprises to deploy enterprise applications to private and public cloud and behind the scenes it's basically deploying to given at ease. So what our platform does. Is it integrates the source control system, primarily github? We also integrate with SVN and CVS. We take the changes from source control. We use the build system either and maven, Gradle or Jenkins.

C

We build it and then deploy it to a Cuban at this cluster or clusters. So I'm going to show you today a demo I'm going to share my screen. Now we find the screen.

C

So here is an application, that's running in Cuban. It is now this is whether it is running in AWS now. So, as you can see, it is it's it's at sample application that I created for demos. So it's running, oh three, four, zero, two versions running on Apache Tomcat and it is running on actually two nodes or two parts.

C

So what I'm going to do is I'm going to show you how the platform works and how the platform helps build and deploy an application in communities. So I'm going to go back to the source of this, so here is github. The game is a public project, so this is a typical term Gale project.

C

So what we do is we kind of make it simple. So, in the project we introduce a file called AB, 0d animal, so so the app I'm opening the app zml now so this the animal file contains. You know some basic information about the app. Then it also tells us how to build it.

C

This particular case it's an ant build and then it also tells me or tells the system where to deploy. So here you know, you can see that there is a cumulus context here and it says two replicas and what tour to expose and then it has some custom properties. Now the idea is to have different animal files for different environments, like, for example, for dev. There would be one ml file for you testing.

C

There will be another one and then for production there will be another one and for this demo, what I'm going to do is I'm going to show you a symbol, dev deployment, so I'm going to edit this file so before I do that I'm going to go back to our engine. That's our back-end! That kind of coordinates all this so I'm going to use our tab tool and check the status of the engine. So so the backend is designed using microservices architectures. So there are, we have several components: kind of connected together using a hub.

C

So this tells me everything is running good, so I'm going to watch, build and deploy micro-services, so I use the I option of a tab tool, so this will most likely be used by you know administrators of our platform, so watching build and deploy so now I'm going to make a change. So here the application you know, so what I'm going to do is I'm going to change the title and one property here.

C

It says 179 here so I'm going to make a change so this time I'm making a change in the ABS EML itself, but instead you can make a change in any source file.

C

So we did it I'm going to make it 180 and I'm going to change the title to say today's date, I'm going to add today, States, ok, so I'm going to commit now as soon as it come. You know we commit the back and picks up the change and starts building some. You know using the tap tool. I'm watching live what's happening, so it's now clear, already compiled it, and now it's pushing the docker image.

C

Now you can see the build, is done so now I'm going to go back to my inbox, so I'll get an email from the system. Saying that you know the build is successful and the new version 4:03 is that is build is complete and it took about 15 seconds. It also gives me you know if there are any warnings or errors during the build. It will also add that to the message now, if I go back to the lawyer, you can see that you know the deployment is also done.

C

So if I go back to the inbox, see the email where it says- Russian 4:03, it's done- took about nine seconds. So now, if I go back to the application, so you can see that you know this is the old version is running so now I'm going to be free load this page.

C

So now you can see the the new version is up and running. So it's starting on two new pods and the value of the Nana also changed so here you know, during the line on the time that you know, I was showing you the log. You know it built and deployed and created during the the new two parts. Now this is a symbol application now, so I'll deploy one more application, so it's Tomcat won't load is pretty so it's it's. Basically the Tomcat Apache Tomcat project we forked it and introduced our ABS EML in it.

C

So it's going to if I'm, when I make a change here, it's going to build its illogical project, so I'm going to make a minor change here commit so I can show you the current version running. So here is the current version running. This is the the Tomcat samples project, so it has around I think about 1,500 source files.

C

Yes, 1560 source files, it's compiling behind the scenes once the combining is done. It basically uses Cuban. It is to deploy so it's now building so build is successful. So I should see the email.

C

So there's email, so it says you know it took about 36 seconds to build now. So now it looks like the deployment is also done so it took about nine seconds. So let's go back to the application, so this is the previous version. So when I click on this link again I should see the new version running. So here's a new version now a couple of things about the ml file. So this this particular project or the application is, is deploying on Tomcat.

C

Now, if I were to change this, for example, so we also created other image templates. So we have. These are nothing but docker files with different. You know application service, so I can take say, for example, the Tomcat loads, an application I can deploy to say WebSphere. So all I need to do is change. The.

C

Button image template to have spirit so deploying it now so so so this be I made a typo there, so I'm going to fix that it's pH.

C

You come at the change, so it's going to build again and now it's going to deploy it to WebSphere. So what we have done is you know to do for the enterprise is you know we made it simple to basically create different types of image templates and simply put all the information in a Yama file and we basically pick up from the ml file. We integrate the build and deploy and the deployment part is done using Cuban IDs.

C

So here you can see that you know the WebSphere deployment is done, so this was the Tomcat loads and application. So it looks like you know it's now to WebSphere is coming up, so you must be so I. Have the emails here saying that the build is complete so 4:05, so you can see that the template is WebSphere 8 and the deployment is also successful. So WebSphere takes, you know a few more seconds to come up. So let's try it now there. It is.

C

It's now running on WebSphere the same project running on WebSphere you're done, and you know it's took about 45 seconds.

D

C

We also have a UI, so you log into the UI, and they can you know you can see the the deployments here. So I can click on. You know the different those and then pull the logs. They want to see the logs. So here we go, you can is the bill log and also you can drill down to some of the details like, for example, the message that came from github. You can view that, so basically we keep track of all the messages, as well as the log that I don't.

A

C

Better kind of going across the different micro services, then we also have this was a bill log. You can also click on the deployment activity, so it's now showing the different deployments and I can also pull the deployment logs here you can actually see the cube, colonel commands that it executed and we also tap into Heep, stir and pick up all the data and and show it in a single shot. So here all the hipster data is also shown in the same dashboard.

C

So okay. Well, thank you. Thank.

A

A

Interesting deployment tool, it's all the time we have for the demo. So if you have questions for Reggie, please ask them in chap register view, bring up your chat window, you can answer questions for people there or there will be links to I, ABS, II and other information in the notes. So thank you very much. Thank.

C

A

Next up we have our release, updates so I, and that of course starts with the upcoming release. Jase, you wanna, take it away with the 1.10 update sure.

B

Thing so 110 is in the over the top of the hill phase, so basically over week, 7 of 12- and there is a link in the community meeting agenda for the full schedule. If you want to follow along with where we're at we're looking on track so far to meet our release target of March 21st.

B

Obviously a lot can change between now and then, hopefully it won't, hopefully, will continue being on track, and this week we are cutting a beta, we're having a couple of issues with the release tool and ago and we're trying to sort those out, so the beta probably will be released tomorrow or maybe Monday so slightly off schedule, but still early enough in the release cycle that you can start testing against it, which we highly encourage, because that's a great way to get early signal on release quality.

B

We are also setting up the release branch. There was an email that went out to communities dev and some other lists that basically said that it's time to do cherry-picks against the one tenth branch- and that is not correct- just keep committing as we currently do. The the cherry-picks into the one ten branch actually happen after code freeze and those will be done by the release team.

B

So basically things hit master first and then they always get cherry picked back just like normal, so no change to current process there next week is code slush and that's where we're trying to sort out the issue, sort of relevancy for the release signal and so SIG's need to mark their corresponding issues that they want to address before the release with the proof for milestone and the bot will definitely enforce the labeling on those as we go past code freeze, so just a reminder that all issues in the milestone are considered released, blocking the reason we do.

B

That is because it gives takes a chance to pull the proverbial stop chain on the release. If there's something that could negatively impact the community and the release and is known, there are obviously known issues in the release and we'll have those discussions as the time gets closer. Is it to determine of what is actually release blocking, but we definitely don't want a sacrifice: release quality for meeting the target date because well, it is a plan to have a quarterly release.

B

Cadence, it is a little bit arbitrary and quality will always preempt schedule, so definitely keep your sakes on top of any issues, make sure they're labeled in a way that is consistent with where we're at in the release process yeah.

B

Lastly, code freeze will begin on February 26th and that's where we basically stop pulling fast-forwarding the entire master branch into the release branch and we start selectively. Cherry-Picking commits out that are for test fixes for quality fixes. Let's say you find an issue and you fix it as a sake that will allow us to pull that code in and basically we curate the branch from that point forward, and then that is what gets released as the release.

B

Are there any questions.

A

I'll just add a comment which is about at this point: 30 to 40 percent of the issues that are in the milestone are not properly labeled and all of those that are not labeled are gonna, get kicked out on code slush. If you don't go ahead and complete the labels on them. That will be pestering people in slack about that. Yes,.

B

Thank you very much, and then those labels are again the important for the release team to to understand what the status of any particular work is. We don't have a lot of things to work off of so labels become quite important, especially from just the human readability standpoint.

B

So, in terms of the other releases in progress of 1.9.3 is out. 1 by 904 is planned in two weeks and 1.88 is freshly out. So if you're looking for some of those cherry picks that have gone back into those release branches, they are out there and ready to use, and if there's no other questions, that's it for me.

A

Okay, well, thank you very much, so our.

A

Meadow and Joe are not actually going in for this one they just sent along their updates for 1.9 1.9.3 is out and released. Med Hole is planning on one point 9.4 in approximately two weeks. So if you have fixes that are backward to 1.9, please get them merged in the next week. Also for 1.8 1.8 point 8 is out no definite plans and 1.8 point Milind, so I think that's it for release updates, which means we are now into sig updates. So we're going to start out with sig testing so Erin.

A

You want to do sig, testing, sure, hi testing here.

A

I'm going to ramble through a couple random that have happened, don't really have that much of a very Mathew type of update for you this around. As always, all these links are in the meeting notes, which is where I'm going to start sharing my screen.

A

Okay, so first off I wanted to give a big thanks to the Amazon eks team, who hosted a good chunk of the state testing folks for a face-to-face meeting on January 26th. A lot of us are sort of co-located in Seattle, so that seemed like it can be anything to do if you are also in based in the Seattle area and would be interested in participating further. Please come on down to the stochastic slag channel or look for announcements. The further me that's going forward on the state testing mailing list.

A

We found that it was pretty productive to just have sort of a high bandwidth conversation with folks in the room, and we also were working to include some remote folks. If there's value in that yeah come check us out. Look.

E

Let me let me use that moment, Aaron to offer to any of the sakes or folks that are just looking for some space to come in and have a meeting to have a you know: kubernetes sig or working group meeting or any just please reach out to me, and we will be happy to support that.

A

Cool yeah, it was a good friend, so I would love to proudly announce that we have finally accomplished our goal of getting rid of Jenkins in our hundred ish Jenkins slaves. There they're gone so every single job that has run for this project. You know a pull request, job or a post, admit job or periodic job. They're all run natively on a kubernetes cluster. Now so hooray Jenkins is dead.

A

Lola, Pratt I think I announced this a couple weeks ago, but I'll just reiterate that state testing now has a new sub project called the testing common sub project. Where I like to talk about how we will defend to the death your right to run tests, but we're not going to write them for you. But the testing Commons place is a great place to talk about best practices and common practices for writing tests. I. Imagine there's going to be an influx of tests being written to flesh out sort of conformance and different components.

A

Profile and I would expect that's going to be a great place to participate in that endeavor and sort of identify, best practices and the usable frameworks for all of that to happen. I'll get a little bit later, one of the common issues that came up, but that happens every two weeks, 7:30 a.m.

A

Pacific time Wednesday, because we're trying to be friendly to some European folks when they're collaborating with us, something you may have noticed in the middle of January, maybe not maybe don't checked estimated as obsessively as I do keep tests great got rewritten in go, and so this page used to take like 30 seconds to load up and it loads phenomenally faster. Now this is like a massive world of difference, so I just want to give a huge thanks to where a pitchman and whomever else helped out with this.

A

Just to give you an idea of how much more responsive it is. I, don't know that this Dropbox link is going to look forever, but the blue dots here represent in seconds sort of how long it took for each and every one of the dashboards to return a response. When hit for the first time- and you can see some of them served longer than 10 seconds, whereas with the gala version yeah, we do have a few outliers at five seconds, but almost all of them are much much faster, isn't it.

A

This is kind of a logarithmic scale.

A

Faster tools are better. You see the data faster, it's great, so Pratt's been getting a bit of a facelift. Lately, thanks to a new team member on the GK Inspiron team, whose name I don't have off the top of my head. I apologize, but you know we set up this bot Kinnaird redirect a while ago. For folks, you don't know all the various commands you can use on pull requests just used to link to a markdown table.

A

It now links to a live copy of Proust pounds. The thing influence on these box events- and you have sort of the committed self.

B

On the left hand, side so.

A

An example usages effect from in here the description of what the community and description can do it. You can also here.

B

A

Gonna hide this thing here. You can also see the that implements it so, for example, the assign plugin I can click on that and get information about the assignment.

A

There's a bug right now, or this doesn't entirely work for all the repos. But the idea is this page right here is showing you all potential commands that could be used anywhere ever. But if you are interested in the commands that just learned say in the community repo, when we do a list of the commands that weren't there, the eagle-eye the most, you might notice that there are more repos being supported by crowd than just community's repo, so like flow, for example, is using just these commands or CRI is using these commands.

A

This is all because Pratt was just like way way easier to administer than multiple munch github instances.

A

We sort of have the same thing going now with plugins. So I went back to the doctors to show you that link, but I could have also gotten there from this menu on the side here hopping between the command, help list available, plugins and again so most they're. Not all plugins will influence um some of those commands.

A

Some of them implement some automation, that's not necessarily accessible, and so this just gives you an idea of all of the potential communities that you could set up for given repository or github organization that proud that they get to support so, for example, the lifecycle plumbing.

B

A

Take a look at that and see what commands that has, and this one lead me through the community page.

A

Okay, do how are we doing with type these days? So if you look at the umbrella issue for our attempt to roll out tied ties, the thing once you replace this would make to you right if I go and take a look at the time you I, um it shows me that it's potentially looking at all of these pull requests here when this bird requirements tab shows me that tied has a couple. Basically, just you know, queries we're tied at Louie looks for the set of issues course I setup or bust scheme.

A

These repositories that have these labels that don't have the labels have all of their checks. Passing there's another query here, for example, that's running just for the coop CTL label: that's making sure they only have the CLI label and that they don't have. These do not merge labels. However, there is the requirement that there's an actual approve of you. You know, submit your review and you actually submit it instead of /lg jamming, you get this nice little check.

A

Mark icon there, so it's pretty flexible but we're trying to move to a world where most everything uses the same set of virtual climates. Here. One of the big things we want before we roll it out to kubernetes in general is a more representative or user-friendly way of understanding what needs to be done to make my pull request merge.

A

So if you take a look at this discussion here on how best to represent ID status right now, you may have noticed you're getting a tied status, just like not in tide pool or something like that, and so we're having a pretty lively debate about the best way to represent this.

A

Ultimately, we want to get to a world where the existing kubernetes, rico kind of for any pull requests than bunch github submit queue, has a status context out of the bottom here so make you write, and it kind of tells you why this would make you doesn't think the pull request is ready to merge. Yet this isn't the most in-depth piece of information, but it's something we're trying to get tied to basically do the same thing where.

B

It sounds like we're, not tides.

A

Not ready to merge us because all the tests aren't passing or because it seems to be missing labels, things of that nature, if you're interested in participating in that discussion, you're helping us flush this out, because I'm going to always encourage and welcome you cliff from the wire audience. Instead of just a select few people, this would be the issue go. Do that um something that's coming up, we've been looking at, as you may know, use basil to.

B

Do a lot of the building.

A

And testing on our CI.

B

Infrastructure.

A

Because it's really good at knowing exactly what to build, how, when basil, has recently introduced the feature of remote caching and we're looking at this force of our jobs, it's taken some of the jobs down drastically in terms of how long they take to build some other jobs that were just intensive, maybe less so so, hopefully, just as with tax period, where things just kind of magically that faster pull requests are gonna, magically, start passing or daily and faster.

A

We have a proposal out there to make it easier for folks to upload their conformance results to test grid. Right now to get your stuff into test grid requires that you upload things to Google Cloud Storage according to a set of sort of a schema which I think I can click here to get to yeah. So if you want to contribute test results today, here's the document that tells you how to do that. This is in.

B

A

For repo in the docs on directory cost, which would be in customers oats and basically, you need to make sure that you upload to Google Cloud Storage bucket. That kind of looks something like this and put the right metadata. It has started JSON and it finished JSON. You put a log here and then you put your test results as Jade unit files.

A

So this proposal is suggesting that perhaps we take the output from Salonika, which is what's used to generate conformance results and see if we can, just from the artifacts from side, employee generate the appropriate JVM files to stimuli as if attested actually run and then get those places up into test. Great because we'd love to get to a world where underseas saying they're conformant aren't just submitting pull requests, but they can actually point to a lot of dashboard that such as continued conformance compliance or continued conformance certification.

A

Whatever you get the idea and also have had this hanging out a little while ago, I'm going formalize this proposal here to you document what the suggested criteria are for police blocking emerge, blocking tests in terms of ownership and in terms of some of the qualities of the tests, including like how often they run how long they take to run a coughed and they pass you in the same commit things of that nature.

A

How am I doing at one time? Okay, it's been a bit of time. We want to do one more minute, yeah sure, so another thing I want to encourage folks to come talk about. If you have any interest in this is the concept of doctor and doctor or a local cluster based on doctor and doctor, we want to get to the world. We're ready to be tests, doesn't involve standing up a full-blown cluster with a cloud and all of its virtual machines.

A

We instead want to get to a world where there bunch of docker containers that basically represent the cluster. In fact, that would also be super and extremely useful for local development. This has been ty trying, time and time again. There are multiple implementations out there. I've heard that cluster and lifecycle has some scripts to do this around I'm Rachel's based project, and we basically want to get to a world where we kind of converge on one effort and try to use that going forward.

A

So we had a healthy discussion about this February 6th, a testing meeting we're looking to put together proposals, so we can get folks to rallying around iterate. This is the sort of thing where I would expect. Testing Commons is going to be the place. We're gonna have the most discussion about this in the interest of making it a reusable framework, but yeah Jesse you're totally welcome to help. So a hundred percent of eight sounds awesome.

A

Thank you very much for extensive update, so our next update is from sync contributor experience, so Paris.

F

Can you hear me yes,.

A

F

Everybody I'm Paris from contributor experience. I am going to share my screen as well. One second here.

F

All right, everybody see my screen thumbs up all right, cool all right. So, as I was doing, these updates I realized how many awesome contributors that we have so I'm actually going to do this backwards, and thanks so much to all the awesome contributor that we have helping out in contributor experience for a wide array of things.

F

Brief name drops George Aaron thought of Tim Quinn, so many of you that have jumped in to really help out with this. Thank you so much so. First things. First, our Charter. The draft is now being socialized within our group, I'll, happily screenshare that I won't necessarily fit. It is still rather raw, but this is coming from the TLDR short version of the template from this airing committee. That's being circulated right now for approval.

F

It has not been approved yet, but we thought we would get ahead and it's actually given us some framework for what to do so. This is just our Charter and I'm about to actually go through in depth. Some of these items that were actually working on right now, but you should be seeing this checked in I'd, say within the next week or so after we get some more circulation and feedback going from our crew next contributor. Guy, that's been a huge chunk of time for multiple people.

F

We started out with about 65 pages of just contributor guide content, which is huge. That's not, and we're not actually talking about developer guide, either developer guide would bring us to something over a hundred pages. So what we're really trying to solve for here is a discoverability lots of folks say that they can't find any certain contributor documents and then also holes on the process, documentation, broken links and, of course, adding a better flow to the contributor guide documents. We have a new area in cake community for contributor. That is right here.

F

This, like I, said before, includes developer guide, as well as contributor guide information, for instance CLA info, but the discoverability piece is really important, because a lot of us thought we should have contributor and developer guide information on kubernetes io. It's where a lot of people are looking for documentation outside of just github from from the project. So, as you can see right here, this is live big kudos to dr.

F

Chand, Quinn and other folks that have been working on this behind the scenes, but we actually hope to have this out the door with an MVP, more formulated by the 1.9 release, so check back for more information. With that, um let's see what else mentoring that's been a huge piece to to our PI. Here we really want to focus on the contributors and membership growth. We do have a membership ladder here. I should put that link in the in the agenda.

F

I will in a second actually, but those are member reviewer, approver, odor maintainer each one of those staffs has different roles and responsibilities, which also includes different skills for each one. So we are really focusing on each one of those latter roles, as well as trying to prevent things like burnout and also just increasing learning and development for the kubernetes project in whole.

F

We're in a testing phase right now with every proposed idea that we've had thus far we've been learning a great great deal, one of the things as time zones up and we hate them, but that is taking place right now in our group. Mentoring program group mentoring, the ideas coming from a peer networking here peer mentorship, one of the main problems that we're trying to solve for is time. We can't grow time from trees and I. Think time is something that we hear from mentorship as to reasons why people don't participate.

F

We are all super busy folks, but we know that mentoring is important, so that was taken into consideration and a great deal when establishing all of these processes and programs. So brute mentoring is exactly what it sounds like 10 10 to 12 folks, who are all achieving the same Heol. So, for instance, for this test cycle, we have 10 to 12 members who are all going to review ership in 3 different projects.

F

They all share a slack channel, they do stand-ups and then we also have workshops for them, and those workshops are in development as we speak. Tim Hawken actually just did a code review the kubernetes way yesterday and that was or actually Tuesday, which was an hour alone, and he actually did not finish so. We know I think we need a kubernetes 101 code review and probably a 102 code review. He didn't even touch the API pieces, so this is all growing and from us we have.

F

We started with milady, so we also had Larry Apple come and do a one hour, interactive communication course and that's something that we're trying to build from these workshops is interactive sessions to add value to the people that are taking the time out. To give this one hour to sit. There join this one hour process and we have great feedback so far from the workshop based classes from the the groups that we're working on and the group mentoring piece would take about three months. Why three months?

F

Because that's how long it typically takes to get from each rung of the process. According to our membership guidelines, if you disagree with that, please comment on the community membership down file, but that's sort of what we were going for here to stick with those requirements that we've laid out unless they otherwise change.

F

Google Summer of Code shout out to Nikita for helping us run that she actually was a former Google of google Summer of Code intern for the project and has now turned into lead. So that is definitely a success case worth mentioning. She I, don't believe, needs any help for that at this point in time, I think they're just kicking off with mentored Archana, and things like that.

F

We've also participated in outreach e, which is also still going on. We have to outreach interns for those who are not familiar with outreach II, it's a third-party program run by Sage shark and others who who pay for underrepresented folks in tech to have an internship experience with major projects such as kubernetes, different Linux, distros, etc.

F

That is also it's a long-term solution for us, because these are three to five months long semester, type of deals both of those individuals sit in six CLI and they were paid for by CN CF in Google. So next round we would love to seed more organization stuff up and sponsor this effort, as well as other things, and then we also have another program called that I'm proposing called the Buddy guide program if you've ever.

F

If you were like good for calling last year, they had a program called the Buddy Guy program for folks who were new to go and new to do book or con I'm, actually trying to think of extending that to a longer term solution.

F

One-On-One mentoring is the traditional elements, so this is kind of getting us to that traditional except again, public. The time factor involved we're talking about a one-hour one time, sort of tour guide of the kubernetes ecosystem, and that would be with a contributor of like a higher higher rung ladder than you and just kind of a quick ask. That's anything if you will that's just proposed right now. For short, you may or may not lead this effort, depending on what the thoughts of other people are with this project also meet our contributors.

F

That's a very short-term, quick way of getting mentors on demand. That's a one-month right now, once a month program, I get to expand this to at least bi-weekly, but what we're doing right now is sort of an access anything. We had our first one on the first Wednesday of this month and it went really really well.

F

We had about five folks of many different browns and varieties on the call, and we took questions from Twitter and slack, and that was really really awesome, so we need a lot of help with us, especially the issues and things that are located within the agenda. Again. I already mentioned the outreach pieces, but we also need more contributors for the meet our contributors pieces. Oh No. Can you not see my screen anymore? ah What on one? Second? Don't move? No.

A

We still see your screen all.

F

Right, it's just our room. I can't see the screen all right, cool.

B

F

Are equal so what I think Oh need more contributors for the meet our contributors? Peace again. This is just you being on a livestream to call answering questions. Most of the questions are more on the human side than the actual contribution side like how to do open source. We had a lot of those questions. We also have a lot of questions about. Where do I start, and it's just giving your opinions on those things. So there is an issue link for for signing up for help there as well in the in the agenda.

F

We also need a lot of help with building skills workshops for this group, mentoring and future home of kubernetes learning and development. Examples are in the mentee guide of what I'm talking about and just like what I mentioned earlier surrounding communication code review. Writing rating release, notes writing better documentation how to be an approver. You know the list can go on and on and ideas can go on and on, and we really need help with identifying the skill set. We have gaps with.

F

So if you are, for instance, an approver and/or owner maintainer, listening right now think about the ways that your contributors could be better. You know not necessarily in a selfish way, but as just from a growth perspective like how can we grow the folks that you have right now? That's very important, also keys they about if you're a cig need how you're actually growing the mentors. What the strategy is that you have. How can we plug you into what we have right now from a testing perspective?

F

Please reach out to us: that's it for the mentoring piece. Next is dev stats. We are sort of reverse engineering, dev stats. At this point, we really need feedback on the data that you want to see and specifically what questions do you need answered about the project? So that's the reverse engineering part. So if there's anything that you've ever wanted to know about this project, what is it and we'll try to figure out what the best dashboard is for that approach?

F

We realize that adoption of the tool has been a little slower than most shout-out to sig. Docs I was in their meeting yesterday, where they used a graph to establish some s elbows for response times, that's exactly what the tool is for and if you are not about, have not adopted the tool yet. For any reason, please see us. We've constantly are filing issues with with dev stats on things like hey, I, think some data is missing, etc. So it's very important that we get this right.

F

So if you do see data that is missing or inaccurate, please let us know if anybody on the call is interested in sax metrics, the health and life of the project, how we're measuring velocity health, etc. We need your help so come see. Us next is documented in improving communication platforms. That's a big deal for us. We did release in slack guidelines. We are working on new calendar solutions.

F

We are also working on issue triage and labeling. We've proposed and created a triage solution guidelines also newly new labels. All of that is in the agenda. Please provide feedback there and then some miscellaneous items we are going on a road show what this means is we'll visit. One of us will visit every sick and working group meeting from quarterly based to make sure that there's you know a feedback loop.

F

That's that's closed, ultimately, making sure that your group is cool with changes from a contributor experience side that are either going on or have gone on, to make sure that everybody is on the same page and also get feedback from you and how we can make this better. um We are having a face-to-face, that's Tuesday, I'm, sorry, okay, um we are having a face-to-face. This Tuesday at the index conference it'll be about eight to ten of us swing by if you'd like to help us get through some old PRS and things like that.

F

We are also doing the contributor summit again this year at the Copenhagen cube con. That is May. First, more information will be coming out about that in the next week or so. This is an open invite to all contributors. We are changing the format and we'll have a lot more new contributor components this year as well.

A

Thank you very much. All.

F

A

And still, thank you very much for the summary of lots of in Trebek's activity um being will sniff. uh If you give us an update on what's going on with cig api machinery,.

A

And I wanted to thank Daniel for agreeing to swap with cig AWS who's going through some leadership changes. There's someone there update next week, okay! Well, this will be a loadrunner update them.

G

So I've got a much shorter update in the last couple, so sig Apia machinery we own the hub of the kubernetes hub-and-spoke model, just like I, should give a plug for what we do since I see a lot of PRS and issues assigned to us that that, because, if we owned the API surface, which we don't, if you want to make freakin wide-reaching API changes, that is there's a cigar detail, we owned the things that make a P I function.

G

So if you want to change the mechanism, if you want to put something in metadata, you want to add an extremely format. Something like that. Then that's our responsibility, yeah. So.

A

G

Own more than that, that's a very brief overview. So things we are doing, the aggregation layer is going to be one this release. So if you have experienced that a few bugs, please give us feedback very soon.

G

Yesterday, I sent out a rather large design dog proposal for an evolution to keep control of fly. I sent that to I started out with three SIG's CLI apps and games cheering one of the PBRs I'm gonna, move it to the control plane. So.

A

If you have thoughts on that.

G

Look in one of those sig groups or I can share it in slack or something I'm. Probably after I've gotten some feedback I'll send it to.

G

You can put a link.

A

To that in the notes.

G

For today's meeting sure next next up would be those notes and and everybody's dev and I. Imagine we'll probably have to talk about this at sig architecture, so that would be the timeline for that would be rather long, so maybe maybe longer as well, and alpha and 1.11 certainly not trying to make major changes for 1.10 next on the list, I would like to put out a request for feedback on the web book.

G

The admission web, both mechanisms, if you have used them and had good or bad experiences, please take something in the API machinery slack channel or come to one of our Sigma T's or send us an email on the sick list.

G

We are not advancing the web books this quarter, but we may want to next quarter, so we would really like to have feedback if you have any finally want to say some things about some code changes that were making my colleague Walter threaded the go context structure through the cloud provider provider interface recently. So if you implemented a cloud provider, you now have a new parameter and we are debating doing the same thing or the go. Client, the downside is that anybody using defiant would have to make a CO change.

G

The upside is extremely mechanically right, a arm7 combo to fix all your code everywhere. The upside of doing this is that we gain in the future the ability to implement, like request, tracing cancellation, propagation right. So this is this is this is only at the moment a change to the interface of the go client, but it seems like a good idea to change both the client and a cloud provider in the same order, so want to put that out there so that it doesn't catch people by surprise. If, if you think it's not worth it.

E

G

You can come to bait with us in a big meeting. I think that's all I had scheduled on the list, though you.

A

G

A

You very much for for pitching and for delivering that update. The people should take a look at those changes. So a couple of announcements one is, we will be having our regularly scheduled office hours next week. That's next Wednesday, again in two different time slots. This is for people to meet members of the community and bring up problems and talk about contributing and all kinds of other things since next Wednesday conflicts with both the helm summit in the UNIX conference.

A

If you are not going to be either those events, we really need you to show up for office hours so that there are people there. So please do volunteer for that, and then we have one last topic here, which is to discuss LG TM and a an automation, behavior who's, going to take the lead on that that Aaron, try and hurry real quickly. So I wanted to raise this.

A

In the context of the principle of least surprise I introduced tied to the documentation team on the website, repo, the documentation teams code review process up until now has been that they need an lg cam label. From somebody who says this looks good from a Doc's perspective and somebody who says this looks good from a technical perspective and they were surprised when we put in an owner's file at the root that gave lots. People approval privileges that, when they /l GTM it automatically LG TM and improved things and things started getting merged. Unexpectedly.

A

This was a little weird that an LG, cam command would act kind of differently, depending on who they were and where they were in the directory tree. um I'll share my screen real briefly, but I'm kind of coming back to an issue I hit here in the community a couple times which is of trying to find the right forum to discuss, process level, changes or process level issues and make sure that we're talking to you enough of the community and getting enough feedback for the community.

A

So what I was proposing was the ability to say that LG Chem should only mean LG, TM and accrued should only mean approved. Now there are many of you on this call who are approvers in the kubernetes repo, at least I'm. Pretty sure there are, because there are about 146 approvers and the community's repo, so I'm.

B

A

Setup you are hopefully on this call and you may be really used to typing /lg TM and having it automatically issue an approval as well, but this concept of LG TM and approval of reviewer and approver kind of seems like something I keep having to explain to people as I walked as a to them, and so I was wondering if we could make this possibly more explicit. um It's generated a little bit of conversation.

A

What my concern here is the conversation on this issue has mostly been between few folks from contributor experience, a few folks from box and a few throats from sake tested that I haven't hit enough with a larger community. To me, somebody's been with this project for two years. I still find that this is a very magical way of doing things. I would like to find a way for us to move to more explicit hands.

A

Where else you can just means LG, TM, to prove just names of proof would mean that for 146 of you, I'd be increasing your workload by over 200% by asking which type of couple more keystrokes, but I mean this also kind of comes back to like I said: Doc's had a different code review process initially, where, like they had LG TM for docs and LG TM for tech and we're trying to force them into this exact same code review process that kubernetes core uses.

A

It opens up the question: should every repo in this project be using the exact same code review process, or can we allowance become that you're going to read the basis? I was hoping to have this discussion here, but we only have five minutes left and my Mac is kind of about to die. But does anybody have any thoughts or feedback on this.

E

Well, I'll give just one one bit of feedback: I think that a lot of people are interested in contributing across the project in different places and having a consistent way that everything is done across the project is super super important I really just can't say strongly enough. How much I say like configuring. Different policies for different parts of the project is going to add to confusion and overhead and all sorts of productivity issues. I.

A

See Brian has.

D

Moved closer to the microphone, yes yeah, so I'm, one of the people who suggested the docs try this workflow I mean in general I'm in favor of making it approval explicit. However, in this case, it seems like if.

D

You know the if the people owning the documentation are in the approvers file, then I don't quite understand the problem with approval from a doctor approval with approval from a Doc's perspective.

H

Example yeah, so you know since I'm a cig, maintainer and I'm an owner of a lot of these things like when I create a PR because I'm working on something it will automatically set the approval since I'm right and then someone may come come by and lgt em it and it auto merges before like we actually wanted to go out, and so what we're trying to prevent is these like wait, wait, wait or.

D

It's ready to go back.

H

Up a little bit, what kind of who is lgt ending it so well, we need to write because a lot of times we need both a tech and a Doc's went, and so, if I create a PR and someone comes by and does you know like the tech lgt on, but it hasn't.

A

H

The doc LD TM from someone else besides me, then it will merge, we're just trying to heal it's important.

D

For it to actually have doctor LG TM from someone other than you yeah that you're you know contribution that is not sufficient to make sure that it adheres to the doc conventions. You just want a second look at that: okay,.

H

Right so we're just trying to prevent these like merges before we're ready to actually merge yeah, and then we could have everyone say you know explicit, like you know, slash hold, but then it's you.

D

Know I can tell you what I do I get called in on a number of specific issues like does this API look? Okay, or is this approach? Okay? So in those cases when I'm not LG, teaming the whole thing, I don't actually use the commands.

D

I just say: yeah, it's okay right, so it's I mean it's a little bit less formal, but in general someone is specifically asking specifically me: I, don't know if that's the same case exactly for a technical review, whether we need labels to be able to identify things that have been tech approved, but not Docs, approved whatever, but I find at least for my cases that handling it informally seems to work another.

A

Use case I'll put out, there is I happen to be in the owners file at the root of the community Rico. So there are times when I want to say that a document looks good like it's grammatically written correctly, and all the words are in the right order, but I'm not necessarily.

B

A

Subject matter expert for that particular domain and I need somebody else to slash, approve it but like if I /lg TM, because I'm in the Roadrunners file isn't a printer. It's automatically going to assume I'm approving it as well. So I.

D

Don't think there are any number of states that we can introduce that solve this problem globally, because there are a bunch of cases where we want. You know certain other people to look at certain other aspects, and it may be more than one person looking in more than one aspect did.

A

I get that I get that that's kind of why we can organically use this hold label. To me, it's just that the /l GTM command does something different depending on who I am and where I am in the tree and I would love for it to me and just LG TM, with nothing explicit thing right at.

B

A

Surprised and who's talking about the implicit self-approval feature which we do actually have is a configurable option. Within this mix you and I agree. I would look for consistency across the project I'm just trying to raise the flag that newcomers who I've tried to introduce this stuff to are confused by it and I think we could reduce that confusion.

A

If you make things more explicit when I have tried to raise this issue in the past, I have got no pushback from key and core contributors on the project, I'm trying to figure out how I can have the most inclusive profession and get to assay decision with all these people, because we talked about this once a contributor experienced yesterday, and it was kind of like an echo chamber where everybody agreed. You should make everything super explicit, but I don't want that.

A

You know move people's cheese without telling them so to speak, so I'm trying to figure out how we can proceed from here. I.

I

Have an idea: um I mean I, don't know why why don't we I feel like um the main problem is: is that if an owner submits a PR and then somebody drive by LG TMZ, it gets merged and it doesn't get the review they want. So why don't we just remove that implicit approval?

I

It's always an option, but but you could always make it an option for owners to self proof separately, so don't make an implicit but make people explicitly slash approve their own PR. If that's what they want. That way you can prevent. Oh, my gosh I wanted to you know, get feedback and just magically merged and I didn't mean for that to happen.

I

Wouldn't address at least part of it sure.

H

But I also think like the LG TM should not have approved in it either because, like I for our workflow I may want to LG TM it on the dockside, but not actually approve it to go out. I.

D

Think you're agreeing yeah.

A

It sounds like an agreement via so I. Think we're gonna need to continue to discuss this. The because we're out of time in the community meeting here, I submitted a thread about this on kubernetes, dan and I will follow up there and thanks to the issue, I showed so okay there, but, like I, said, I want to figure out how to drive this forward and make sure like Ian agreement.

A

We might also want to find a time slot the contributor summit for this the anyway. We need to wind this up because we're over time and some people have already had to drop. So thank you very much. Everyone for participating and I'll see you the next community meeting and online. Thank you.