Istio Technical Oversight Committee, 23 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Technical Oversight Committee 2021/08/23

Description

Istio's Technical Oversight Committee for August 23rd, 2021.
Topics:
- Extensibility Roadmap for 1.12
- Security Roadmap for 1.12
- Istio Upgrade survey results and feedback discussion
- Extending Istio's support window - conclusion (n-1 + 6w)

A

Was an experimental api unfortunately did not land in 111.

A

So now we will land it in 112, and that is a p0.

A

Telemetry api to alpha so finish, all the metrics access logging and that and then there is a persistent request for a sort of better ongoing native stats support. So we need to make some headway there. So the first one is p0. The second one is p1 um rate limit api design.

A

So uh in the last quarter we made. We basically did some work there, but um we discovered that it does need much wider consensus and um there are many more dependencies potentially so we have to put that back on the agenda.

A

Middle proxy is now coming up, often, and we've had middle proxy telemetry on sort of the menu for a while, but I think now uh there are other reasons to do it, and what I expect here is to be able to produce talk. That says here is the design, and this is the equivalence or lack thereof, between a sidecar and middle proxy telemetry.

A

One of the other things which we discussed in the in the previous quarter.

A

Actually it came up a couple of times, but rama brought it up for his specific use case is that to add open telemetry of provider, and once we have open telemetry provider, it does open up, like many other other integrations.

A

So a lot of this work is going to be um to actually document and then blog about how to do it and then metadata discovery service is is again so mixer was a metadata discovery service which we got rid of long time ago, and since then we have had again another persisting request, and even that is becoming, I think, important for other reasons now so in the previous 111, it was a p2 this time it it is slightly higher and it has it has one primary owner and a secondary owner.

A

So that so that's that's it. We have yeah.

A

B

Yeah, I guess for me I don't understand the middle proxy telemetry design. I don't know if other members understood that.

A

So so gateway like uh telemetry that that's that's based on purely gateway right, so our the the gateway telemetry works great great at ingress because it it mostly talks about kind of where the the traffic is headed and doesn't talk a whole lot about where the traffic is coming from, um because once you're in ingress, there are many more places that the traffic could come from when you have a middle proxy.

A

Actually, both sides are quite nicely bounded and you can produce a full telemetry just like a side cardboard and that's what that's. What middle proxy uh telemetry would give you so almost full correct.

B

So the user benefit is to help us to have visibility into the source of whichever traffic accessing the gateway.

A

Right, correct and, and that's where it intersects with the metadata discovery service as well, because uh knowing information about the source of the traffic is also needed.

B

Okay, thank you.

A

And doug is surprised to see this on the agenda.

A

Oh doug, do you want to add something here? Okay, oh all right.

A

Any other questions.

C

Yeah, what's the.

A

C

Benefit of the meditative discovery service.

A

um Benefit of the material discovery service is that you can take an ip address and or any other identity and map it back to its attributes.

A

And so, for example, if you have a a middle proxy, where some of the clients of the middle proxy are not in the mesh, then being able to resolve um who's, the source of that traffic back to its metadata is what material discovery service gives you.

C

D

I I would say it's it's coupled with uh with what we discussed last week in networking, where you know the micro proxy can completely go away. If the network infrastructure provides you the same thing, and then you need this metadata service to actually resolve ip secure id with uh with metadata.

A

And, and and again like without getting into too many details. But there is a. There is a very good chance that we will be able to just use studies, infrastructure and another xds.

A

Resource to to actually provide this, but that will all be part of the design.

A

Yes, dns as well austin.

E

Was there any any performance work on the agenda? Mender.

A

No performance work on the agenda in in 112, not not in the.

D

Middle proxies performance, work.

A

Well, yeah so like so one of the things that could have been on on the agenda is the is a faster version of the telemetry filters, but but it did not make it into this roadmap unless you're suggesting we should put it there.

E

And it's useful to track it for visibility. You could obviously record your sp2.

A

A

I will record this picture.

D

So uh another one thing that would be great to also track us b2 or something uh we are working on proxies grpc and some other things I mean the microprocessor that was discussed last week would be good to have some some uh thought about how we collect telemetry. In those cases where android is not in the pot or make the full, instead of almost full with middle proxies, because we need something.

