Add a meeting Rate this page

A

Hey Craig looks like we're. The first couple on I will wait a bit here, for others join in.

B

And unfortunately,.

A

I'm in the car.

B

Or anything, no.

A

Worse,.

A

You.

A

Hey David, n'doul gonna, give it just another minute or two for a few more folks, hopefully to join.

C

You.

A

So we're basically five minutes, passing I go ahead and get started. The meeting is being recorded already automatically, but as a reminder for folks, this is a Caretti z-- public meeting, where we adhere to the kubernetes in CN CF code of conduct so be good people please. So in the agenda there were two things following on from the July 9th meeting.

A

There was some discussion about a cap and Dhaval started a draft document and then the other thing was survey results, discussion again with doll's name next to it and Dowell said he's in the goober right now, and he just bounced on and off the meeting. So for those two items, I, don't know how much we're actually gonna be able to have him speak to them. But doll. Do you want to say anything about cert the survey or the kept? Or do you want me to walk through the document.

A

Yeah yep I'm just pulling up the link to paste into the document and trying to type some notes as well. So there's a there's a link in the agenda. There I'll paste it in to zoom also, so this is a kept draft that da ville' started drafting up after the July 9th meeting. There's a fair amount of discussion in that meeting.

A

If anybody wants to go back and watch the video around the the release, cadence and support lifecycle and whether it should be annual and I guess from so I wasn't there, but from what I saw in the video, the decision was made to like, let's formally draft a Kemp, to propose this so that the link is there. The is called kept yearly, support, cadence and I.

A

Think the the basic premise is that one of the things has come up in the other two documents: the the one from Tim Sinclair and from Luba mayor were that an annual cadence of support instead of our nine-month cadence, makes it easier for downstream consumers or end-users of the project.

A

Because of how support Cadence's tend to work inside companies where people do supported services, so yeah, the the cap kind of goes into some details around that the motivations I think it's that the general stuff that we have discussed or been discussing in this forum that we're seeing and hearing from users and then specifically goals define a yearly support policy, as opposed to the current nine months. Define any prerequisites for that policy set a timeline for making the recommendation moving it to implementable.

A

Let's see what else is there in here, oh and while we say annual so in the proposal that actually says 14 months- and the point of that is that we would have four releases that are under support. I think is the the idea instead of three, but, as is the case today, with that third release, it's got a little bit more than nine months. Support, often that that nine months rolls over and there's usually a month or two in which one or two more final batch releases come out for it.

A

So if we added a fourth release in that that you'd end up somewhere around 14 months of support and one could then achieve a one's yearly, big update, if that's how that one operates, their clusters are prefers to operate their clusters now, the actual specific mechanism of that I think is, if I, if I read this right as declared out of scope like would you go from version 12 to version 16, or would you go from 12 to 13 14 15 16 there and how we operationalize? All of that would be the find elsewhere.

A

I think I'm double. Do you want to clarify anything.

D

On that, yes,.

C

I think in the project visits have mentioned that we probably.

D

Need n.

C

Minus 2.

D

Upgrades because.

C

Once you increase the number of releases, the technical debt increases as and when coming. If you look at the survey data, we actually have, we see a large number of consumers actually are on older releases and older release, the more the number actually so it looks like people are staying on older releases, unsupported releases, sometimes, and as and when more and more services go on.

C

This kubernetes clusters upgrade becomes difficult, so if they want to catch up, they probably need to do it faster doing it and minus one upgrade and plus one upgrades is expensive and costly so and also not predictable, so making it and becomes easier. So that's one of the prerequisites that we should probably also look at that.

A

Is there something magic about the there like in, doesn't imply like there's a LTS annual stream and you can upgrade from LTS LTS. But this is like in the in the existing cadence instead of just 13 to 14 years ago, 13 to 15 or.

C

Yeah I think it gives us every application policy. It's a try. Everything at define can be defined, as this will be supported for at least two.

E

Releases.

C

So that would, on other words, transfer to saying okay, we support n plus two cadence. Anyway, we are saying n minus one.

C

If you look at where it's queue, policy that would go to n, plus two, the upgrade start at you would go and say: okay, I can now support a client, a cĂșcuta can support up to n minus two and a couplet we'll be able to, and, and you will sup we will be able to say, PS or we'll be able to support n 2 version of couplet, so I think that's the that's how an to have great footwork and it just reduces the time I- have and also gives us an incremental goal of reaching skip.

C

Upgrades I mean jumping upgrades is stuff across four reduces of a fast project. So doing it incrementally is easier.

C

That's why it's proposed and upgrades it's it's easier to achieve the shorter goal from n minus one, especially with the maturity of the project, having a great testing coverage for API, etc, etc.

