Istio Technical Oversight Committee, 2 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Technical Oversight Committee 2021/08/02

Description

Istio's Technical Oversight Committee for August 2nd, 2021.
Topics:
- External Control Plane to Beta - APPROVED
- Revision Tags to Alpha - APPROVED
- Issues with Kubernetes 1.22
- Supported Kubernetes versions for Istio 1.11
- Istio 1.9 EOL

A

Okay partying started, then.

A

Right go ahead.

B

Sorry, just closing a couple tabs real quick because the zooming wasn't really responding there. But I have a few hundred taps open.

B

B

See if that's any better okay, so let's see um july 12th yeah um testing should be done now. I think that was done last week. Right sure.

A

Yeah, it was done and thanks to john the last four manual testing he completed when we discussed so all the pseudos have been tested at this point and the ones required automation uh other than few. I think five or six most of them have been automated in p0 category.

A

um The next milestone is cold freeze, which is expected tomorrow.

B

Yep, okay, um release updates. um Do we have anyone from the 111 release managers here.

A

That's what I'm thinking I don't see anyone normally john. He joins and he's not here, um so I can work with them over the channel. We have reduced a lot from last 16 to two p0s, which is a great news, but that one release blocker on their books still ongoing. So I have to check if it is going to be a problem, because we have a code free stream here: okay,.

C

uh Is sam here because I think sam is the one who is working on that release brokers? Maybe some can update us on it.

D

Yeah, I'm here um yeah, so for some context. The issue is, uh we moved the validating web hook from base to to be a per revision resource and to keep it from purging on helm installs. We had to keep like a lame duck validating web hook in base, um so it turns out that that's actually an issue because it creates a lot of error logs whenever you apply resources, because the ca bundle never gets patched in.

D

So I think the fix is just to remove it from base and add a caveat to the helm, install and upgrade documentation about. uh Well, it's it's described more in the issue, but uh yeah, I think, there's a fix for it.

C

Okay and sam, we were also missing the mechanism to install the per revision when via helm, so I'm guessing you're going to fix that too right.

D

Yeah yeah there's a pr link.

B

B

So the next one on here is um release 1.12 um recruiting. um Do we have any updates on that.

A

So um friday, actually louis mentioned that um there is some discussion in the studying committee. uh Swain is here, probably have more context and there is a sheet where we are updating the release manager. So what louis mentioned is that it will come up in the toc.

A

um I do have the link to the release, but um swain, can you provide more context from this one? uh How we are proceeding and who is the responsible folks to add the information in this sheet.

E

On which sheet.

A

The istio release, so I just paint steel release manager schedule uh what he mentioned was there was some discussion in the steering committee uh that, rather than looking every quarter to have it like built for complete one year and um each company should volunteer the release managers so right, if you can click on the sheet, but louis mentioned that this will come up in the geosync. I.

C

Can give more context while, when it's trying to refresh his weakened memory, so basically the context is we were discussing and steering how we can better staff the release managing uh process? If we agreed to extending support for sto last week mitch brought up, can we extend the support for history releases for three months or every alternate release for three months? Whatever?

C

It is one of the ideas to better staff, it was if we can have a better rotation policy in the release managers group that automatically shares the burden among vendors and whoever else is heavily involved in the community. So as part of that exercise, louis started writing down who have been release, managers, people and their affiliations, and this is what we have so far so going forward again.

C

We can try to manage this load better and if we want, we can create a schedule looking ahead with two or three degrees in advance, so that you're not always scouting for people, then uh you know searching uh deliberately desperately in the last minute. Did I miss anything swain.

E

I think that's right yeah. This was part of the discussion of how to better resource. If we're going to extend support.

B

Now would that be saying this um individual will be a release, manager, six or nine months from that date. Thank you.

C

That's the idea.

B

C

If, if we decide to extend it, then the responsibility is also extended.

B

A

So um how are we going to add the names here right? Otherwise, this sheet will remain empty. I just want to make sure we have the responsibility of and or the responsible honors or is it volunteer? How are we trying to add this? I.

E

Don't think we had agreed that we were going to do that right, like this was just we had started the process of looking backwards. We hadn't started the process of looking forwards yet so I don't want to rush ahead being like. Oh we're not doing this and we're not going to fill everyone out right like I don't I mean nero, is crappy from wrong, but I don't think we had.

C