A

D

A

uh So so question I I will. I will put you as the as one of the main owners here and then we can add, like we can take it from there. Yep.

D

Sure, okay and and if microprocessors, that was discussed because they are pretty similar.

E

uh Okay, you want me to stop for something render.

E

Click that as a yes.

E

Okay, uh security or someone.

F

Yeah, I can't present okay.

G

F

uh Louis are going to bring up the doc.

E

Yeah, I can pack him right here: okay,.

F

G

I can get started um the first one is um oh yeah between me and shankar, and I um I think the first one also includes um yeah some alignment um like across what we were already doing um and inside google and their external oss part. So we want to gather um design complete for their external certificate premium api and their sds configuration api. Currently they are using either environment variables or mesh config. We want to move them out and use crds to define those apis.

G

F

Yeah there's already an existing design, but we want to iterate on yet that's it yeah. So the next one is the improvement of security policy uh yeah. So marco and yamin are working on improving the easter qatar troubleshooting for mtis and oscillation.

F

Yes, they already shared design earlier and I think the initial implementation uh has been done, but yeah they need to complete the implementation, and the second part is yami is working on supporting extracting george clint to http header. uh He already shared the design to uh to the security working group and also networking working group.

F

I think there are several use cases. One is to use the georgetown-based routing and the other use cases. Customer wants to use the george claim as a http header in their application, so his design is going to address both use cases.

F

Yeah, and next is the future graduation. uh We have uh yeah a bunch of security features we want to graduate um so for the uh external oscillation feature uh yeah, we want to promote it from experimental to alpha, auto mqs. Promoting auto mqs is actually mostly done. There is a a few left left over item.

F

I think mostly on support side, a 16 phase, pencil completed um yeah and for promoting security policy api to stable, I think for the p0 is to scoping off the work needed so yeah, so yummy plans to properly write a dock to put down what are the work needed to graduate the api.

F

Yeah and the last race yeah.

G

So this one uh promote external ca integration feature from the experiment to the r to alpha it's um owned by shankar. Currently we have this, customers are using it already. We want to promote it at least to our far shooting for that goal in the next release.

G

um Yeah the last one also belongs to me improvements on the documentation. Currently we have their security concept page, which is pretty long. We have. We are halfway there to get this improved, to make it much shorter by moving some of the contents into their tasks or best practice, documentation and also didn't mention it here. We also add we'll add more tasks for the concept page as well.

G

Yeah, I think that's it.

F

Yep, that's all we have any questions comments.

H

For the um documentation, improvements will that include the automated tests. Yes, okay, awesome yeah. I will.

G

Add that as well yes, okay, thanks.

F

So all over this is on the console page only or also the task page.

G

Only the concept page, we only miss the automated tests on their concept. Page.

G

I think that's what brian was saying. It's also talking about the same.

H

Yeah, I know the best practices pages too, but I don't know if that belongs to security or product security.

G

Right yep, we can resolve that in our product security working group goals.

H

This looks good to me.

E

Yeah me too, um we should make sure the auto mt last stuff is well aligned with the micro proxy proposal, not not that it blocks the promotion of the existing feature to stable, but what we were going to do next.

F

So uh louis you are talking about the microservice of proposal. That's the on the networking roadmap agenda. Okay,.

E

Okay um seems like we're all done here.

F

Yep: okay, thanks.

E

uh Mitch, you want to talk about upgrade experience.

I

Sounds good, can you guys see my presentation yep great, uh so for just a little bit of context. Two weeks ago we were talking about extending support for either the 1 9 or 110 release, and we sort of heard that we would like to see updated feedback.

I

The user experience working group conducts these surveys every quarter with every release. We survey our users, particularly on their upgrade experience, and I haven't had a readout of this since april, so this will be covering the 110 release.

I

So, as you may recall, last fall. We found that users had a lot of confusion around vulnerability exposure and that there were a lot of concerns around the safety of upgrade process. So we reorganized our 2021 roadmap around improving the upgrade experience.

I

The feedback we showed in april uh with one nine, was our first release that had been reorganized around upgrade experience and we found that there was some improvement. We moved the needle, but there was still quite a long ways to go.