C

Do you have any comments? You think we can directly do an end-to-end for upgrades, I. Think.

A

That would be a challenge, lots of notable changes and, like you say in deprecation policy, still a question in my mind whether we, the the broader community, would buy into the and then I'm curious about from a customer or user perspective for a scheme like this.

A

If, if you're wanting to upgrade annually, if you still got a from goat 12 to 14 to 16 verses 12 to 16, if that solves a, if it actually solves a pain point like this having it make a significant enough difference for users and I, don't know what the answer there would be for sure.

C

Yep I think those are good points.

A

Craig, were you going to say something there's a bit of noise on the line so I needed just because it was hard to slightly hard to hear da ville', but I saw you unmute it I, don't know if that was intentional.

A

That sounded like cardinally, so it might have been inadvertent.

A

You.

A

So da ville', how? What would you describe kind of the state of this, like it looks like a fairly early draft, there's a bit of information there, but not like fully fleshed out? Where do you see this going at at this point? So.

C

The discussion in last meeting was: we will all contribute to this everyone who is tonight at the past. We have taken the pragmatism from the OMERS proposal and put this and we're saying: okay, we need to be pragmatic. Maybe we need to go step by step and slow, so those prerequisites are in there and Jordan, and everybody commented last time that we all want to be authors on this.

C

So it would correct me if I'm wrong Jordan, if you're already on the call but I think everybody wanted to be authors on this and they will probably join and then draft a proposal at different sections comments, etc.

D

Jordan's not on today with Lew Ayres Jolla.

F

Is on vacation? First of all, can you please update the link in the agenda, because it's a self link to the same document? It was what point to the document where the KPI.

A

Oh I'm, sorry, oh.

F

It's interesting to me. Like week, we had the survey and Jordan brought the problem with a petrification points and I agree with that. But what is the demand from the community? It's used to me like one year, I'm, not sure like what do you mean by n minus 2, I'm understanding that we are doing one year four months? Is you know a service re four quarters instead of three for a basis? So what is the demand from the community from the consumers?

F

Are they okay with this one 1/4 of extension here because it used to be like we are like dodging a problem. I think people want to have more from a yes.

A

Double is that what you meant, where this is sort of like it? It's a pragmatic, in-between like it's, maybe not everything that one might infer from the traditional LTS phrase, but it's an improvement that at least enables some some annual cadence for end users.

C

Yes, so the data sales people want LTS clusters of users who have commented in freeform comments that they wanted LTS to data sales, that users are sticking to older versions.

C

But if you look at even logo, marriage proposals clearly signals out the discipline and the state of the project is different. So if you really want to realistically make an evolution to our current cadence, this is a good next step and that is achievable and tomorrow, if you want to go for a longer cadence, we can always learn from current experience of one year and see how people are using it.

C

We have already heard from the audience to increase different releases.

C

Cadence's I mean we ten months right now and whenever we release a patch after that, we still hear someone say: okay, can you please release one more I think 1.11 had a little longer cycle than what our twelve also I think it had about thirteen fourteen months, so I think twelve or thirteen months, but so being more pragmatic, I think people could start on any release like I could be on 1.12 and I could be starting in the middle of the year, say 1.16 and now I want that particular release to be supported for a.

E

Year because.

C

If I go for the.

E

Earlier I'd.

C

Say.

E

January.

C

I'm still having six months of support, only left for it and whatever I pick the latest after that would also have the same so maybe increasing the current cadence is a good first step in that direction. So anything.

E

You pick at.

C

Any time of the year you still have a year of release and if you want longer, maybe after that it makes sense, maybe two.

E

Years or.

C

Three years, I I don't have any data or any use case. Your users. Are you right now that understands that? You know that that tells me where the two years or three years is better.

C

We never asked a question to in the survey saying: do you want two years ago you won three years, but do we? We do have the data that says people are using clusters older than one year versions older than one year as old as 1.8 or 6 and 1.5, but significant amount of community is on one hotel, not 11, and the charts which I have shared and I think mayor Jones, meeting details of which clusters are being used by which groups of users is quite significant to them. It does it answer your question.

C

Yes,.

F

Sorry.

C

About the background noise.

F

So originally before the survey a really war, it was the direct question and have a table whatever bullet points, for people to wait on the their demands, because, right now we we still officer sir, we are still bit unclear. Maybe we have people are still saying you know 8 releases behind, like maybe that's part of the majority. Who knows we don't have the data? Maybe a lot of people are currently still on the 1.10. That's five releases behind so right now it feels to me, like we have a separate question to ask like.