Quite no, I and I was going to say the same thing. I don't want to rush here. First, we need to have some basic agreement among companies that are sitting in the steering and then peop folks who attend toc. Let's collect those names and understand how vested they are in being release managers, and then we will see whether we can actually fill this out.

B

I have a similar dock that I'm keeping track of for other reasons in the seo community drive by the way. Now, I'm going all the way back to 1.1.

C

Oh great, then, if you can share that also and add it in the doc document. Probably louis can just stop his work and take it from there.

C

Yeah, this would be a very helpful brand thanks.

B

Yep yeah, I wanted to remove them from the groups and um I wanted to remove them from the groups without actually removing the contributions.

B

E

It does leave us that, still needing one to two more for 112, it does.

B

Okay, so looking at this, we have today um securities um uh roadmap presentations.

E

It should be down in the in the agenda for today. Yeah should be, I don't know. I.

B

Can't guarantee that okay um do we want to go top to bottom or start with that and go on. Maybe we should probably start with that. One: okay,.

E

Is that is that actually, on here.

A

E

No, the uh whoever was doing a remap review today, so.

A

The security was supposed to present and the message that they are not ready. Okay, so we have to skip for this. One.

E

E

All right, I think, but if mitch is mitch, is not here and louie's. Not here I don't know if we want to so. If we're going back to the top, I don't know if we want to talk about skip the extended sport discussion. um I can just mention.

A

E

Discuss it in steering and one of the things there was some desire to actually support, extending it for every release, not just um alternating, but obviously we need to know exactly how much that's gonna cost to do.

B

Yeah we we discussed the alternating last week and then we asked third the um ever released last week and then we asked for alternating. So now we have both um yeah, that's cool.

E

F

Let's, hopefully we can have the sort.

F

I guess between miss and brian all the data should already be here right, so in fact yeah. This is on vacation, but he specifically mentioned that he doesn't need to be here to discuss it, because if all the information is there and um toc can actually decide.

F

uh So if that's not the case, then of course we should wait, but so what is missing.

B

That's a good question uh mitch did send out an email with the update friday and we're still kind of discussing that in tsc um like friday or today, either way that conversation really kicked off this morning. So I think it's probably better to wait until next week, but.

G

Yeah he did send an email. He looked forward to discuss on august 9th, which is next monday's toc. Maybe because he's also looking forward for brian avery to collect feedback from the product security work group tomorrow, right.

B

Yeah, that's right! It's on thursday we're discussing that.

C

But yeah so to take this forward. I think the ask here is all toc members make sure you respond to mitch's email say you know what consents you have or what methodology you prefer so that we can close on this by end of this week and then have a good discussion next week. Plc.

B

Okay, so next here we have the external control plane, beta promotion.

H

Yeah so frank was on the call last week in this guy- and I was out- and this got postponed to this week and of course frank is out this week, um so he asked. If I could, I could cover this one, um and so basically um there were a couple of things left um for um promotion to beta. um If you actually look at the the files changed, um we did already. We it's actually interesting.

H

If you look the files change, it already says: toc approves this so um at the bottom, but um the the key things there were. We did add istio.io tests, um so they are, it is being tested as as part of the sdio test. um I believe lin did have the supportability review um in december or january, so that one was checked off and sort of.

H

The key thing that was left was the integration test and there was there was one um it was being skipped because it was flaky and in reality it really didn't test that things worked. So we did update that so at least now it's it's being tested. We are verifying, indeed, that the gateway is created and running.

H

There is one pr that frank worked on last week, adding the reachability test, and I my plan is now I'm back this week to review that and um hopefully get that pushed in.

H

um I guess it'd be good to be pushed in today um with code freeze, um and so that test is now done um so sort of the big thing was to make sure we got the testing done and- and we think that's complete- um we do still need to to get the reachability test merged and then add that into test impress, so that is being run on every build.

B

So you think that'll be completed today. You said.

H

um Frank told me the pr was was ready to go um part of the problem. I was gonna go and look at his new test to make sure that worked. Okay, um part of the problem is it's a tnr thing and I can't approve it because I have some commits in there. So um I will need to get somebody from tnr to approve that once it's once I verified that that all looks good and then I'll have to tweak my.

H

I have a pr out and test infer to add that test um was actually my old test, so I'm gonna have to tweak that pr a little bit and then we get that in and then that should add the test into the pipeline.

C

So I recall the changes and enhancements made to make to ensure this is better quality. Look really good to me. My main concern here is: we are relying on mesh config for this feature, which I, which I think we brought up last week and we have been holding back promotion of quite a few features because it relies on mesh config. So I would like to get consistency.