I

Looking at our 110 survey, we got 27 respondents, which is about double uh what we got for the one nine survey, and the reason for that is that now our surveys are open, starting on the release date uh and more or less open indefinitely. They're. Also, now a part of the upgrade process, both helm and istio cuddle will dump a small message to the user, asking them to fill out a survey about their experience. Upgrading.

I

I'm sorry, I need to mute this other tab so that I can focus.

I

There we go all right, uh so the first uh question that we ask our users is to get an idea of the maturity of their installations. um You'll notice that, as a change from one nine, we saw a lot more users who have had only some of their meshes or some not. You know, test message, meshes fewer production installations than we saw in 110 or one nine sorry. This is because we had the survey open from day one. So this is an expected change.

I

Some users will have upgraded only one cluster and then immediately had gone to fill out. The survey- others, as you can see, will have upgraded all of their production meshes before giving us feedback. So we have pretty well-rounded feedback from first impressions to pretty mature installations.

I

um We measure satisfaction versus the progress of installation and, in one nine we had a. We had a light skew to the positive side um with some concerning. Let's see, oh no, no, this is particularly concerning, but the the skew was light and we, of course we didn't have a lot of response. Only 13 respondents in nine looking to 110, we have a much stronger and clearer skew towards a positive upgrade experience for reference.

I

One would be a significantly worse experience than before three would be about the same, and five would be a significantly better upgrade experience than previous versions of istio.

I

You can also see that this this response, this strong bias towards the positive, is pretty evenly distributed across users, uh who have only just begun their process of upgrading or who have completed upgrading all of their meshes to sto110.

I

The next question again in one nine, we ask for areas where we've seen the most improvement versus areas where we need the most improvement. This is what we saw in one nine fairly, even across the areas where we saw positive revision based upgrades had two showing improvement, two saying it needs more improvement. Upgrade stability, biasing slightly positive, skip version, upgrades being the most popular request in one nine in 110, uh revision-based upgrades biases much more strongly positive, which is great news.

I

This is an area that the environments working group has been investing in for quite some time and we're beginning to see positive feedback from our users on revision-based upgrades. We'll look a little bit more at that later. We've our users are happy with upgrade tooling and stability, but still skip version. Upgrades are a very strong ask uh from our users the ability to upgrade from one eight to one ten one, nine to one eleven uh within the support window questions there.

J

Yeah for the skip version upgrade responses are.

D

J

Who tried skip version upgrades and it just went badly and they wanted a better experience or they just want that feature.

I

So we did not get any qualitative feedback from these users on why they selected skip version upgrades, so skip version. Upgrades are supported uh within 110, so you can upgrade from one eight to 110 uh and that was announced shortly after the 110 release. However, um you can't do it within the support window, like one eight went out of support before skip version. Upgrades from 1 8 to 110 were possible.

I

um So my my reading of this feedback is that users expect a fully supported experience in upgrading a studio twice per year.

I

I sam I do have a section at the end where I'm going to ask for qualitative questions. We've gotten contact information from a lot of users who said that they would be interested in being interviewed, uh so we can dig more deeply into that in those interviews as well.

I

E

Cool thanks, yep.

I

When we asked our users, if they preferred in-place upgrades or revision based upgrades, we saw a big change release over release. The sort of pastel bars in the donut graph are the one nine responses.

I

In one nine we saw more than half of our users, uh prefer in-place upgrades and then more users not understand what their upgrade posture was than prefer, revision based, which was uh disheartening, because this is somewhere. We've invested a lot well in this release. The needle has moved substantially.

I

Users prefer revision-based upgrades slightly over in-place upgrades. We do still have a large swath of users who don't know how they upgrade istio, which um I I don't know what conclusion to draw from that. But uh it is great to see revision based upgrades gain some traction here. uh Excellent work from the environments working group.

E

Assume that the people who don't know are either new users or are doing in place and don't understand, revision based.

I

You know I have divided the uh like feelings on that. On the one hand, if you just run, you know an install command without any special flags you get in place. On the other hand, if you've copied your install command from anywhere in the istio documentation, you've very likely gotten a revision based upgrade.

C