F

If we have this kiplyn proposal for one year, we have to again fire a question to the public. Let's say: hey: are you? Okay? With this? It's just simpler than the extension of one month. Sorry, one release to have a basically yearly cadence is better, but again it's something that we can already do today and I wouldn't call that the OTS. Maybe we already have the OTS with the three releases we do so it's kind of this requires more discussion about I. Had a separate question here like by the N minus 2.

F

Are you proposing to skip a version when you do upgrades.

C

Yes,.

F

So this is might be quite tricky. I want to get the feedback from API machinery on this, but it actually can be quite disruptive, believe it or not. I can give you an example. So if an API goes out of scope in a particular release and the next release, we basically handle this API removal properly. But if we skip this in-between release, we end up in a new release. That is unaware that the previous release removed this API, so I, even Qube idea, I'm, not really sure we can handle this already.

F

I mean technically the cube, ATM upgrades logic and mechanics can allow you to do the upgrades. If everything is you know, if everything on paper is super clean, you can perform the operate. It's going to work. Maybe, but the API is it's a very tricky subject because they began API. Deprecation policy has a strict sequence of events where an API is removed. It guys deprecated and I'm not sure this is possible. Uncovering history I think.

A

We've kind of rationalized that is definitely not safely possible today. There's lots of examples that have been shared but I. Think one of the things within that is that this isn't. This wouldn't just imply an elongation of the deprecation policy. We'd have to move to sort of a tick-tock scheme where API is our deprecated API czar only removed in a specific release and that that release must be visited during an upgrade process. So maybe even odd releases or something like that were evens, don't remove or an odds do or something like that.

A

But then, when the N minus two wouldn't just be arbitrary in it would be specific ends. I think.

C

Is easier to implement it? If you say the deprecation policy is.

E

You.

C

Don't have to get anything for two releases. If you start with a notice, then it goes. What do loses most are de duplications. I have seen how can't be on two releases so being able to support that kind of a disappears. Okay, if you are say on 1.16 and the application was on 1.15 the moving from a touch 16 to 1.18, you should probably know that you are using a duplicated api and you are sitting there, so you should be prepared for that.

C

What.

E

Is the.

C

Policy you're always gonna face this issue unless you only upgrade incremental, because that is very expensive right now to upgrade incremental as and more services. More and more, you know so control plane, abstractions, we add works especially with CRTs when their controls.

E

Been.

C

Is be getting bigger, so it gets difficult. I'm.

A

Not convinced we can rely on a you should know that these things are deprecated.

A

I I suspect that there's gonna be a lot of things that fall through the cracks and I think cluster lifecycle has been one of the places on the forefront of discovery of those sorts of things or or yield fielding the brunt of disgruntled users who've run into those sort of things so I think an explicit validation mechanism is gonna, be required here and I kind of get the sense that cluster life cycle is getting in that direction, though, and in terms of being able to do validation of configs.

A

But where do you see that going lunar I can.

F

Give you an example where something that's happened very recently: I'm, not sure if everybody saw the removal from the API server of a certain API types, those were extensions / you want pizza, 1 and basically that was for the poor, sorry for demon sets and for maybe stateful sets, and after that we have now v1 sorry, abscess v1 and all the entrant tests upstream broke. Because of this change. In terms of you know, CNI plugins everything broke, and this is a basically a landing stone in this particularly release.

F

So if you upgrade 1/16, you have to prepare your deployments. You have to modify all your manifests on discs to comply with the new release of communities and theoretically, if we skip 1/16, we are going to be in trouble. So then we have to define the list of releases you have to land on when you do the upgrades, so it's really tricky but may okay, maybe we can do it through the amount of question that you're asking Tim like what is the state of you know, component config cause lifecycle tools, it's really unclear.

F

We are right now demanding tooling, from API machinery to be able to perform conversions outside of the tools themselves. For instance, cube proxy does not expose a way for you to basically transition from an old version of your proxy convict to a new version of the proxy config. You have to do it manually, so you PDM might be able to do it for you, but it's still, it feels like a hack. The ecosystem is lacking tools for validation and conversion of API types, and this is a serious API machinery problem.

F

We are discussing it in working group components, standards right now, and this is a serious blocker for it. Yes, you, basically, even if we we are skipping operation to the picture, these tools have to support the version skip as well. We have to be able to convert between the old type that may be going away, maybe not every component out there. It has to fall the same deprecation policy. Exactly all the releases have to match these components that have to be duplicated.

F

If one of the components deviates, you end up in up with a broken cursor, because a conversion tool is not going to work. So it's really super tricky I'm going to ask like what is the exact motivation to be able to skip releases? That's my biggest question. I.