C

Okay, yeah. I that that's fine.

I

What about this relies on mesh.

C

When config look at the docks, it has a lot of things from mesh config. Take a look. I don't know specifically.

J

That I think it's all time, options now yeah.

I

I mean I don't understand: what's what the issue is with that of course, message. Config is how you control the discovery address so like, but I don't.

J

Know what else.

I

We can possibly do and why we would hold this back based on that.

J

And to be clear, this is not a user. I mean end user doesn't actually deal with that. That's practice, something that the operator is doing.

J

Using mesh config, we.

G

J

G

Using this by the way, just quickly check me.

J

G

Said they are using this uh yeah, but but I do agree with you uh costing jones comment about using mesh config, though, because the external htod doesn't use more at match, config than multi-cluster support. It will be very minimum just to like indicate discovery service, which we do it in multi-cluster. Also and multi-class is already beta.

J

I mean sorry what I meant is: users are not actually interacting with mesh config they're. Not. We are not asking users to change machine league as an api. It's just part of the install options and and and usually for external, it's managed by some operator or or some other entity.

G

Right exactly, I agree with your point yeah, and- and this is no more than multi-cluster installation of this shield right so.

A

It's less based.

G

Only at the installation time the interaction with mesh config.

G

C

Okay, that's fair, I think, and there are a bunch of it- relies also on a lot of the values uh like the sdod, remote and stuff like that. Is that supposed to be the stable api? For this feature.

J

It's not an api anywhere, I mean. Is that that's an installed experience, but I don't think we consider the stuff that is done when you install this dude to be on the same level with with uh you know, routes and destination rules. I mean the problem is at run time after you install istu and as a normal user. That is interacting with istio. If you are required to use those apis and we are required to support them or not,.

C

What do others think I don't know? It really feels arbitrary and defining the support policies and our graduation policies on the fly to me, and we try to rationalize this on per by case by case basis, which is very difficult.

J

But install versus runtime is not very difficult to know. I mean it's pretty clear, cut.

C

Okay, so going forward whatever install time, irrespective of where that state is that is supposed to be stable, as in that, whatever the feature, uh how, whichever feature consumes it it doesn't matter, we can promote it. uh Anything runtime which comes from mesh config cannot move past alpha.

B

So I guess my thoughts there are, I mean mesh config is integrated into all sorts of stuff. We can't just block everything because our installation ah changes um the other thing. There is. Presumably most people have like staging environments and everything that they're running their installation through before they actually deploy.

B

So they've done some testing to make sure everything came up and everything before they go into production and when they do go into production, they're much more concerned about the run time and things make being stable over time than they are that initial installation that they've tested.

I

Yeah, I'm pretty concerned about this thinking that if something uses mesh config, it's suddenly stuck at alpha. I mean all right.

C

I

We need to have a way to configure mesh settings and mesh config is the only way to do that now and there's been no proposals on any alternative, so without that we either have to allow mesh config features to be promoted or just stop promoting anything, and it seems like the first option is a much better one.

I

In fact, perhaps we should promote mesh config itself to beta officially now, certainly not all fields of it, um but like, for example, auto m2 us that's in mesh config. That's just. I think it's stable now we're not going to introduce like a new crd just to enable or disable you know, auto m2s, like.

J

I I don't know uh john, I mean uh if we believe that users is easy, is auto mtls, something that that should be. You know global for the entire mesh and be set up install time and only by things administrator or is it something that should be set at name space level and and have a proper api meaning you know in networking I mean why. Why is that the telemetry telemetry is 90 of mesh config. We agreed already that users may want to have. You know individual namespaces with their own options, not to go.

J

Try install list every time you want to change something.

I

So uh yeah I mean I totally agree: there's things in mesh config that should not be a mesh config, but there's also things that are in mesh config. That should continue to be in mesh config, for example, uh settings on how to connect to kubernetes. That has to be in mesh config, more or less right, like.

G

Discovery address.

I

But yeah I mean every every everything has config maps too, like every linker d, kubernetes prometheus, you know, yeah, they all use config maps to configure these type of settings. It seems like a perfectly fine way to go. I'm not saying every field should be in there just the concept of having this mesh config. That's you know this container.

J

I

Configure z2d so nobody's.

J

Like this with having mesh config and a couple of fields but discovery address, isn't proximately by the way which is already scheduled, but I was asking if you find any field in emotional things that you think should be reserved, because I didn't.

