Kubernetes SIG Release, 20 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 20210420 SIG Release Biweekly Meeting

Description

20210420 SIG Release Biweekly Meeting

A

Hello, everyone to our seek release meeting um this meeting is being recorded, so please adhere to the kubernetes code of conduct, which basically means that be mindful of what you say and just see be friendly to everyone else.

A

um We have a few guests on the call today. Most of them are already well known, but do we have anyone on the call who would like to introduce themselves for sick.

A

A

And if this is not the case, then let's move over to our subproject updates. So is anyone from release engineering here who would like to provide us an update about this sub project.

B

I can uh give an update if no one else uh has anything. um I know I saw here that uh jeremy uh mentioned the another 1.18 patch um adolfo. I think was it you or carlos who had um commented that you had spoken with stephen, and that was the the.

C

Plan, I think it was a thoughtful and adolfo has another meeting running concurrently.

B

Right now, oh gotcha! um Well I I believe that is um the case. Did you have a specific question.

C

We had removed it from the schedule already, so I was just curious if we were going to do it and how we were going to publicize that we were doing it. um I got pinged by someone asking if we could include an issue. Let me grab the issue and drop drop it in chat just so. We have it.

B

Yeah, I notice- and I can uh let me grab the comment here that specified that we would uh do another patch here, but we definitely need to. um We definitely need to publicize that um I was under the impression we would potentially um add that back to the schedule, but it doesn't look like that's happened so um I'll make sure to follow up and make sure that that is uh publicized here, because it's just right now. It's just a comment on the pr yeah that removed.

B

1.18. other than that, I'm not sure if there's um any other uh critical updates um that we won't cover in the uh next week's release. Engineering meeting.

A

Maybe one thing we can mention is that we have decided to use the mailing list a little bit more for official communication, and I think we all agreed on that. We want to announce patch releases in the future on the sick release mailing list, as well as on the kdf mailing list, which is kind of an improvement from my perspective.

A

So thanks to marco for taking the opportunity and writing up the email, I think we can send it out today or tomorrow.

A

Anything else related to release engineering.

B

uh One one small other thing: we will have an email going out about a release, manager, associate program, kind of describing that and some of the responsibilities of that.

B

If anyone on this call has any questions about that, I think uh most. The folks here are either already released. Managers release manager, associates um or are are likely have other roles in the kubernetes community and would not be I'm interested in in that role. um But if you have any questions, definitely feel free to reach out um and and look for that email and coming.

A

All right thanks! So let's go over to the next update from the release teams. Anyone from the releasing here would like to provide us an update on that topic.

D

Hello, everyone um hope everyone could hear me. um We we have gotten the shadow responses and the role uh sub team rollies are working on it and uh I have created couple of bootstrapping prs and I.

E

D

E

D

On creating the rest of them throughout this week, that's all stopped it. Anyone has any questions for the release team.

C

I would just add one more point: the part two of the retro will be today um on the calendar. So if anybody uh is interested in attending the second part of the release, retro um check the sig release calendar the invite went out yesterday. I think uh it's at 11 pst taylor. Can you correct me.

B

11 a.m: yeah, not.

A

Taylor but.

B

Answering for him cool yeah.

A

Awesome. Thank you.

D

Thank you, jeremy. For that I I have to make sure that I am there for that. I feel a lot better today, so.

F

When does the schedule, when does the schedule go up.

C

I think we were.

F

Waiting after we passed today's cap.

C

Yeah, I think we were waiting waiting to thumbs up our thumbs down the the plan in the cap before we finalize the schedule, because there obviously would be impacts to uh how long and when that would end.

A

All right, I think this brings us to the next topic- the release cadence cap um yeah. From my point of view, the cap is are mostly ready for approval, but jeremy, do you want to give us a short summary about the current cap and what it describes and where we are yeah.

C

Sure let me share my screen real quick, just to bring up the table and then we can walk through a couple of.

C

Points come on zoom. I use webex at work now, so I forgot where the screen sharing button is on zoom.