C

Think, actually, the current policy of doing and I'm not great and is ridiculous, I mean if you have to do step by step upgrades. You are gonna, the conversion will always gonna fail. So if I have a conflict that is deprecated after two releases and doesn't have a replacement, I am gonna anyways fail.

C

I will never be able to do the skipper, skipper direct upgrades, so the reason for doing ability to do skip upgrades is to be able to reduce the time cost to do an upgrade and when you have services running for say six months, seven months and suddenly, the only reason you have to upgrade is only reason all the services are running on the cluster or going down is because you are doing an upgrade and you're doing a four versions.

C

You know upgrade just because you want to catch up that expensive OC. So you don't do you know if you don't.

F

Sorry yeah.

C

Go ahead, lilloman yeah.

F

I understand so, basically, it's a pretty volatile requirement. Upgrades are expensive, people have to be booked. Time has to be reserved. The question may be down. We just have to evaluate if it's even possible in communities today in, even if we like, we have to have a good picture, whether we have all the tools to be able to perform. This I really want feedback from Jordan on this I'm.

C

Iii agree with you, and that is why this was a prerequisite. It's not just prerequisite for the proposal, but it's come ting I mean I. Think you fee. If we say every one and minus two upgrades by say in a year, we can look at what is required to do and predictably make it.

C

Plans usually happen in the releases I mean, so you could probably have it in one year or 1.5 years. But if you, if in in the process of being able to achieve and two upgrades or being able to skip upgrades I, think we actually have much better design for all our tools versus I, don't know I'm not saying 1.17 should be one yet supported. Release I'm saying this cap is trying to propose a timeline and setting a goal.

C

So if one of the goals that you see I'm talking about a timeline and and the goals, if you don't set a goal and if you don't set a timeline around saying okay, we probably should have this all around this time period. We'll never have I mean component configures of one one of your old concept and we still don't have it implemented in all the co lights and most many other CLI still don't have, and even not even close to going. There.

F

Yes, forces the corporate config.

C

You supposed to take time, oh I, really like the changes that we are making to 6:00 p.m. and sig release right now, and that is this. That is where we can drive. You know these goals, saying it: okay from the user experience. This is what the customer wants and then go back and try to implement this in the project, because the implementation is an engineering challenge which is always solvable.

C

Users are really facing tough problems if they are finding issues not not being able to upgrade just because they're actually staying with older versions of kubernetes, just because n minus-1 upgrades are difficult for them, then, when we probably are failing them, I feel.

A

Like the world from the very beginning, there's been a question of what we mean by support and there have been at least two major things that have come out of those discussions and formalizing. This word support. One of them is an upgrade path and the other is so that's moving forward and figuring out how to mechanically make that happen. The other thing is when you're not moving forward out of specific space. For how long do you receive critical bug, fixes and security fixes?

A

There I feel, like this discussion, conflates those two things in a way: that's kind of confusing one. There's the easy thing like hey you're sitting here, we'll let you sit there longer 1/4 longer: okay, that's cool, that's understandable! The N, minus 2 or n plus 2 upgrade path feels like a different thing and I wonder if we're in attempting to address a user concern, upgrades are slow, upgrades are difficult.

A

Upgrades are front if we're going about it in the wrong way, trying to say: let's, let's make that technically possible and getting down into API machinery of it versus it, going up the stack and saying how do we manage cluster migrations, immutable infrastructure and shifting workloads over to a new version of infrastructure, where that could be a lot bigger jump but you're not trying to maintain api compatibility within cluster components. You've still got your workload. Migration to do and validate, but I I feel like that could be a much technically simpler thing to implement there.

A

There is always the question of whoa I: don't have resources for two clusters, but how can you is there a way than to address that problem in a way that it's, a piecemeal migration versus requiring you to have? If you have a thousand node cluster to have another thousand node cluster next to it? So.

C

I think these are orthogonal. One one thought came to our mind was if I was increasing today, just the cadence of kubernetes for three months now you have a nine month support and then it is increased by 12 months. So if I was starting with 1.16 and say, 1.16 is increased by three months. This is the only release. I would be beneficial because, after that, once 1.16 release is over.

C

I still have to catch up every three months, because I'm in pretty old release and the reason I'm not upgrading is I'm cannot upgrade so frequently so I waited for a year now after a year, I have to start again upgrading every three months, because now I'm catching up the N minus two upgrades helps me catch up faster, and that gives me much better motivation to do that.

C

So the there is no benefit long-term benefit or more is a bigger benefit, actually in just extending the release cadence by three months, because the releases are still happening every three months and I after one ear, amps I might just black behind.