J

But the question is we need you know proper review and and to select the field that we may know that that was a plan. Are we changing the plan.

I

Well, I think we we should go through all the fields, but we shouldn't hold up all these features that happen to depend on existing fields, just because they happen to depend on these fields right.

I

It's not like this is adding new fields to mesh config, or this is using fields that are already used by other features as well. It doesn't make sense to me to hold them back while the other features they use. The same exact fields are our beta already.

E

Yeah generally, I kind of agree. I don't think we should be holding back features because we can't get our api act in order right. So how do we stuff? So anyone who is saying we should block things needs to propose fixing things and actually get them fixed and not just block right. We can't we can block promotional features.

J

But then I thought that consensus was that we promote things to a proper api with review. It has an api, we define the api and we application support telemetry, for example. I thought that was the conclusion. That security is that there will be security, api telemetry api that includes the features that we want and users can interact with them. With you know, proper, arbuck and and normal behavior, and not requiring instructions, that's a fundamental problem.

J

We are saying that to operate this feature you need to be measured, mean and train stories, because that's how or to to control this to your system.

E

I'm saying to promote things, we don't need a block on getting that solved. I agree.

A

E

Where we want to go, but we can't block all progress in the project.

J

Well, but we're not we're not blocking we're, not saying that we cannot promote features that that install time need to use some mesh configurations, that's okay, but if they require users to modify mesh config to properly work with that feature, that's a different story.

C

I'm sorry I mean these agreements. I've never heard of an agreement like this before whether that first I mean I heard about fee if you're, relying a feature relies on messenger cannot be promoted few weeks ago, when jacob told me that we were trying to promote uh topology configuration for uh and it was never promoted, even though all the work was done and that's why I'm bringing it up because the reason was it relies on mesh config now.

E

Right, I'm saying we shouldn't do that you should I.

C

B

E

J

E

Like, let's not, let's.

J

Oh uh that's a perfect example here. The network topology is a perfect example. I mean it's the problem, it's not that it lies on measurement fixed promise that in modifying the istio system, for something that that normally should be. You know the name. Space, employee.

C

Yes, I understand the end state. We have users who are using an alpha state feature for long and they don't want to use it in production. They have done their testing. That's the problem. I'm trying to solve right now the magical api that we are proposing. If it comes to the today, I will take it, but it has to come in six to nine months. So.

J

If someone wants this feature to be promoted, they will define the crd or extend the networking api with with, uh with whatever is necessary and it can be promoted. I mean it's arbitrary.

C

Blocking of things that's not allowed, we, it was agreed to put in there as and then follow the process of promotion. I'm sorry.

I

So I think so going to the external control plane doc. I pretty sure the only field that's used in mesh config. If I'm reading the dock right is root, name space, so there's one single field and that's clearly not a user config right that is the owner of the control plane decides.

I

So I feel like the concerns that users shouldn't have to modify mesh config doesn't apply there.

I

The topology thing is actually part of proxy config, so I feel like that's, also kind of in a different category. I don't think that should be blocked at all and but it's not even in mesh config either.

I

So I feel like it's. I don't know a bit orthogonal.

J

I agree so a proxy config is going to move to a crv to be better. So so, uh at some point I mean that's that I think that also at least on that we have consensus.

J

uh The question is: are we saying that proxy config, which is alpha in the current form, automatically becomes better and and will be supported, long term without a crd or as it is right now, that's what you are proposing or what exactly do you want? How we are going to to to to keep the current proxy config and mesh config and and how it works and support it long term.

I

uh I don't think anyone's saying we'll keep the current proxy configured. I think we all are in agreement that we want the proxy config crd resource yep and.

J

I

That consensus.

J

I mean I'm not sure what changed here.

I

No, no, I don't think anything's changed. We want to promote that to beta, but that doesn't mean that any feature that happens to use proxy config today is now suddenly stuck in alpha. um I mean.

E

Almost every feature.

I

Uses mesh right, so we can continue to move this forward and proxy config forward and everyone's happy. I think now I guess we're all saying: like we shouldn't block things, does anyone actually think we should block things? If not, then maybe we're all fighting against uh a conclusion that no one agrees with.

G

Yeah, so I think there's maybe some confusing here right. So if you look at mesh config, there are certain configuration, that's more for whoever install is still kind of the administrator role of istio.

G