B

You're not doing your job if you're, not if they don't make you find it. This is what I found.

C

Okay, so notionally what the cap is proposing is transitioning from actually continuing the kind of three releases per year that we adopted in an ad hoc manner in 2020 um in response to the ongoing pandemic and other things, uh but in a more structured manner. So in 2020, obviously, the 119 release was quite elongated. The 118 release, kind of was more traditional and then the one night. So the 120 really is kind of split. The difference between those.

C

What we've landed on in this cap is providing some lightweight structure around building schedules out, so that structure or guidance includes releases should be around 15 weeks. Releases should have around two weeks between them. We should finish before mid-december for the last release of the year and again, three releases would be the cadence for the year we put together some notional timelines here. um Obviously, these things could change based off of events, but this builds out what it might look like for 120 for 2021 and what it might look like for. 2022.

C

we've incorporated feedback from from josh and jordan in the most recent round of comments on the 2022 schedule to bring the release date back a little bit uh landing at 14 weeks for that last release of 2022, but in general uh what we end up with is pretty predictable timelines. So in each year the first release of the year will be in april. The second release of the year will be in august towards the beginning of august, and then the last release of the year will be towards the beginning middle part of december.

C

We've noted when kubecons occur in here. Just so, people are aware in the schedule. We also note that we will pause all release team activities for the week of kubecon. We've done that for the last few releases, starting with 119. I believe so. We did that for 119 and 120..

C

um The the cap will be in alpha for 122, and then uh we will focus really hard on communications during 122., for example, we're going to attend the the first of the new community meetings that are kicking off this week on the 22nd present this cap and the changes that people can expect at that meeting.

C

Kind of tying back into the point sasha mentioned earlier, we're going to lean really heavily into the mailing list communications, so we're going to as soon as this cap merges we're going to prepare a nice, formal, write-up detailing all the changes that will go out and then, as part of the cap existing in beta, it's policy kept, but we're still trying to stick to those.

C

You know kind of graduation criterias we're going to collect feedback in 122, 123 or sorry 122, 123, 124 125 to just gauge how this is going and then make a formal decision about whether we revert or continue this going forward. Past 2022.. uh We didn't want to make a change in the middle of 2022 just to make things consistent for people um kind of the same reason that we didn't want to revert in 2021.

C

We've kind of carried this three release cadence into the year so far, um don't want to change mid-year and kind of end up with funky timelines or uh big surprises for people. uh Hey, suddenly we're back to four, and then we go back to three in 2022 if the cap was adopted, um so that's kind of in broad strokes.

C

uh What the the cap is proposing uh just summarizing again formalizing the three releases per year that we've adopted in 2022, giving some structure and guidance to release calendar planning so that people have a better idea about when these will occur and just general policy decisions around what the schedule should look like.

C

Did I summarize that pretty well sasha lori.

A

C

Miss anything all right.

A

So now is the chance to raise some additional concerns and that we can take some action items to follow up on.

F

The only one thing that I can see that's still missing from there is: when do we do the evaluation on whether or not three releases a year is working for us.

A

Yeah, we created two follow-up issues um which are also now part of our sick release, north star vision, and one of those points is the creating metrics around the cadence and also creating the survey. So since we did not agree on the exact point in time where we want to do the survey, which is probably the end of the year um yeah, but this is this- is now under evaluation and should be part of our overall vision.

F

Oh wait they my last reading the cap. There was a survey that would go out with each release. Did that get removed.

A

I don't think so, so I think we, I think it would not probably make much sense to create a survey for every release for the next release and the release after the next release, but we have to create a plan how we get contin continuously feedback from the end users.

F

Well, I'll I'll attach it to a follow-up just because I can think of other things we could put into a per release survey, which would make it valuable beyond just checking this in particular, um so I'll follow up on that.

A

Yeah cool sounds great.

C

I'm dropping the two uh related issues into the chats or anybody that missed them. Inside of the long scroll of the cat.

G

We'd mentioned at some point um asking the cncf to help us with the survey. Is that still on people's minds?.