C

So this is trying to get those huge amount of consumers in 1.10, 1.11 1.12 pipeline right now that we saw in this survey most of the consumers where, in those versions who were in the user community.

C

Is it kind of fun, so the question I know: there's still you know, subjective yeah.

A

I hear the assertion there and I'm trying to kind of raise the question because, like I, don't necessarily see the data to back that it's easier or faster to do an upgrade across ends within a cluster versus having immutable cluster components and transitioning workloads across clusters, or that there's an intrinsic motivation to do upgrades more or less often and either of those potential schemes.

C

I yeah I see that those decisions are not made by us. Those decisions are made by the ops folks, I mean we could give a particular recommendation. That's saying we don't support in place, but that's not how the community thinks and they choose. If you look at the comments people actually want in in one place, they wanted in place of grates another place they wanted ruling updates. So the misunderstood, rolling upgrades are well understood.

C

The big vision of in-place upgrades I, don't know, but yeah I think it's.

A

Still an emerging pattern, a lot of people aren't super familiar with it, and certainly I have my thing. I upgrade my thing is kind of deed, the one that is that the way that people typically do things are gonna default to it would require different thinking to go somewhere else, but I also I feel like that's kind of the the basis of all of containers and cloud native is just a slightly different way of thinking about things.

A

So I I don't know that it's it's something that you can immediately just dismiss as people don't want this way of working. It may just be that they're unfamiliar with it, and if, if we built tooling that helped that they would potentially prefer it.

C

um When you say build tooling that helped you mean and and upgrades or and to upgrade strolling yeah, not.

A

Upgrading in place tooling, that allowed it, it made workload migration across clusters, more seamless, I, think.

C

You didn't, then hand upgrades make sense. You don't have to do incremental upgrades. Even your workloads would still have CR DS and compatibility with the API server etcetera with the control plane becoming thicker right now because of CR DS. You could be you don't know where the control plane is ending. I could have a kubernetes cluster, but with three other C know.

A

You've cut out.

A

So I think the the idea that just already between clusters, which would have different versions, would mean bringing your CR DS along with you, and those could have incompatibilities like that. That is true, but the the same there are gonna, be breaking changes.

A

At least today, given the evolution of things, we're not everywhere, v1 stable with long support on API is there's going to be breaking changes that come through the pike, so users are going to have to validate each of those things and and move in some safe way, because at some point they are gonna hit that point where they need to be made aware like and I think this was my my my worry about your earlier statement about.

A

You should be aware: we need to help them become aware, and it's not just documenting deprecations, but giving people away to more safely trial. A migration I think.

E

Reasons.

A

Jordan was fairly passionate about needing to support um downgrade because you start to move a component forward and inevitably hit an issue and want to come back so that there's there is gonna, be some user involvement here and I feel like we're stuck on keeping the user involved in the way that they are today versus thinking about other options. Possibly.

C

I agree with that point, but I also think that no matter if it is n minus one upgrades are said, minus two upgrades it's the cost that reduces you have to do less upgrades when you do n minus two upgrades when you have for raises, but if you take that through the chain is still required, I have not read and not refusing that I'm. Just saying the proposal doesn't talk about that implementation. Yeah.

A

But if you're gonna argue that way, argument leads to saying n minus one upgrades are the best, because you have the least amount of work by by regularly keeping yourself close to two main lines tip, and that is true. You.

C

Have to do it every three months yep. Sometimes your application is so big that you actually are only upgrading all through the year. Because he's you finish an upgrade, you start, then you have to start planning for the next upgrade, because it's already three months in the front, so that also is actually expensive.

C

That adds more costs unless you are a thin app or you know, a single process system, this is I mean you could be having a thousand or trustor and just upgrading those thousand nodes will take you more than more than three months for sure I mean I. Think even a fifteen or cluster would be very difficult to upgrade the patterns I, see in different cloud providers, etc. Right now also kind of hint towards wanting. You know at least supporting two versions older.

C

If I look at existing cloud providers, how they provide supports, how much how down they want to go and say masters versus API server versus worker node supports anyways, yeah, I think it's.

C

We all well understand it at this point right now. It's that's kind of the fruitful discussion we had and I would I would have an office I'm total, probably talking more I would recommend everybody to add themselves as authors and make those modifications and comments of this proposal, because almost every one of us have attended every meeting in working off ideas and I think this proposal should be everybody's.

E

Can I add a idea we don't necessarily have to have a proposal that works for every situation. We could say this to propose that we believe will help this kind of user. Maybe that would help.

E