There are certain roles, uh that's more for a little bit more. You know a different team that who maybe can fix their issue for their services, or maybe the platform team, but not necessarily who install and manage istio. So if you look at this external issue d, dock in particular, like john you point out the route name space right, so that's whoever install installed istio is going to config. That and it's all said I mean we don't expect people to really change that.

G

So it's really provided by people who are managing this and there's no plan. As far as I know, to graduate that into a customer resource right. But on the other hand, if things are in proxy config we're already talking about. First of all, it's user facing configuration second of all, are already in the process of moving them to a customer resource.

G

Now that I recall a few weeks ago, we may have discussion of when things are in proxy config. We were nervous about them. Moving to, I think we may discuss moving to stable because of the api is going to be drastic change from mesh config into the proxy config on customer resource, so the user experience would be different, so we were hesitant about the promotion and, if I recorded it correctly, the discussion was around promote too stable.

G

So I want to make sure you know we separate these two. The configuration just at the install time was the configuration every service owner or maybe namespace admin would deal with it and it's going to be moved to a different customer resource from mexican thing.

C

Yeah lin, no, I I understand it. My point of raising this today was to make sure we are not arbitrarily blocking feature progress, and I think we should have a consistent philosophy, and I agree with swin yours and john's overall statement. Many features rely on this. If the feature has achieved the status of data, we should just make it better, and I understand that proxy config someday will be a crd, but I don't think we can hold things up.

J

So you want a feature that is better with alpha apis that will change. I know.

C

I'm sorry, that's what the state of the community is right now constant.

J

So why why would the user trust the features or advertise api is going to change? I mean you can't.

C

Install this still, if you consider mesh config and proxy config to be big alpha right now. Basically, nobody can use this too.

I

If, if our entire concern is around proxy config being alpha- and we know that we plan to promote a beta next release, then it seems like the only things that matter are this particular feature, because everything else will have processing fig beta by then right.

I

So to me, I think, there's kind of two use cases of proxy config one is. I want to configure every proxy in the mesh, because it's discovery address and they're all the same and the other is, you know, actually things that are configured per proxy and to me this is just global configs, which it doesn't really matter where it's configured right like we can keep the same api. It's just. The admin sticks, hey, here's, the caa and everything kind of works.

I

If this was something more, I can't think of a good example, but like per proxy, maybe it'd be worth waiting. But to me I don't have an issue with this going to beta and then next release, proxying fig itself becomes beta and from there on out we don't really have many issues. Does that make sense.

C

K

Yeah, it makes sense.

E

K

E

Yeah, I'm mostly just agreeing, um I I think the the concern that many people having including me is like. I don't think we want to promote mesh config itself, as is to beta and stable, but I you know the point I'm trying to make is like just because we know we want to get rid of that api. We can't block features that depend on it from getting the beta right. So.

A

E

We have a case where you have this. You know not even alpha api that is dependent on by all these features. um It's just the state we're in and I think it it means we need to move faster and we need to make more progress on getting things out of there right proxy config is a great step. We need to get the rest of the work done, but.

J

uh It's not a binary choice. Here I mean we either promote mesh config to half hour or we don't promote features I mean we cannot. We have also the choice of if you have a feature, if you define the api for the mesh complete and then it defines the proper crd or you put it in a proper place as a better api like we did.

E

Telemetry we need to do that too, but I mean telemetry is a great example right. It took. I don't know how long doug had that pr out right, like it took like a year for us to agree on an api, and I don't think our users will be happy with us if we take a year to promote anything because we're trying to define apis. So that's saying like we need to decouple these right like yes, we need to get the apis done, but we can't block the features from like if the code is stable.

E

You know we just put the caveat that sorry, you have to use a an unstable api, but.

J

Is isn't it working as intended? I mean mesh config was where we can put an api quickly, knowing that it's all fine, it can change, and we don't have to wait a year for equality to be. You know to get because for api, you need, you know to get a quality api. You need reviews a year is not you know, just uh just waste it. It's it's based, you know, get feedback and and make sure it works up.

J

That's why you put in the mesh copy and alpha first, because you want to get feedback and make changes later. If you are saying that everything in mesh config will automatically become stable magically, you know, how does it work is chicken and egg.

E

So, that's that's not what I'm saying right, I'm saying if, if you have to configure something in mesh config to use a feature that feature can still go to data and stable.

J

If the user doesn't have to change it and and and and kind of you know, every user will have to like we'd have the policy apis in security. Basically, where, where uh you know, everyone had seminar all kind of namespaces and it was almost impossible to move yeah yep.