Is in place, which I think probably also confuses people yeah.

H

Yeah, so looking at this question here um to me, it specifically asks which one you prefer, which sets me you. We might have users who have tried both and not actually figured out which one they really want to use long-term.

I

That's a great point: the the question is not focused on behavior, but on preference- and I don't know, is a valid preference.

I

We did ask for qualitative feedback on why they had that preference. Interestingly, one of the users who responded- they don't know, said that they prefer. I don't know, because it's more stable, so there might be some confusion about the nature of the question there.

I

The users who prefer in place we have some people, calling it stable and predictable.

I

Not having time to do the canary or revision based upgrade, is a concern then again, when you're working in production moving fast is not necessarily the best for the users who prefer revision based upgrade by the way. Last time we only had one person explain why they were preferred revision based upgrades so having three this time again. Big improvement in this area, uh and we are seeing that perception is changing. There's more safety, there's more stability, we can move progressively.

I

These are exactly the things that we have been saying about revision based upgrade now for over a year, but we're finally getting through to our users and they're agreeing with us, which I think is a really big deal.

I

We asked our users what they consider the riskiest part of an upgrade similar to one nine. This is a mixed bag control, plane data plane some gateways, not a strong signal there. Also, I tried dividing this by the various.

I

What am I trying to say by the various maturities of installation and there's there's just no strong correlation in any direction there.

I

A lot of diversity of perspective, this did not come from uh the survey, but it's relevant to the discussion at hand. I know last two weeks ago, when we were discussing which release we should extend the life cycle of one of the comments was that the 110 release should have much higher adoption than one nine.

I

This chart shows the number of pods running components of istio in each version on gke, using only open source istio and, as you can see, 1 9 is far and away the most popular release in terms of release life cycle where 110 is at now with about three months after the release, uh one nine had about thirty percent or sorry fifty percent more uh pods running at that time.

I

So we're seeing a lot of strong adoption on one nine adoption on 110 is not weak by any means for where it's at you can follow this curve and it's not substantially slower than the 1 8 curve or the 1 9 curve, but it is lagging behind.

I

So that's just sort of another data point for what we're seeing in the wild in terms of istio adoption questions there.

I

I

So uh takeaways are again revision based upgrades. I am just super thrilled to see that, finally, catching on with our users uh still a strong expectation about those direct upgrades or skip version upgrades and looking forward, uh we do already have the 111 survey open. It's been open since day, one for istio 111, with links in all the appropriate places after upgrade, uh but it's been about a year since we've conducted a survey that focused on anything other than upgrade behavior and experience.

I

So if you have suggestions on what you would like to see collected in the fall, uh it's probably time to do a more universal survey for istio user experience.

I

Questions for the qualitative interviews are also welcome and then one last point I wanted to highlight here. These surveys have been using google forms up until now, which is not accessible in china.

I

So we are considering other platforms for hosting these surveys that would be more globally accessible to our user base. We do have a very strong user base in mainland china and we don't want to be instructing them to. You know bypass a national firewall in order to give us feedback.

I

B

Thank you so much mitch. This is very encouraging data and I do agree with you about the wider survey. I was actually just thinking about this recently, especially uh with the roadmap documentation. You know we're trying to produce. I think it aligns really well if we can collect some type of global survey. Not only just for upgrades, especially upgrade has been improved. Quite a bunch now.

I

Yeah yeah: I think that that it's it's about time for that and uh I'll be putting together a document in the ux folder before long sort of soliciting questions or or themes that we could address in that next survey and I'd love your feedback on that lynn.

B

Yeah I'd like to collaborate with you for sure.

C

C

Seems like on the next one right now we're talking a lot about in place versus revisions. um We may want to add something about tags, and if that causes a lot of confusion, then that's a sign that we poorly documented the new tags feature. So I think even that would be a good signal, um but I would in theory hope that we once we start pushing that then in place becomes or sorry revisions becomes both more used and gets better ratings, and that would be a good way to prove that's working as expected.

I

Yep I have, I have reference tags in the 111 upgrade survey, so we should start getting feedback on that. uh We don't have any respondents yet who have upgraded to 111. But that's you know. It's not surprising at this point.

K

E