Resolve some of the disagreements as an example a pivotal: we know that we have customers who run on-premise are typically resource constrained, so for them the side-by-side green/blue migration option. Whilst they would like to do that, they don't have the ability, no the harbor to do it, but for customers on the cloud, it's a much more viable option and generally preferable because it's lower risk. Perhaps we could start this proposal saying this is targeted at you know: people who have elastic infrastructure or don't ability, construction, I,.

C

Think I, like that idea and I, think it's more towards saying this is evolution rather than you know the final final release, cadence of kubernetes, maybe in just an evolution, next version of what we're doing right now, I.

F

Think the biggest supposition that the N minus 2 proposal is going to see is from the folks who agree that the Koopalings and the best server cannot be two versions apart. I can give an example of how badly things can break today. If you do an upgrade and between basically some more. Let me go back so imagine you have a 1:13 coaster and you want to use the mechanic that Tim is talking about introducing a new question. Where is the new version of 115 115 couplet? If it starts talking to a PS, 7 is 113.

F

Things can go horribly wrong today, and you have to convince the same folks that basically did this Marshalls view that it has to be supported. Scenario I wanted to make another comment here. So when you're doing immutable upgrades, when you do this new notes, the cursor you don't necessarily have to have double the the nodes in the cluster. It really depends from very buildin, see part of your question so how many external workers you have? What is the size of the workloads? Are they currently running? How many replicas you have things like that?

F

You can take me to introduce one third of the size and still get away with upgrade, but you have a risk scenario where, during upgrades, you can potentially end up in this basement situation. Where something fails, we don't necessarily have to say hey. We need double the size and.

A

When I I'm actually maybe been miss speaking or not speaking, full.

E

Clearly,.

A

On the the immutability I'm actually meeting Abell clusters, so if you have a cluster at 112, you don't introduce queue by adding new components within the control plane at new versions, you set up a separate control, plane and worker nodes as a separate cluster, and on top of those, you shift your work over to the other one. So it's it's about workload versus cluster compatibility as opposed to cluster internal node compatibility. So.

F

That's technically question and after duplication, you move the workloads, but that's like that falls back to the argument of expensive that the vow is bringing that's really expensive to for most users at least I've seen I can.

A

Understand David's argument for on-prem, and certainly if you're in the cloud you have more elasticity in that regard, but if you're I'm sort of thinking, if your control plane is bigger than your set of worker nodes, you, you aren't exactly doing cloud native right, probably re lasticity right in the first place. So if the worker nodes are the primary cost, setting up a duplicate control, plane initially is gonna be a small incremental cost is certainly incremental, but then bringing in some worker nodes a minimal number in order to trial.

A

Some workloads could be possible again as an incremental thing that you don't have to do n times to increment, but it could be if you have a thousand node cluster, bring up a new control plane with five nodes and start trialing, some of your workloads on it and shifting and spinning down nodes on the one cluster, bringing them those resources back up on the other cluster that there there could be a mechanism built that enabled that type of underlying resource and workload trialing migration over, but that that would be something that completely needs built.

A

I I have the impression that there are cluster operators out there, who've built things like that for themselves, but we don't have like a canonical one of those in in the open source that works with all the cloud providers and there's a lot of complexity there. But I wonder if things like where cluster API is going in the mechanisms that I presume to be built on top of that might start to better enable the type of thing I.

C

Instead of instead of commenting on what you say, it I would just point out that this is just another way, because Lumiere had a way Daniel say the way, and you say the way we cannot define how the ops is gonna decide, because these three are still very modern versions of our plates might happen and I.

E

Like Denny.

C

David's idea, David Lankes idea, said that hey, we should start with saying: okay, we're just evolving this process to cover another significant bigger user base. That's it! That's that's why I'm.

A

Looking at it, I know that that's easy to say and I hear Luba mirror saying that when you get into the details of how you do that with it and skews, there's a lot of work to actually create that mechanism.

C

The project needs to evolve into trying to become more deterministic and user facing and say: okay, the engineering will have to work on it because it's an engineering problem and- and we all know that we can solve it- it's not limited by physics right. So it is something that the I mean from 6 p.m. and city release perspective. If a user perspective is not being if significant user perspective is not being addressed with the project, then there is I mean I, all the component, configs, etc.

C

All have it started only because we see this, we recognize this and we need to solve this, and that's why I'm saying maybe we should start saying it. Okay, we say, and to upgrades or the policies that we have defined in a proposal and say, let's work towards it for a year and then make that release as t44 before quarter releases be.

A

Explicit I think I part of me definitely agrees, but I I feel like it would be easier if that was a separate cap of its own, like supported.

E

Grades.

A