C

Yeah, I think so I reached out to um contrib experience and uh specifically bob killen and asked what kind of mechanisms do we have for conducting surveys right now, and I don't think there is a really solid answer for how individual sigs would broadly survey. The community like there are ways that we can reach out to contributors, but there aren't really great ways where we can reach out to contributors and end users, and I think, really getting the end. User feedback is important here. um We're impacting both both groups.

C

Right, like this impacts, developer velocity and contributors, but it also impacts all the downstreams. In the end users, yeah.

F

The way we have.

D

Go ahead, go ahead.

F

Contributor experience survey dude here, actually um the um so um the way that we have to reach end users is we actually ask the cncf, and then this would be a survey. We could only do one time right. We can't do this with every release. um We asked the cncf to use their pr mechanisms to advertise um the survey yeah and that's kind of the best that we can do in terms of help from them.

F

The other thing we can do from our own community is obviously to reach out to the various vendors and and ask them to ping their end users, if they're available for it.

G

But cncf has the possibility to ping the whole end user community at one time right.

F

Yeah yeah, the cnc event, user community right.

G

Yeah, so I guess it would make most sense to be faster. If we just did it through that network they've got.

G

What do you think.

F

Yeah, so that would be a one that would be a one-time thing and and would be important to pin down a couple months ahead of time at least yeah we'll need to coordinate with them. um Among other things, they won't do it. If they're doing a big publicity push around something else,.

G

All right so I mean what I would. What I would think would be to save that survey for the end of the year, but if they have those other con conflicting interests, maybe we need well.

F

We need to. We need to make our decision at least one we'd want to make our decision. At least you know two or three months before the end of 2022 yeah, because if we were to decide to revert, then we'd want to know that well in advance of recruiting a team for the that release.

F

So um and also you know again, for the sake of the vendors they're going to want to know well in advance, um so we'd really be looking at.

F

You know technically be looking at something around like august of 2022 and the problem there in terms of getting the cncf's help with it would be um kubecon stuff, which is, I will tell you, you cannot get anything out of cncfpr in the month leading up to a kubecon.

C

Yeah, I think that, with all of the timings and things that have to happen, it would probably need to happen during the second release of the year.

C

Send that feedback out, you know, send the survey out collect that feedback, um and then we can make the decision as we head into the the third release of the year, um which will start in august.

C

So having that feedback collected up to that point, I think, would be the ideal state and then we can use that time to determine. What's the uh what's the plan for 2023.

B

G

When does the cncs kubecon kickstart over the summer time, like is it july or august,.

F

In terms of when, when did they become obsessed with kubecon.

B

F

I said it's starting about a month now so kubecon fall, it depends on when kubecon fall is in 2022, which I don't know the answer to that.

C

Yeah I tried to get that date too, and I could not find a lockdown version of that date. Yeah.

F

It's not public.

G

But probably august ish would be still doable for the survey.

E

G

Least, because it feels like october is october november, is when they yeah so.

A

Okay, do we have anything else related to the cadence cap? Any concerns questions.

A

Because, if not, then I would like to kindly ask for approval again from everyone who is in the approvals list of this cup. I already approved it and I said, saw that dimms also approved it, and we are still missing some approvals from a couple of other six, probably so question.

E

Yeah it's joshua sterica. I was waiting until this meeting because I thought this was where the topic was going to be concluded. So, uh given the discussion here, I will add for node and uh architecture as well.

H

A

H

D

A

All right- and if you don't have anything else related to the cadence cap, then we can go over to the next topic, which is policy needs. I think this was from laurie right.

G

Yeah- and I don't have a big discussion plan because I wasn't sure we'd have time to get to it, but I think it provides another good segue and that we we've learned a lot from this cadence kept experience and we vow to be more open and transparent, collaborative about all of our policy and process related efforts, because um just know that it goes better when we do that.

G