C

Okay, okay, I I'm fine with this promotion. I'm also gonna recommend again jacob to bring back the promotion of some other features that have been blocked before on the basis of this discussion today,.

J

And and maybe start the process to promote to actually define the beta apis for those features, you know the right place to have them, and if the api is right and then starts up to review because, as then said in mesh config, we have a very light review process. It's basically anything goes well for proper apis.

J

Usually there is a discussion that is, you know as typical for an api review like telemetry and which can take a bit longer because that's how you define a good api, but it's a process I mean we cannot have it both ways.

G

Yeah so niraj. Definitely uh uh I think you should ask jacob to bring it back um so that you know we have consistent rules um for different scenarios and then for the purpose of external control plan. I'm not hearing any objections. Should we just record tlc approval for for this to beta.

B

So I have two things to add here: um first of all, looking at the actual list um there's a handful of things that aren't addressed yet um and if they're, an explanation of shock would be useful there um and then the actual promotion of this is tsc approves the promotion but yeah. We can record it in the agenda.

B

I'm just noticing that two performance things in the three test- um things which I know eric said: there's a test that still needs to be reviewed, but.

H

Right there's one test and I mean the performance stuff. We really don't have anything multi-cluster performance. Yet, as far as I know, I might be wrong.

H

I'm just sort of going by some stuff that I know frank and I had discussions on.

H

And, like I said, I know we had the reachability test.

C

So I think the conclusion here is directionally. This looks. Okay to doc. Thing is back on github, whether it's issues or pr saying all the checklists. All the check marks are done, or these things are remaining and why and then the final stamp can be given.

H

Yep, okay, so so just add a comment to why stuff that isn't checked is isn't checked. I guess yep thanks. Okay,.

J

One question: thank you. One question we had uh in environments when discussing this feature uh was if we, if this should be a top level features and and treated as such, or it's just a sub case of multi cluster, because in reality, 99 percent of the feature is multi-cluster, which you already support.

J

So if we just want to to document it as a subset of or a variant of multicluster, and not kind of expand, even more as a documentation area, I think it's okay to have it as a prefecture, but just want to make sure that people are aware of this choice and we are consciously making it.

I

I think in general it would be good to consolidate them. Well, I think, there's kind of two things. One is how we document it to users which, in general consolidation, is good and two is how we treat it here like in terms of promotion, which I think it's fine to separate, because that's more tied to the actual development.

I

I do think in the current state. There may be some concerns about merging them because it's not like they are still fairly separate, but I think, like at a high level, it would be good to consolidate them, I'm just not sure how feasible that is right now and there may be some more work needed, but I agree in in theory. It should just be I'm installing multi-cluster. Oh, I happen to want this to just be on its own cluster and it should be good to go.

J

But I mean installing history, and just this to install happens, to have multiple clutter. It may be external in terms basically.

G

A quick question here: do we support in-cluster seod to upgrade to external ecod for the upgrade nodes.

J

In in reality, I don't know if we support it or we don't support it, but it is possible and- and you know it's something you can do with just uh standard apis- you can just get a certificate, apply an api and it becomes external. So there is nothing special about an external studio in reality,.

G

B

Special move on.

G

Yeah, so um I took some notes for this uh check if you agree and I think we're ready to move on if everybody agrees.

C

Yeah goodbye thanks thanks.

B

Okay, so next promotion.

D

Yeah, hey um so pretty much. uh We added the feature officially to the features, uh repo or the enhancements repo uh last week, and the only remaining thing for alpha is the api review. So I just kind of uh wrote up the current state of how you configure revision tags um in a doc and I'm not 100 sure.

D

um What's looked for in for alpha api review, but uh everything's there in the dock- and uh I guess I guess the main thing I'd like to call attention to is the helm api um so the way that you configure revision tags for home um jacob wrote a great doc on how to do that right now and it's like you, use, helm, template and coop control apply, but um that may change in the future into having a separate chart for revision tags.

D

So uh yeah, that's that's the main thing I wanted to call attention to for whether this is ready for alpha promotion.

J

All right and to consider, why do we need him template and keep cutter applies because of the upgrade experience because of the resources and for the base chart. Now it's only for the base charge that you need same template and keep cattle appliances because of limitations at home.

D

It's actually not home templating the base chart it's home, templating the revision tag um resource in the istio discovery chart. Oh.

I

I

Do you recommend helm template because that's what we like or because helm install would not work.