And support for releases those feels separate to me and that they, the the for release, one could still be prerequisite on the other, but to just split them out. It seems like the work and intent would be more clear. The.

C

Four releases does not benefit anyone. That's that's where my argument is ill. After after I wait for a year, I have to upgrade every three months, because I still have the same problem. So that's why and my.

A

Place like that, this is a incremental change for those who don't upgrade in place the the four year or for the one year. / four release cycle support would be an incremental benefit to those people only.

C

Once well,.

A

For if I'm hearing a lot of enterprises or IT shops who run lots of clusters, so.

C

It would be.

A

Once per cluster, which could still be significant, no.

C

I'm saying you can only choose it first time, you're using maybe you're on greenfield at that time you.

A

Throw away that cluster after year, you've migrated because we know that people already operate this way.

D

I'm.

C

Trying to I'm trying to separate the design strategy, it's because that cannot be predicted. I mean I, don't know what Bank of America wants to do: I'm, just taking out that name right now, because it's a bank.

A

We don't know what any particular one does, but we had the data. The people do do this, so that would be beneficial to that set of people is.

C

It significant are we solving their problem or are we solving a problem that represents all of the data or most of the data? That's that's where I'm trying to say. Maybe we should look at the data back and say these people who are running this older clusters. What is their reference of our strategy because.

A

I think that's a key part of the cap that make sure that it's data back to say for the elongation to four or four releases: slash annual here's, the data of which portion of users benefit from that and.

C

For.

A

The N minus two upgrades here's the data on which portion of those benefits they think that that's really critical, okay.

C

Yeah, probably yeah. If anybody else also wants to chart those data's, please feel free to do that and also take a look at this. I have taken up for action items on this proposals already.

A

And I see folks have been adding comments on the talk. As we talk also. Oh nice.

C

And also, if you go back in the history of our meetings of minutes, you will see the link of where the details.

C

So you can download the data and construct the arguments.

F

So I wanted to ask like I, haven't done some research on this, but like for the popular projects out there like Linux Ubuntu?

F

What is the average LTS length.

C

T I have not done a research and I am sure. Tim has a better answer for Linux for Ubuntu it's about two years. They release an LPS version and they frequently release dot, o 400 ATO seven release for a canonical. There are the projects that was similar patterns and some.

E

Some.

C

Have ad hoc LTS, based on you, know how many who is asking for a longer term release like so.

D

Yeah those are different. There is no average but a bun, even though they make a new release every two years. They support a given release longer than that right. Oh.

C

Yeah yeah.

D

Yeah.

C

They supported for five years and they release their release and support. Cadence's are different. It's not rectangle, it's not a square. It's a rectangle! Yes,.

F

So in these bone to release is where they support something for five years. Do you know if they push features I'm just curious, though today's sedation.

C

Yeah, their support policies are different for different periods, bug-fix versus features, so the features only go into the shorter releases and they also get backed out. If the next LTS is not, the feature is not considered stable or enough popular and they are get completely backed out. I think we had if canonical folks were here. They would have been much better to explain this, but I think if I remember unity and genome had a lot of you know it will be in next release or not. We never knew it till. Actually, the LTS came out.

C

So that is because they wanted to see if the previous release was stable enough and was all the use cases that are currently using LTS versions, would they be disrupted with the change, so those kind of decisions are made and I think features are never added. After LTS it's made, only bug fixes are done and security patches and and those get thinner and thinner over the next five or four years I mean I, am a regular 80s user who cannot open to from many years. So that's why.

F

Both of us definitely shifted towards the concept of LTS is the only stable version of the product and uh yeah I just wanted to bring this back because we don't want this for commodities. So it's really. It's.

C

In this proposal there is no idea every releases one year so.

E

Yeah.

C

I think that's one after we not yet we not yet sure what else should be in LTS, but we are. We are sure that at least a her should be there at least for subscription licenses and basic SAS services. Also at least you should have something supported for a year if you're taking it up. Yes,.

F

So this is going to make the people who want to get all the bleed innate, bleeding edge features so I'm happy, because we are not going to but ports teachers and they have to wait for one year to get. You know the latest version of the whatever a restful feature we have in the API server.

F

Yes, so that that's going to be a problem. I think this also problem in the proposal from Tim, if I'm not so wrong.

C

Yeah I think those those proposals were more for projects that to not move I mean I, think, ultimately, something like what Tim and Tim proposal would make bigger sense a after 10 years when kubernetes is very stable and we don't have anything new most of the stuff is CR DS, maybe at that time I'm just giving 10 years as a ballpark. Maybe it could happen in two years, because kubernetes is so fast to.

A