So with that in mind, this list is of policy needs that we've been looking at for quite some time, and I think we could actually, with this group prioritize, get some feedback around. What are the priority items on this list so that, as we head into 122, we can spend our time tackling the highest impact highest need.

G

Topics that sound like a good plan for everybody,.

G

All right, um so I guess we just pop up the document.

G

Someone want to do that. I don't have it open at the moment. I was multitasking a little bit, but I can do that if you want.

A

Yeah, maybe you can provide us a short overview about I'm.

E

Just wondering if we.

A

Want to put those efforts also into the north star vision but yeah. We probably can.

G

Well, I guess that question can come up here, yeah yeah, all right, so I will share my screen.

G

So I think this is an exhaustive, exhaustive list. I don't think I miss anything, but the release engineering project board still has quite a bit of items in it, so there might be something missing, but in any case we have enough to get started and have a good discussion here. So the release cadence kip, is on its way.

G

So I think we cross that one out and then we have these items. The first one is how to build and ship artifacts of things when the source code is not within kubernetes kubernetes for things that are getting split out of kk.

G

G

This is based on.

G

G

So if we jump down to the bottom, this is the main. This is where this conversation left off.

G

The idea here was providing an outline and offering specific guidance on how to build and ship artifacts listings from the source, because it's not within kkk for things that are getting split up.

G

So that became the action item. Do we agree that that is the goal, or is there a different way to phrase this goal? That speaks more to the.

G

G

Do this again, I mean one other way to ask. This question: is that when this issue, this issue was filed in 2019? What is the core related issue.

C

G

G

I don't think yeah, there hasn't been any activity on the specific question.

G

It's primarily about cube adm, but the policy here would be general.

A

Yeah, I have to agree with josh's comment. This is probably nothing we can move forward from the secret lease perspective right now. We can raise the questions for sure yeah, okay,.

G

So I did ask this question recently in sig release. The idea here is that sig release needs to provide the guidance for this kind of question when you're building and shipping artifacts of things when the source code isn't in kk.

G

How do you split those things out of kubernetes? What is the policy, the guidance for groups that we want to offer.

F

Okay, so just a question of how: how did the artifacts get built exactly okay,.

I

If we can't, we actually have any mechanisms for that now or is this something we need to implement.

A

Yeah, I guess the the idea is to provide the frame around how artifacts, which do not live in kk can be built from a kubernetes perspective.

A

So where should they host hosted? How should they be built, and things like that so, for example, for ci tools, we right now cut the release on the cra tools repository and then we use the github 2 gcs tool to upload the artifacts to the bucket, and maybe it's a good starting point to elaborate how we could achieve something like this. If cube, 80m is out of three.

G

I did I missed that sasha. Can you repeat it because I was yeah.

A

We had a very lightweight process around how we so we can host artifacts on our kubernetes release bucket, which are built from a different repository and right now. I think only cri tools is using it, and this could be a starting point.

A

How, if we assume that cube adm is not part of kk anymore, then we draft the policy or outline the policy how the maintainers of cube adm can put their release artifacts in to the kubernetes release bucket.

I

I think, but this is only assumption- is that the biggest problem around that would be how cuba dm would push their debit rpm packages, because this is what we still depend on from google, and the question is: will cube adm continue to follow the community's release policy? Is it still going to be the same release, cadence and the same release versions, so it probably depends on that as well yeah. I guess all that requires reaching out to c cluster lifecycle and seeing with them what is the status and how are we going to proceed.

G

So that's a first step, maybe pinging them on this issue to see. What's our what's our introductory question or major ask other than how to proceed, what do we need to know from them.

I

I guess the first step would be to know the status. Are they proceeding with it, because that issue has been like not so active for a while, so we still need to check them out they're interested and how hard they want to push for it, and what is their priorities regarding that? If they want to go with it soon, I guess we can probably see how we can collab collaborate them with tone cap and some stuff.

G

Oh, um do you think that that's a sufficient introductory to like making the next step of progress on this topic? If so, we can move to the next one we're not going to solve all of these today. Obviously, the idea is, in my mind at least we just surface these topics and see what what we can do next to get them going forward.