Mitch, do you want to stop presenting yes,.

I

Thanks for presenting that mitch, my pleasure thanks for tuning in.

B

So meet you just a quick question as we throw it into the next topic, the data you have on gke, that's regardless, which, like there's no subset of user. It will be, I guess, a general data from gke, because your other server is switching for one turn right. So people may not take time to even look at 110, so they wouldn't even spend time to look at that survey. So it's a very targeted set of sampling data from the 27 participant, but the the gke data you presented.

B

That's um that's just a wide range of data right.

I

That's right: that's all users of open source istio on google that are not internal projects uh like our testing or our performance projects, or things like that.

B

I see that's very cool. Thank you.

I

Yeah, um are we hoping to make a decision today on which release to extend support on, or is that something for another week.

I

um That was the context that I brought this topic up in, but I'm not sure if you all feel like you have enough data with this or not.

B

Yes, that was the context. It might be good for us to think through all the data a little bit and the recommend next week. I don't know what do you think.

E

um Do we have saying, do we have forum to talk about it.

B

We have the chrome, the only thing is mirage is sick. Today I know he's been very vocal.

G

B

That night, yeah.

E

E

We should probably make sure niraj is here. We don't have any impending deadlines mitch right there. There is no support window.

I

Closing there's sort of a vague deadline. Technically the one-nine support window was supposed to have closed last week. um I believe the cve that's currently being worked on uh will will also have a one nine patch release for it.

I

I don't know if our intention is then to announce that support for one nine has ended or if maybe we can just leave it vague until a decision has been made, I'm not sure.

E

It certainly seems reasonable to keep it open until this is resolved in the toc. um So I would certainly vote in favor of that right now.

E

uh Does anybody in the toc object.

H

That sounds reasonable to me.

E

So let me keep that as a note.

C

And what exactly are we going to tell the users, because if we decide we're not going to keep 1.9 support when we resolve the issue, then we'll just suddenly drop the support. So I feel like we should we don't want to tell users that it's supported up until some arbitrary date that we make a decision.

I

So what we've communicated so far is that the the support we we announced, that support would last till what is it 90 days past the release of 110, which elapsed on august, I think 17th.

I

um Normally we also do give. I think it's maybe a three week or a four week, heads up to users. Hey support for this release is ending on this date. That announcement did not go out as far as I can tell for the one nine release, so we've already been been more silent than normal about the end of support for this release. That.

C

One did go out, it says august 24th, oh, did it sorry. I missed that no problem.

E

Can you put a link to that in john if you haven't done it yeah.

D

So we already announced that it's no longer supported.

C

We announced that it will not be supported, starting on tomorrow.

D

And we cannot take it back.

C

Oh, we can definitely take it back, that's just what we thought, but I think it would be confusing to say. Actually. 1.9 is supported until some arbitrary date, where we make a decision which could be tomorrow or three weeks from now.

C

Or a year from now.

I

Will say it should be less disruptive to announce more support than we've committed to or to implicitly supply more support than we've committed to than to say it'll be another month and then have it not be another month. If that makes sense,.

K

And I was going to say, depending on how close customers looked, we actually initially said it was august 17th and we bumped it to the 24th because of the security releases tomorrow and we are releasing a later 1.9.

C

I'm fine with bumping it to a specific date. I just don't want to bump to an undefined state, maybe sooner or later, and I think that it's given, I think we already have all the info that we need to make a decision. So if we're going to be doing things like this, it almost seems like we better just come to a vote or something and or whatever we need to do to reach consensus this week or so.

E

I mean niraj is pretty pro extending the release window right. Is that a fair characterization of mirage's historical position.

C

I think so I think everyone is fine with extending it, but the question and correct me wrong there. The question is: how long do we extend it um 12 more weeks, six more weeks, do we do even odd releases and do we start with 1.9 or 1.10, I believe, are the three open decisions.

D

One announcement was sent us.

L

I should probably write those down as yeah.

G

As open questions.

C

That was my take at least if anyone else has opened trade-offs then feel free to add them.

E

Sir gentlemen, was the first thing you said.

C

um Whether we start with 1.9 or 1.10, or something else.

E

um Well, we could start capturing people's positions on these topics.