Be clear, you're both talking about Tim Sinclair's document on the the Condor inspired? Yes,.

A

Sic Tim has gotten pretty lit big these days. Yeah.

C

They should be a sick name actually or maybe there is already one- and we don't know, but I secret cabal of teams. If you're a team, you get you get into the project, the community with your project, but yeah I think you know I'm only thinking about sick team right now, it's Tim Sinclair's proposal is more also makes it faster for shorter release. It this monthly releases and also gives an LPS baseline for people who are building CR, DS and stuff on it. That's a different way of creating flavors right now.

C

If you look at Linux and flavor, it's up Linux, you have one base Linux, and then you have one big over to see our DS. You know you had a new CR. Do you we added something new control plane. You are actually a completely different, so you.

A

Know cluster, so people who have shared interface starts to feel like user space versus kernel, and the big difference is if, if you look at so.

D

If.

C

C IDs, if C IDs make everything even API server objects. Core objects also come see our dish tomorrow. Maybe everything it's got no space so.

A

There's a wiki page for the Linux kernel and it has a section on maintenance and long-term support, and so there had been the question earlier about how long is the kernel support?

A

So the 300 kernels LTS dream started eight years ago and it's still in support, but I think that the bigger thing to realize there is that started 20 years after the project, so we're it's easier to do these things once you have decade's worth of stabilization, that's happened and interphase is starting to become apparent more naturally we're we're really forcing something here before it's mature enough to to be clear what the right path is.

F

Yes, that's the the premature demands where I am just still thinking whether we shrink we should invest efforts in instead of going on the road of. Maybe at this point it's easier to support the seamless upgrades instead of having these long release cycles, where we don't even know if the increments or great picture is going to be clean and also you know the jump between the skip universum. These are essentially, we are battling something we're battling them. The lack of maturity in the project like.

A

Like the whole says, if you, if you don't draw a line in the sand where sand somewhere and aspire to accomplish it, it's all just talk at that point. So making a proposal and trying to implement it, as is one of the ways you get, that maturity to or it versus just waiting for it to spontaneously happen over decades and in the meantime, there are customers who are running this stuff in production. So it's a complicated balance. I.

C

Would say if you give yourself a timeline say of a year and start going towards the goal, you will know whether it's an achievable and a practical goal or not, and if you give yourself one year and you at least have the in this option. This proposal, you at least have an option to continue the status cure of three releases. If does not make you have one more release and does not make sense to have an N minus two of grapes, so.

A

Are you saying that you would not want to accept the change to cig releases release cadence until after and minus two upgrades were made viable, improved.

D

For.

C

Me, the value for n minus two upgrades I mean for me in the value of increasing it by three months, is non-existent if I don't have an N. Minus two upgrades are faster upgrades, because number of upgrades I have to do to catch up on. My technical matter is huge, so.

A

What do you think about kind of inverting this and saying that this is the N minus two upgrades cap and future work would be then once completed, to extend the support lifecycle from three to four releases. To focus on that aspect, I would.

C

Say let's really see.

A

The primary value III.

C

I see in the end in it, and this you know to nine months, become, becomes the similar predict visit that says: okay, everyone, I'm doing n minus two upgrades. You know I'd rather have to have it as even number so I can keep jumping, and nine months is less than one year.

C

The other problems that I'm already solving I can't even have a subscription license if I am a user who is distributing kind in an IOT device after nine months, I have to go down the C and get it back because, as I sold a one-year license in the last three months, I'm supposed to actually go and upgrade so that those questions come in. I think this to go work well this two.

C

This two proposal points work well with each other and in this these two only work the best with each other. If you take one out, the value of each of them goes down is what I'm saying okay.

A

Yeah we.

D

Are over time.

A

So we'll wrap up I will make sure the video gets posted.

D

By.
youtube image
From YouTube: Kubernetes WG LTS 20190723

Description

The Long Term Support Working Group (WG LTS) is organized with the goal of provide a cross SIG location for focused collection of stakeholder feedback regarding the support stance of Kubernetes project in order to inform proposals for support improvements.

"WG LTS" is simply shorter than "WG To LTS Or Not To LTS" or "WG What Are We Releasing And Why And How Is It Best Integrated, Validate, And Supported", but should NOT be read in that shortness to imply establishing a traditional LTS scheme (multi-year support; upgrade from LTS N to N+1, skipping intermediate versions) is the foregone conclusion of the WG.

Charter: https://git.k8s.io/community/wg-lts/charter.md
Meeting Minutes/Agenda: https://bit.ly/2HI8ppj
Maling List: https://groups.google.com/forum/#!forum/kubernetes-wg-lts