I

Yeah, uh I would guess this is good enough for now, because, as joss said as well, not so much that we can do from the secretary's perspective beside providing guidance and it depends on how they want to go with it. So nothing we can do from that. For now, all right.

G

Yeah, so we can't really prioritize this either until we get more info and to sasha's point yeah. This is basically walking the board. It's just a policy edition um all right. Moving on to the next one draft, a policy for updating, go versions across kubernetes code base and infra.

G

This is also about cadence and timing.

I

Question about that one: is there anything we can actually do it ado about it, because the I think that we have some brief discussions that earlier in the process is mostly like ad hoc on the need basis. We check when the really go release is going out. Then we see where we need to update it depend of. Is there some series or something like that? What about release branches, so it is like, depending not sure, is there some cadence that go team is following, but I also think that they don't have something specific.

I

So I'm not sure. I think that there is some guidance on how to update the conversions. If I remember correctly, stephen created some uh templates in the cigarettes repository that are actively being used now as well, not sure how much is that up to date, but I think that it is in a fairly good shape, but know that I haven't really done the go update so far, so I could be missing a lot of context.

A

Yeah also with first break to the patch releases. So right now we don't bump go versions on patch releases, so we don't bump minor, go versions on patch releases, but sometimes we update them for the patch releases of the go versions for the patch releases of kk and I think a lightweight policy around that would be helpful.

I

Yeah, I agree with that. Maybe some documented casey release or something like that to just describe when we want and in what cases we have update, which conversion like when we upgrade batch releases, minor releases and so on.

A

Yeah and documenting which container images are related to building releases because they follow go versions as well, so yeah, I see a documentation, need.

G

I don't know if I got everything tell me if I missed some aspect of that.

I

Seems fine to me.

G

Okay, so who else would we need to involve in this discussion? Are there other stakeholders and who would they be.

A

A

But in general.

A

I think sick release and release engineering should be enough, but sick testing, probably yeah.

G

Okay, no reason for architecture.

A

Oh yeah, probably yeah.

G

What would what would the news be for them? What would be our message for them.

A

Probably raising the question: if there are any restrictions around go versions and kubernetes, we have to consider from a release engineering perspective.

A

Rather than keeping it up to.

I

Date, um one idea from my side: what about seek security for the information about the cvs and how those are imported to be included.

H

A

G

Should we reach out to the go team, there was a thread with them. The sig release leads. Should we ask them this question.

G

Is it necessary to do.

G

A

I don't think so.

A

G

Marco raised it marco. What did you have in mind.

I

G

I

G

Okay, so good to know, but not a blocker.

G

Is that an accurate assessment.

I

Yeah, it is, I think, okay.

G

And then should we check to make sure the templates are updated? Where do we think that they are or do we know that they are? Maybe someone here already knows.

I

I'm not really.

G

I

Maybe we can ask carlos offline because he has been doing the go updates yeah recently, okay,.

G

G

What would be our first step here? Do we have any obvious first step.

I

I guess possible first step would be that someone starts drafting the document that we come up with some initial skeleton or something like that. We review it share with other seeks that we mentioned at the bow and see how we can I iterate on it.

G

Okay, that's easy. um I can do that if I have the key sections.

G

If you just provide the key sections, then I can do that.

G

Sound like a plan.

I

Yeah, I guess we can do it async. We don't need to do it on the meeting or yeah. No, no.

G

No, it's okay,.

G

Cool and if we don't do this, what bad things happen.

G

A

Yeah I mean so there's the risk that we don't have documentation around updating golden releases and the people who did this in the past are not available anymore. So we probably miss musical release or echo update or sce.

G

Pretty compelling reason, so maybe that means that this will apply as higher to the priority list.

G

I think carlos is the only person doing that updates or is there someone else.

A

I think steven did it in the past as well right right, he's.

G

H

Sorry I just joined fully so I I was trying to to assess. um Is this the part of the of the uh go templates? Yes uh yeah? There are some issue templates for doing that.