E

E

And so the just so we narrow down um how long to extend for it was by one release. Was there some other possible measurement of extension, just.

C

Yeah, we discussed a six-week extension so that way we don't have um as many overlapping ones, but you still get like right now. You basically have to skip level upgrade in one day if you want to stay in the window, so this would give you a six week window, um but we don't have the full overlap, which also means that we end up with an extra release during this time when we cut the branch and we have master and next release and then the two three previous supported releases so yeah.

E

So it's really 12 weeks right, which gives us uh you, on average n minus two, but periodically n minus three yeah for the development branch.

I

Well, I guess it depends on what we consider support right. The master branch is not typically supported.

C

uh It's really five branches, there's master the next one and then the three supported releases, so only three of them are supported for users, but five are required for actually landing a change right for developers.

C

Whereas with the six weeks, it's only four at most for developers.

E

So basically we were saying one release or half release.

B

And also don't forget uh the releases john. You are counting, it's not just a issue issue right. I assume it applies to dogs and proxy. So it's like a whole different things. So four and five it's it could be a big difference.

E

Sir john, how do you end up with five releases for having so you end up with n minus three right.

C

Yeah so there's three supporter releases, but then you have to go to the next branch once we're once we cut the branch but haven't released it yet and master so for a one month, window, there's five releases and for everything else, there's four: that a developer needs to backboard to it's main.

E

Upcoming and then minus three.

C

E

But it's only sometimes that we actually have n minus three.

C

uh In the one release this this is so we always have main and n minus three, and for one month we have main and minus three and upcoming.

C

In the other case, we have main and minus two main n minus 3 and main n minus 2 and upcoming, which sounds a lot more complicated, but I don't think users are thinking of it like that, hopefully, um but you'll notice. None of those have five releases at once.

I

That also depends on whether we uh do every release extended or even odd extended. That is true, yeah right.

D

We have skip release up a test for all the five or four combinations.

I

Yeah, those are those are done at uh pre-submit.

D

Skip fashion upgrade for all four, I mean from one uh nine to one ten, one, nine one, eleven one, ten one, eleven all the permutations have tested to appreciate. Yes,.

H

So it's a little late here, but I just thought of this.

H

The concern is really about skip level upgrades right.

E

That's the the user feature driving the demand is so skip level upgrade. Is a symptom of customers only wanting to run a certain number of upgrades a year.

H

Yeah more my question: there was if we make sure that the skip level upgrades work. Do we need to do all the effort and patching and security releases and everything like that.

I

So we, the skip rate upgrades already were sorry skip version upgrades which we're communicating to the users and calling them direct upgrades for rudy's sake um or or lack of clarity, maybe in einstein, but anyway uh that's what we called them.

I

They already are supported and they are thoroughly tested um both across in place and revision based in helm and in using uh istio control. So those are functional, however, in order to make use of them. Currently, our users must allow their existing install to lapse in terms of support, yeah, okay, yeah, there's somewhere in the neighborhood of six to 12 weeks to perform an upgrade depending on how aggressive they are and how large their installs are, and the idea is to provide them with support during that upgrade period.

I

A

Question is: was this so this data that we collected the feedback from users about lts and generally things like that? Did that already factor in our support for skip level upgrades, or was this feedback obtained prior to us really supporting skip.

I

Level upgrades we have both the one nine survey was conducted before skip level upgrades were provided for users, the 110 survey most, I think all of the respondents would have come in after we announced that support, whether they particularly saw that blog post or not is a. I can't answer that question.

D

Okay, so uh on this skip level upgrade I mean we do have some tests, but uh you know the upgrade process. Even for n to n plus one has always been pretty complicated, pretty risky with real applications and all kind of things that users need to. Do. I'm not sure it's safe to claim that we support arbitrary. You know n minus x versions upgrade with with what we have right now I mean it's super superficial. In my opinion,.

I

I mean we've already announced that cost and we announced that in may.

D

I know, but you know it's I don't know it's it's doubling down on something that was pretty shaky in the first place seems not very useful for users because there are all kind of corner cases. As you know, I mean it's. Okay, whatever it's easier, we support everything.

E