D

It was because helm installed did not work.

I

Because of that resource ownership.

D

Yes, yeah, you can't swap it around between revisions.

I

Can you swap it if you use like the special helm? Well, you can probably discuss it offline, but uh I mean I.

J

I I have that separate chat for for just uh revision, and it worked perfectly fine. I mean it's, it was not a problem, so I wouldn't you know for for the video pin. We know that we have an option that doesn't require this. We can install this ud with one command and have a separate one for the tag.

J

Let's, let's review it again in environment and I'm I I missed this part. I thought that it resolved and didn't require.

G

So this is not to block your promotion to alpha just curious. um Your thoughts are: are we going to have a proper api for tag? The tech commands, because I remember when you initially proposed these tech commands.

G

There are a lot of comments around and this is going to be in a proper customer resource or a proper api for user to um to set the tag.

D

Yeah yeah, that's that's a great question. um So initially we tried putting it in the istio operator. We figured that was a decent like the place for the declarative api on revision tags, but turns out. That's actually not a great place for it um and you would want kind of a global resource that spans across revisions and then you know like a global resource. That applies to all revisions. Like here's, the review, then a controller that you know reconciles the revision tag uh mapping there into mutating web hooks.

D

um I don't think that that's planned right now. So basically we wouldn't have a crd for it. We would have a dedicated home chart as like the uh declarative way to do it and then the uh just the cli, just the the istio control tag.

J

Especially since it's not something that regular users will will do, I mean it's not something: the user control which tags are available. That's a cluster admin, the installer.

G

Yes, it is cluster admin, but it's not like a cloud provider right. So whoever uh owns the cluster, um they would need to set these uh to specify which one is the production which one is their canary yeah.

C

Yeah, I think, lynn, what you're saying is if a platform operator or the mesh or whatever the operator who owns stu is, is there if they're trying to do this through a ci right it feels like they will have to do like update their ci workflow.

C

Add these to ctl tag commands then delete it again and stuff like that right, because it's not declarative.

G

Yeah, because one of the reasons also, I heard some of our user doesn't like to add its joker into their developer pipeline.

G

Part of this is because it wasn't approved so they had to seek special approval, so many of our commands can be controlled by customer resource right, so they know how to add a customer resource or apply a custom resource using cube cuddle, which is already approved and given the helm option, it's still vague to me on what to do in that scenario. For him, which is why I was wondering you know what are the api we have available for the user without it still cuddle.

I

Yeah lynn, I think there's two things like one: we could, in theory, introduce like a tag, custom resource, but there's substantial implementation complexity with that, because you need something to actually reconcile that which one we have to figure out, which easter d actually does the reconciling, which the reason the way we do, that is by the tag resource. So you have a bit of a chicken and egg issue and it requires extremely high permissions that we don't currently have.

I

But if they don't want these to a cuddle, that's fine. They can like they tag generate, generates the plain kubernetes configs and they can just stick those into their pipeline. So they may need to run easter cuddle once on their laptop and then check it into git or whatever. But I think that's perfectly fine.

G

Okay, that's good to know I I didn't. I was not able to yeah.

I

Tag set is like okay, it's like uh applies it for you and tag generate just outputs. The m1, then you can you've, got to apply it. If you wanted.

G

C

Yeah and basically the helm, template command is mimicking time generate.

J

And there is an api that exists to do to do this, which is uh the imitating web hook api, so users can create a dating web hook. Format. It's not not nothing, special! That's what really disturbed us.

G

Okay, that's great, I don't have any concerns, then.

B

So did you say you're going to take this back through environments costing? Are you asking for approval.

J

Details the details about helm: how to do helm uh install uh because it is possible, I mean even cam. Template is okay, but uh I was not aware that that we we we referred to backup to keep cuddle, apply everything else. Okay,.

C

Yeah austin that.

J

C

Great, if you can come up with a workflow without relying on cube ctl, so yeah we can. We can revisit this discussion next week, if it's not too late for you. So.

D

Yeah, that's fine.

B

Okay thanks so.

B

Next on the list um is um kubernetes, 1.22 is out um august 4th um and whether we want to do a banner on s2io uh warning users uh that 199 pillow won't work.

E

B

Yeah, what's up, what's the minimum we support right now? Is it 1.14 everyone that yeah? No it's past.

I

1.14 yeah, what what version of kubernetes our official support for 1.10 is 1.8 18 through 1.21 or unofficial, 16 and 17 also happen to work okay. So the problem is that historically, we have.