H

They could you use a little bit more work because I tried follow one or following one of them. Well, what was missing really was the documentation, and so just following the template blindly, I got into a pitfall and carlos had to fix it, but I I think one of the manuals has not fixed. It's not is now has not merged, so probably would be better if uh first following the documentation, then the issue template.

G

Yeah, that's right. I now remember there's two aspects of this: the template and the policy dock itself and I think both are well. The templates are in progress. The documentation wasn't started, so I think we're just talking about getting this started, but obviously it's dependent on these being updated. So.

G

In any case, I think we have a little work plan here. What we need to do to get this going, which is plus one, should we move on to the next topic?

G

Okay, this one's been around a while as well, so the release cadence a lot of cadence questions, um a lot of tree features- and I I know that this has come up over the past years being super important. But it's like kind of a big issue that might require a lot of conversation and discussion.

G

I

So one question about that one and I think it is somewhat recreated as the first point: how much do we want to care about something that is out of trade like not eka or something like that, and that is not by sig release? Is there something we need to do about it? Beside relatively relevant to the first issue, we discussed about cuba dm that we provide guidance about how they can publish their stuff to buckets and so on.

I

Maybe I'm missing something, but I'm not sure.

G

Yeah, that's a great question. Is this something that we wanted? Oh or.

G

G

Looks like we talked about in.

G

2019 then it went to the pm which no longer exists, and I think that's where it uh came up in the context of cube adm.

A

Yeah, I think both topics relate yeah.

G

So here's my sad question from last may: what do we do.

G

That's what I do a lot.

G

G

Should this actually.

E

G

In the enhancements policy discussions, sorry.

D

G

I

To say that once we solve the cube ada mission or which one the comes the first, then we probably saw the other issue as well. So in case, if you have the kubernetes team to come up with some policies and so on, a part of this one will be solved as well, and a different way applies as well.

G

Yeah I mean: do you think that we should actually try to engage those folks, this cycle, with uh with the idea of like getting rid of some of these old questions through their.

G

G

Just on the face of this, and seeing all this conversation over the years, what do you think now is our best first step.

G

Maybe if you need more time to actually read the issue and go over it, then that's fine too, but if you're familiar with this one because you've looked at it. um What what do you think is a good step here to take.

I

Yeah, I guess some time to go through. It would be useful.

G

What do you, what do we think about looking at the discussion and then for our next follow-up meeting? We I we have identified the core, the core issue here, like from all of the conversation, what are what is what is actually being requested.

G

Specifically from this.

G

G

Is that a yes, or that was a question I.

C

Think I agree with marco that this really ties back to the the question around the qbdm issue, and once we define some lightweight policies around like how people ship issue or ship artifacts and deliver things, I think that really will drive the it will answer more questions or maybe open more questions for how we track those out of tree things.

C

But I think what we have now with the label of things being tracked out of tree is probably sufficient to to give people the idea of where to look for these things and who to go see because they again like they are tied directly to the bits of the release itself. So they're kind of out of the purview of the release team itself.

G

So then, it's just basically shipping, the artifacts, at least for now, yeah.

C

I mean there were other things in there too, like how do we tie these things back to test grid and um et cetera, but those things I don't think are really really team specific. There there's probably a whole lot of other things that maybe come down to enhancements tracking, but again enhancement tracking is really tied to the release. So I think, let's, let's solve that cube adm issue. First, freeze this one for now come back to it once we've resolved or defined something for the qba dm issue, and then we can.

C

uh We can peel off the layers of the onion on the other one.

G

Seems like a good approach. What does everyone else think any anyone want to add, or I guess we're also out of time right, yeah.

A

But yeah, I think, that's a that's the right approach.

G

Nice all right, so we made some progress today.

A

Thank you, everyone for joining and thanks joseph for taking notes. So if you have any questions around the cup, um the release cadence cap, so then just reach out to your slack and enjoy the rest of the day and see you soon. Bye, bye, bye,.

I

Everyone bye-bye.

G