Okay, I mean, I think we have enough information to capture toc members opinions on each of the three things.

E

Right now, the primary one in the the 12 weeks versus six weeks. So how would we explain to users the difference between the 12 week, one and the six week one? What would we now say about how long a release is supported for?

E

Is it just adjusting the existing thing by adding six weeks to the number, so we say it's now supported by.

E

You we said 90 days right now, right so we'd say 135 days.

I

We could do that, or rather than saying the subsequent release, we could say that the next subsequent release, I'm not sure which is clearer for users you'd, have.

E

To say, 45 days before the next subsequent release.

I

No, so it'd be 45 days. So if, like we're talking about one nine, it would be supported until 45 days after 111 ships. Okay, right now, it's supported more or less until 111 ships with a little bit of variability depending on if a release slips or things like that.

E

All right, let me capture what we think the message would be. One line is supported until six weeks after.

E

Ships and the message if we were a whole release, oneline is supported until 112 ships right yeah.

E

uh On the even odd thing, uh vendors who support releases further back uh are any of you doing an even odd or lts like thing.

E

I believe that aspen.

C

E

C

Let me capture- and I think it's actually, that they don't even ever support the the versions that are not every other version. They don't they just never ship.

B

I see so they only deal with the odd release. I assume, like one nine, that's.

C

The main question I got, but I I'm not 100 sure.

L

There you go yeah, yeah, no um yeah, so we currently support uh one six and one nine. So it's typically every two to three releases: there's, no! Even an odd.

M

We're in a similar position as well, I think we're currently supporting one four one. Six and soon one nine.

E

Oh sorry, who's that robbie.

E

Basically, anyone else want to chime in here, so.

B

Do we have anyone from the ibm team eric.

K

um Other other than me, um we could ask andrea, andrea to see.

K

E

I guess andre is there.

F

Yeah, I'm here.

E

uh And so uh ask the mesh folks when you do select a release? uh How long do you support it for.

L

We uh basically until um until we have like a following release that we wish to support so so like one six is still being supported, but um we will be ending that soon. um So there's not really a set timeline, it's more or less. um You know until we can actually get the next version that we do want to support, and then we, you know, give people probably about six months to migrate. Okay. So it's.

E

And n minus one plus six months, migration window.

L

Yeah or yeah around that time.

E

We'll um that uh brian, what does red hat do or something.

M

Yeah we do. We do n minus two of or n minus yeah, we'll do n minus two of our releases, but uh the older releases. We only do um critical and important cbes and critical bug fixes so uh for how long uh until the whatever release is gonna end up like that.

M

So I think like where we're at now coming up with a release based on 1.9, we would be supporting 1.4, 1.6 and 1.9 until we moved to a later release- and I think you know just this just has to do with our internal versioning, but because of the differences between one four right and later uh that one may perhaps linger longer. But once again, that would be just critical.

M

uh Patches um typically would be n minus two. So once we moved to 1.11, we would only be supporting 1.11 and 1.9 and we would drop support for 1.6.

E

Okay, so it it it's, not really n minus two, then right, it's n, minus one! It's it's! Our n minus two yeah.

M

uh Or or n minus one yeah, because we're really only doing the two most current, um we're still in the process of figuring out what we're going to do for long term support.

M

Because I guess you could say technically, you know we're. We have 1.4 is sort of unofficially that, because we're maintaining support of it because it there's, we don't have a migration path from 1.4 to 1.6. So that requires users to you, know, uh install fresh and migrate.

M

E

So you, you have some exceptions to the pattern.

M

uh Yeah, if we need to make exceptions, we make exceptions correct so like. If something came out like 111 and you couldn't upgrade from 1.9, we would cut a new release and you know call it. You know. Whatever our next major version number is and say we don't support upgrade from 1.9 to 1.11.

M

We do that on a product. We try not to do that, so we would but the changes you know with the removal of mixer and galley and all that were significant and you know didn't really support doing and because we support in-place upgrades right, so not really something that you can do in place.

E

Okay, folks, I think we I I have to drop, but uh the toc members. Why don't you annotate? What's here with your preference? So at least we get the ball rolling, even if we roll into next week.

E

Okay: okay, thanks everyone oops.

A

A