I

Newer versions, have just happened to work, and so people have upgraded kubernetes beyond that window.

I

This is the first time I think, maybe even ever, that a new kubernetes version actually breaks istio, uh and so the banner is basically just saying hey what we've been telling you all along is actually true this time and it will legitimately break so make sure you you understand that so we we're inside of our policy. It's just we've always been more lenient before okay 116 had something that broke something too right, uh yes, but that was kind of the opposite. It was the you had to be on.

B

A

I

Is the opposite where, if you're on a two new version, then it breaks uh yeah.

B

I

Yeah, what's the breaking change, if it's easier to summarize uh yeah, they removed the old crd web hook aps and ingress.

B

Yeah that makes sense to me. um We also have the um issue io support section, I'm wondering if it's worth it to add something there, meaning.

B

B

I

B

I

Good to me, there's uh there's a supporter release page that has like a table of all of them. Okay, we can. We can stick it in there or uh maybe on some somewhere in here. I feel like just we can stick wherever anyone's going to look and it should be fine, yeah more eyes. The better okay.

B

So the next one here is schweitzer um 1.11 kubernetes support.

A

Yeah because we discussed that also in the working completes that we are planning to have a banner up for any versions which is uh which will not work with k test one by two two.

A

um So just a fi for everyone that we are planning to do so, and this is going to be the ownership of the docs team to help us. Do the um banner update on the stereo dial.

I

Yep, so for the next one, 1.11 support seems like if we just go with bumping one version from the previous one. That would mean 1.19 to 1.22, which sounds reasonable to me. I don't know if anyone has opinions on varying from that.

B

Our policy has been three or four releases, so that makes sense to me.

I

Yep that would continue in line with what we've done test or the tested, but not officially supported, would still be 1.16 plus does happen to work.

B

What were you saying.

C

uh Now, which version of kubernetes is the one where they extended their uh support window.

I

It's a good question. I don't think they retroactively. Did it so I'm I'm guessing it's 1.22 or maybe 121.

F

C

I'll I'll look at it good as long as it falls within our support window, it looks like it will.

B

Okay, so the next one here um seo one nine end of life on august 18th, um final security patches um august 20th um go on patch 1.9, even if it's end of life, um yeah.

A

Yeah, this is fyi that we are going to do so um if there is a concern, let us know.

C

You say patch, you mean you're going to make a new release right, or is this going to be patched and not released.

A

Might be a new release or 1.9? The problem was, it was going end of life, but we still wanted to okay. The last one is really the reminder of the toc a month and a half back. We discussed that. We need a one-pager strategy for 2022, um so I I'm the eta is end of august. So please make sure because all this just started, and so I just wanted to make sure there is a reminder.

B

um You said eta is end of august end of the month, yeah, because obviously yep, I'm just gonna.

A

So it is for all the tiers. um I don't know if anybody is planning to take a lead, but we need a strategy document for next year, so uh we can drive all the working recruits to start working on their roadmaps, but I need a strategy.

A

A

So you want me to bring it up in the next one. Our toc is okay to work offline on this one.

E

Off channel and then I'll go, let's bring it back up again next one and let's assign assign people next.

A

Okay, I will work off the channel. um Did we yeah sorry go ahead.

G

I was just going to say I remember last time we had this topic and the the reason we pushed to end of august was because of the release and also because collecting feedback from the customers. Are we going to have a user meeting to collect a feedback, or do we want each vendor to do that themselves?

G

What's everybody's input.

B

I think a follow-up from the istio community itself would be good, because istio doesn't necessarily have the same goals as all the vendors.

G

Yeah I agree so maybe we can take offline to figure out. How do we schedule these type of meetings to collect the information.

A

So I think that's helpful, uh so, let's work in the channel also do we have consensus on the um istio 1.11.

A

It has support because I heard there was a discussion for supporting 119 to 122, but I did not hear if we have consensus yet it should go back a little bit up. Brian yeah.

B

I thought we decided 119 or 119 through 122., okay,.

C

B

C

Record it, if you don't mind, okay,.

A

Yeah, thank you, yeah. That's exactly what I was looking at.

A

And did someone confirm it's in the support window? I know we were looking.

B

Support window for kubernetes.

A

B

um I don't think so.

A

Okay, maybe you can chuck offline brian and update this yeah we're out of time sure thank you. Yeah.

B

Thank you. Goodbye.

C

Thanks everybody.