Istio Technical Oversight Committee, 14 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Technical Oversight Committee 2021/06/14

Description

Istio's Technical Oversight Committee for June 14th, 2021.
Topics:
- Review ProxyConfig CRD and proposal to move it to Beta
- Discuss request to move releasenotes tool to its own repo.

A

All right, next up for the 111 release, managers, uh louis and kevin, uh I think, for the pa. uh We were trying to see if you can get someone more experienced from google or red hat to help ryan and steve here. uh Do we have a third candidate.

B

uh Sorry not yet all right yeah. I still need to chase that up. That's fine! Just let us know uh we need to we'll do that.

A

uh Yep uh cni beta graduation doc uh feature. I did look at it, it's really well written uh and I like that, do you want us to review it now or just.

B

Yes, offline review, yeah, please, stick we can keep feedback. Yeah see is.

A

There everything's.

B

A

Yeah, I think it's really uh nice. All the aspects are well covered and I look forward to seeing it implemented so I'll move on with the agenda unless there's anything else that someone wants.

B

A

This cost in here I moved your agenda item to the top because it was left last time. So do you want to take it over question.

C

uh The proxy config- uh yes, let me can you click the link actually, since you're there's anything? um Yes, so environments and uh networking working groups we discussed. This uh remember uc asks us to to promote the alpha apis and we picked proxyconfig because it has largest and broadest usage and it's probably most useful.

C

um We went over all the fields in proxy config and we found the number of fields that are either no longer in use. Probably are not very critical or are deprecated or are internal and and don't make sense to expose us an api, and we ended up with a with a relatively small set of fields that we believe could be supported and should be promoted to better.

C

In the process. We discussed uh the relation between proxy config and sidecar and how there is a bit of overlap, and the proposal is to actually take some fields from from sidecar like like export and other things that are critical and also add them to proxyconfig and same for some annotations or values.yaml or or things that were currently spread all over the place that are probably belonging proxy computer related to proxy config, which we should also add to proxy config.

C

Instead of of the current alpha places, and there are a lot of comments the doc is, is um you know uh after more comments, I'll rewrite it to kind of reflect the the the comments? But um I think we we. We are pretty close to two consensus, at least in those working groups, about moving forward with creating the crd and at least the core uh part of the of the proposal.

D

So what is the difference between sidecar and proxy config.

C

uh Proxy config can also apply to gateways, including kubernetes gateways, but not really different. I mean one of the discussions was, to just add everything to sidecar. The problem was that name is weird and a lot of things inside there are very rarely used like the whitebox mode, while the things in proxyconfig are frequently used.

C

So uh the idea was that eventually, sidecar would not be promoted to better towards stable, and we would like our.

E

Only it's like only alpha today.

C

No, it is better one, it is better one, but but uh we could treat proxy configures. You know beta two or kind of uh so so we we're not trying to remove sidecar. For bit, I mean it is just that that uh it will be easier for users.

C

To I mean we duplicate a bit of functionality like the egress, it's an opportunity to clean up a bit, the semantic and and and uh the name link for the for the visibility stuff, which is the most useful part of sidecar, and uh the rest will be only for advanced users.

F

Yeah, I mean I'm just kind of wondering like semantically what the difference we want there to be if there should be difference or if we're getting rid of one in favor of the other. ah It sounds a blue. I think I'm getting.

C

uh I think it's still useful for the use cases where you know advanced use cases, cases where people don't use ip tables and need to specify udp, port or uds or or other things that are. You know some advanced features that we need to support because.

E

F

What I'm trying to get at is, if we're going to have, we need to have very clear semantics for them right. It needs to be really clear to the user. What one is for and what the others for, and what divided.

G

Foreign and proxy config is largely not right is that is that the difference at least today.

C

No again one of the proposals, and- and we are pretty much close to agreement except for the name- was to just put everything in cycle. uh The the problem was first of all, that gateways would also use proxy config and second, was that a lot of things inside karatbar, very arcane and and specifically.

A

Yes, I think what mandal both are trying to say is also what we discussed right. We totally understand that there are overlapping semantics here. The issue is sidecar is a better ipi, but sidecar is very confusing. If that's the right word, at least for me, it is- and I have I've heard many other users express that, and the most used functionality in the sidecar like question is saying, is just to do config ruling via your egress visibility.

A

So we can't do much about deprecating those wheels and the complication with sidecar. So if you move it one way from proxy config to some car, you might make a problem of course. So we are looking for better cleverer solutions here, because I totally agree having two things is confusing, but both of us and at least john who we talked with- I mean we don't have better ideas, merging everything into one just feels like a big api, which will be even more confusing to our consumers.

C

And, to be honest, I mean I'm perfectly okay with merging them. I mean, I think there are trade offs, but I I really need it to be better. I mean, I think, the plan we came up, uh it's cleaner for the user because they can focus on proxy config and sidecar will be you know. Yes, then we need clear documentation, but.

A

For the developers too right, we have to have guidance, uh which is what I am a little worried about too right. So is sidecar more or less like a zombie api, then you.

C

Don't know advanced user advanced user, I mean we still need the functionality for for white box. If we want to support it for the one percent of users who need it.

H

I want to tell me one of the common user cases with scica. Is visibility right to be able to configure the visibilities of our istio resources? I think that's like a very common thing and we recommend users to do that in production environment, so that really feels more like proxy conflict to me, especially.

G

H

Talked about moving the outbound traffic policy to proxy config from the car the other day.

A

Yes, lynn, I mean I, I totally agree with you, that's why we are proposing it, but we still don't have a good answer for swan's question right, so we have semantic overlap.

A

How do you make sure developers understand new fields where they go.

F

Right in, and is there any what is the long-term goal right as a long-term goal to have two one?

F

If it's staff one, then there has to be a strategy for getting rid of one of them right and I'm saying we can't that's the problem. Well, it's fine! I think it's totally fine. If we decide the right solution is to it's just yeah. You have a very clear semantics of what they're for.

C

F

Like maybe I could imagine something like you know, if we were starting from scratch, you'd have proxy config and advanced proxy config or something right like you could have two there's all right series. It's just. We need to know what to do.

H

Yeah, if we move the like the visibility and the outbound traffic policy from psychiatry proxy config, it almost feels to me the sidecar for that for that, whatever one percent user customer you mentioned, that's really like an advanced proxy config like maybe, if we can position that way, so that we can move the attributes to proxy config, so user, most user 99 user was just using one api.

H

C

I, like it sorry, john and we have hands. Let's uh use this john.

I

Go ahead, uh john right, so yeah. One other reason why it's good to have another resource, I think, is that the emerging semantics, the proxy big and sidecar are planned to be different. um So I mean I suppose we could say these new fields have a different urge than the old fields, but it may be a bit confusing, but with proxy config we definitely need merging. So you can do things like set by defaults, like you can today, like discovery address, that's very unlikely to be set on a per pod basis.

I

And so yeah that's pretty much. It.

F

What are the emerging analytics of sidecar, or is it that there aren't any.

I

There are none.

F

I uh my sort of initial reaction to that is that we should not have different semantics right like we should be consistent. It's really confusing for users to not be so yeah.

H

Like we should move.

F

Towards consistency as a project, just in general, on with merchants but yeah no did that.

D

F

Different today,.

J

So I guess two things so I guess long-term sidecar will be deprecated by gateway, correct.

J

So the we're not as concerned by the survivability of sidecar, necessarily as an api, because it has an an impending replacement um castle and john. What do we think the likely difference is between proxy config and gateway costs.

C

uh For gateway, kind of expect gateway will disappear, replaced by kubernetes gateway.

J

I don't know, I mean gateway class. Oh.

C

A gateway class, oh gateway class, is a cluster-wide configuration for. uh I.

J

Think there's some debate now about whether it's actually cluster-wide or not uh true,.

C

Yes, that's that good, but but uh again the class has inside the kind of a custom field which is proxy configurability. So if, if it doesn't.

K

Know that that's why I'm asking right.

C

Yes, we'll put plex property config inside that proxy class as a configuration. If they go this way.

J

So when we say inside what do we mean in terms of structuring the api.

C

That that's a class configuration, however, the class specific configuration will be represented. The content will be proxy config, so I don't know if they will have a reference to proxy config or it will be in line, but the semantics we need for configuring, that particular class. If we, if we go the way where we are saying, then that that seems to be very close to.

J

Right, it's just worth noting that gateway class is referred right right. It's not a reverse workload, binding to attach.

C

J

So we need to figure out how we're going to do that composition.

J

Or, what's that.

A

So while I agree that intent should be that sidecar api gets replaced or consumed by gateway class, currently the some of the configuration we provide at the sidecar api level, it doesn't feel like gateway classes, will ever provide it, especially.

J

Around class sidecar should get replaced by gateway. If it's, as you know, one of the semantic divisions is routing or capture concerns, because, whereas proxyconfig, which talks about kind of or a bunch of kind of runtime properties of the proxy, that's more like a gateway class, it's not right. There's. Obviously, api impedance between the two right now with site gateway, class, normally being a cluster-wide crd, but I don't think that's gonna hold.

A

But some of the inter interception mechanisms that we have inside cars do you think it applies to gateways if they're running in standalone mode, because that's what it feels like gateway is currently target right.

B

J

Gateway has the right, as people have mentioned, most of what getsidecar is used is for dependency, pruning gateway can express gateway, can express that uh the other thing is capture. I think a gateway can also express that with its uh address type. So between those two things I think we're okay to allow gateway to replace sidecar. For you know what customers describing is white box mode right.

J

So then proxy config is relevant for both gateway and sidecar use cases, gateway, class and proxy config have a similar conceptual model, but there are some structural issues today that we need to resolve.

C

I said, but in practical terms, uh creating a crdn with a most conservative set of fields that are currently not duplicated and not confusing, and promoting this uh you know from from alpha to beta, uh should be you know reasonable. At this point, I think it's not.

J

C

J

A reasonable answer for how gateway class and proxy are going to relate. I think, then we have a a reasonable answer. Overall.

C

And the the the vendor extensions are supported by the kubernetes. I mean I I'm concerned about the visibility rules because we want to have them in kubernetes as well. So a particular subset of this kind of proxy config probably will be overlapping. I think, but I don't know any if.

A

We move it if we move.

C

It from sidecar.

A

To proxy so let's.

J

A

That right, right.

J

So this gateway gateway, custom gateway will be able to reference service right directly. Yes, so that is a visibility. Rule a means to express the same visibility, rule capability.

C

True, but in in in the mesh side we, I don't think we solve this problem, I mean how I mean. I think the current proposals do not have a gateway for uh for each workload.

J

What's the default.

C

Yeah, I'm okay to to keep to not move it. Now I mean, let's just start with the rest and because peop is not adding any cut, particular or shaky. I mean it's it's. We already have a way to put it in cycle and we can postpone it for next release. Work later to move the visibility.

C

A

C

A

Another good question here is then: do we want a new crd if, eventually something else is coming along to replace it right, and I know we have talked about it for a long time, but this might be again a good time to bring it up.

H

I

Don't think the gateway will ever fully replace this. I mean these are easter, specific things, so it's never going to be a kubernetes area that says discovery address. For example, now there may be a new.

H

Api that references.

I

Proxy config, but we don't need the resource and I'm I don't have my hopes up- that proxy will ever actually replace this. So I don't want to install forever um gateway class. I think, is fairly flawed with the.

D

C

Yeah templates for initiation controlling injections are all kind of fields that are very specific to these two implementation and.

J

Yeah, no, I I I would just like to have an answer about how we expect gateway class and proxy config to work together.

J

um Hopefully, gateway class gives up on being a concrete type and becomes a controller interpreted type reference. That would be better correct. John yeah.

I

Yeah, that would be my preference, and that seems possibly the direction things are going.

C

We kind of do have an answer because proxy config is in broad use and we are using it currently with gate. I mean it's, it's it's just internal and alpha. It's not uh nothing changes. Basically, we keep compatibility with exactly what we have today until we have to change it.

G

So so the difference is that, right now, proxy config is either directly workload bound or mesh bound through mesh config default config and now we're just aligning it aligning it with all the other apis. So yes,.

C

And and- and the main reason is I mean the reason one is to have validation and also you know consistent with the rest of the apis, but also an important use case that mirage mentioned information is a dock. If you have programmatic creation of pods, the current mechanisms of putting annotation doesn't work because it requires changes. The code and having a crd with selector would allow us to configure those use cases.

C

For internal things that are not necessarily pods where you can put an.

A

A

So I mean from what I can uh see it feels like proxy config crd might be a good choice here, naming we will have to bike share a bit just because these all things sound similar, and it should be clear to the user uh for moving the config pruning pieces from sidecar to proxy config. It doesn't look like we have consensus, but I do want to talk more about it.

A

Current, if we add proxyconfig as a separate crd, and still we don't move the config pruning configuration, we will have to have users now configure two things. Instead of one.

J

Well, do most users right, we we're still going to have a global default for proxy config, correct.

H

Yeah and outbound traffic is a good example for that right, so they're going to need to config mobile one for that and if they need to overwrite, they would have to they could use proxy config for workload or they could.

J

So what is there a different form of config pruning that we expect to have other than referencing a list of services through routes.

J

Or the third option, right, where services are there, their visibility is declared at the inverted level and.

C

Can the proposal we have, I am driving this, I mean harvard rules and other things derive it from there, which is still debated.

J

Or derive it from network policy.

A

I mean the last two options, basically are interesting, but don't ex I mean the last option is if the user has created those policies, but if they have not, they still might want graphic pruning right. So we will need to have a fallback. uh The third option about service annotations is it being frozen in kubernetes. Now.

J

It's come up, it hasn't gotten direction yet.

A

Yeah, when you see annotations, do you really mean annotations, or do you just mean decorations via some other seconds.

J

The ability to it so the one thing that is getting traction is the standardization of policy attachment to different resources in the model. One of those policies could be visibility right and therefore you could do policy attachment that way.

C

um And and the other tools whenever policy- and I am are back- are nice because they they- you know it's it's. The user sets something that is enforceable.

A

Right so I.

C

B

That's an optimization.

A

C

What security techniques, I would say, but yeah optimization.

A

Right I mean you have already told us who you want to talk to, so why will we send you conflict more than that.

C

C

So can we move ahead with at least the bare bone and then have individual discussions for visibility? I mean, as we get more data, so we don't get stuck in alpha.

A

I would like to know more about that, just because.

A

It's weird to now ask users to configure multiple things. I'm just saying it's going to be confusing.

C

Sure, but we can, we can create the crd. Put all the infrastructure in place write the code with the bare bone that is currently exist. That means there is no change just alpha to beta and in parallel work on on individual fields that we may want to promote the most.

C

Incremental progress, basically.

H

So I think it's reasonable to create proxy config to have the fields that not conflict with anything inside cycle resource right like the discovery, selector hold the application, and here app ready. I mean these are not covered inside car, so there's no contention so those are seems reasonable.

H

I think people definitely are worried about if they are also in psycho resource so which way is user going to do and how are we going to resolve conflict? So I'm not sure on those.

C

Sure I mean, let's separate the problem alpha promotion to beta for things that are spread across her sink and solve this problem. First, maybe, and then how to optimize other things. Nothing that I'm proposing in in this is new or doesn't exist. It's just fields that are all fine different places and are not configurable with the right.

J

All right, so I think I think, I'm okay with that, the only structural thing with the api that needs to be resolved before we do, that is proxy configuring gateway class, because we don't want to create structural impedance mismatch when and if we make a transition from sidecar api to gamer api, which will happen within this timeline.

J

J

There's certainly no reason in the long run for sitecar api not to be deprecated with the existence of this and the gateway api right because gateway api to like extend your question about semantic uh swim lanes. Gateway api is very clearly traffic, routing and traffic capture, so that would that isn't going to change so there's a very clear division of capabilities and requirements between the two apis.

J

Proxy config and gateway will have to coexist right, so we have to figure out how they co-exist and gateway. Class is interesting because gateway class doesn't have a workload selector right and so the gateway use case.

J

In particular, we have to decide between whether we want proxy config, selecting gateway, workloads or gateway classes are selected by gateways, either directly or indirectly.

J

That has to be resolved, because it's a structural concern now that gets resolved john, I think, if gateway class is allowed to be synthetic, it doesn't if it's.

J

J

Does that sound right to everybody, or at least specifically.

A

J

Is spending the most time on this.

A

Before he jumps in, how would you define the configurations, that's housed in gateway classes, and why do you think they map well to proxy contract.

J

They're, generally speaking, runtime behaviors of the gateway instance that are being described right now, whether you know for any given implementation, you might say: well here's how many instances I want or how much cpu or resources right, so things that look like injection.

J

There are also policies right about the behavior of the gateway right. It's it's very open-ended, but it's not traffic related. So it's everything but traffic, that's being described.

A

I see so we interestingly be able to use this guidance right as in future, where which config belongs, then.

J

Right so like proxy config right is everything but traffic. For the same reason,.

J

So the gateway class and proxy configure logically the same thing.

A

We didn't follow it like that, but yeah. I think we did deviate few times.

J

Right and if we're going to put a workload selector into proxy config, then we have to reconcile with how gaming class is bound now for mesh. I think that's easy for actual gateways. It's a little harder.

J

We need a clear answer.

C

So we need to figure out. How do we attach? I mean if we continue to use workload selector for attachment, or do we use the reference basically in proxy config. That's a fundamental question.

J

Right, yeah, why why would you allow overlapping selector on on gateway instances right things like that.

C

So an alternative will be something like like the canonical service or or some other form of reference that can be referenced uh or.

J

You can just literally reference a proxy config resource as the gateway class, which is the.

C

Thing but one use case is you have an unmodified port and the port starts up. You cannot you reference from what I mean. It's no.

J

No, for apologies. I think it's fine right. You need the workflow selector. I agree with that yep. I think the the issue only arises on actual gateways.

K

C

So I I understand your your concern here.

C

So we may need something in addition to our reserve. Consolidatory is needed anyway for pods, but but we may need something else to okay.

J

And so that, then, the other thing, the default proxy config is a reference resource out of mesh config.

G

Right now, yeah.

J

Okay, that seems reasonable.

J

And referenced are not inlined.

A

Correct, uh currently, it's in line right.

J

Well, we would have to stop doing that right, so we should otherwise why? If you have you have the same api twice and when you make mesh config into a sierra video.

A

I I I get it it's. I don't know how the deprecation path here works. That's a lot of children on users, okay,.

J

Look at look, I I get that we can't do that overnight.

J

But cost an art is the intense to make those two schemas agree completely.

C

We are flexible for the as long as we remove the alpha and achieve the goals, I'm open to any suggestion.

J

All right! Well, you have to include that in your plan right what the intent is to do.

C

With I mean my intent was to to to just deprecate, everything, mischief remains alpha and will gradually die and proxy config will be the ones that, just you know, complete separate resource. I mean config is moving to kind of operators, managing history and and.

J

Mesh config becomes trivially small, like that's fine um proxy config. Should that doesn't mean that proxy config should take over everything that mesh convict did correct. Absolutely.

J

There are still like things that dictate the behavior of the control plane.

A

Yeah, do they need to refer at all.

J

Well, if proxy config is inline and mesh config right, which do we consider the the resource for revisions.

C

The proposal is, if you, if it is in line- and there is no explicit crd, then we use exactly backup mobility mode. If user is starting to creating an explicit crds, then we we ignore the alpha stuff and because user you know implicitly opted into beta.

J

Right but that doesn't mean that we ignore mesh, conveying.

C

No, no, the mesh config except I mean the proxy config inside mesh config- will be ignored in this case, because again we want the validation and all the other stuff. uh We may keep it for backward whatever transition or other thing. That means that's, that's movement, but in the end we want to be in a state where there is no proximately image conflict, because.

J

Okay, so if this proposal saying that we're going to take proxy configurator mesh, config yep, gradually slowly, okay and you're, saying it both exist in this new system- name space- we're going to take proxy connect by default, yep right as the system system-wide default yep, um our general pattern has been for control plane, wide defaults. They would become referenced resources out of mesh config, because mesh connect still represents the root configuration for a given control. Plane instance correct.

E

J

So and what remains in mesh config once you do that.

C

And once we move to beta, that's the other steps. Well,.

J

Sure, right and mesh config is not even a crd, exactly.

J

So the document needs to like just explain: what's going to happen for that.

C

Okay, I can take a stop at this. It's not, um it may be controversial, but at least we can discuss it.

H

Yeah so just make sure we're on the same page. So basically mesh config is per revision right. So there are configuration, that's control, plane, specific, like ca address, it's going to be unique for different revisions, so you could have your own match, config from 110 to 111, but proxy config. The customer ratios that's going to be created, it's going to be global across different revisions on the cluster. Is that how yes? Okay,.

C

But like like all other gateway and and all the other stations and everything else,.

J

All right, so it's revision, independent.

C

Yeah, it is also kind of becoming revision independent with the option we added, where we're gonna have a mesh config, that is user, managed, which is cross revisions which is merged with developer. Okay,.

J

um Yeah john I'm not actually trying to mesh config beta to proxy config data. I just want to have a basic understanding of what we expect the evolution path to be rather do the work right. So just, but I just want to see the design part.

A

um One more request from me about sorry lewis, very good.

J

Yeah, so the only special thing here, obviously, is the global default still being tied into mesh config right.

J

Can still cause a big shift in which proxy config is bound for a workload when you do revision, traversal, which is okay, because that's the same for other resources. But uh it's just. It's gonna be important to make that clear to people.

C

But do you have strong opposition to the proposal grant proposal to just say if you have the better resource, better resources in charge, otherwise we fall back to legacy and use legacy. One.

J

I I would prefer that we had an explicit resource reference out of mesh config, but I don't have a specific objection to that as a transition path. Okay,.

C

So when mesh config moves to beta, if it moves to beta, then we definitely will add the reference and- and uh that actually is a pretty good idea for.

J

Well, I think you're going to want the reference anyway, even if you're not moving this config data, I see so we.

C

Can I see so basically, each revision would have a different default yeah. Actually, that's not a bad idea. That's that's! We can do that. That's that's.

A

Where I was going like, aren't we aren't the users losing things because proxy config is no longer virgin diet.

A

If we do what luigi just said, we will still support that. Yes, yes, and- and I agree with what I mean- yes, that's something we should add.

C

To the document and make it happen.

J

J

Her namespace proxyconfig instances can select on labels right that could be tied to revisions if people really wanted to do that all the way down at the leaf level.

C

And that's something we support, so that was my original uh thinking that we use the east ui referendum put on every label, including destination rule and whatever to make it bound to a revision.

C

It's something only people know about, but but it exists.

C

And I agree it's not, it does and it's not what kubernetes thinks also. So I agree that we should probably consider replacing this with the explicit references in the in the nuke versus api model.

C

But it's a kind of orthogonal discussion.

A

So good question here so do we want to continue down the path of history or rev levels on any custom resources, or is that gonna be a thing that only three people know and no one else uses.

C

uh It's for advanced users for sure the question is: if we, if we, if we're going to replace it with what uh the attachment policy, the quality attachment model that we mentioned, and I think we should by.

A

Costing the issue the issue is, we will have two things, two ways of doing things again,.

A

All right, because we can't remove the other one. I.

C

Agree, that's reality of kubernetes api. We're adopting, I mean, will be a broad in that you know vendor neutral way to do things, and- and so this just specific way, that's we cannot ask other vendors to use ui.

A

I mean kubernetes have been doing drafts forever, it's not new, but yeah, so we should then deprecate the other. Eventually we should deprecate stew ira. Is that what you and me is also proposing or not.

C

Yes, it is what I'm proposing just like we're proposing replicating side current when kubernetes replacement is the one or or the beta or not. Now,.

H

But not for, but not for injector right. This is only to deprecate the annotation. uh It's still resources. Yes,.

H

L

You know, I hope user.

H

Doesn't have to use that annotation, it's really really complicated.

C

And but for some reason it's unavoidable, I mean it's if it's a new feature that is only supported in a particular I mean that said, you know, like employee filter, it's kind of you cannot avoid it in some cases.

A

Okay, I think we did have a good discussion on this. We have one more topic. Are these questions captured here good uh for you to question. I think the ask will be to get answers for this in the document and fingers either asynchronously or bring it back to poc.

C

Okay, and and and to be clear, uh we can go ahead with with creating the beta proto hidden from from api and, and you know, read it and make the code changes while we are in parallel addressing the other cases, because 111 is around the corner and probably to not be finished 111, but at least we I I like to have some progress.

G

Made so so so what my my one last comment is that if we can get some directional sense quickly about whether this is going to land 11 or not it, it will be very helpful. So um if, if I guess, if cost team gets these answers in a week, I think we should still try to have this approval by next week.

G

A

Okay, these- this is pretty impactful.

H

A

By the way I mean we have tend to in history, split up upgrades, and this will be one of those things, if not done correctly, so I would rather take some time to it the proper properly. Even if he's kept.

C

One level, so I I I thought a bit about this uh this and in 111.

C

I think what the most important thing for when you learn from my perspective, is to just go over all fields in proxy, contains existing proxy config and put documentation, saying, hey, zcld is going to be part of the beta api and, and you can rely on it and this field is you know, deprecated or hidden or or you should not rely on it and that that will be impactful for users, because at least they'll have clarity of what exactly will be supported, and if we have agreement on some fields, uh they can make some decisions based on that and then transition will be easier.

C

I don't expect people to start using ucrd111. I mean, I think, if they just keep using the annotation I'll, be very happy.

H

So should we start with data, I'm sorry alpha 1111.

C

H

Is going to be a new api, these things are just claimed data.

C

Alpha with the quick comments indicating the stability of the field, saying that this field is going to be promoted or I don't know how we can express it, I was thinking to have a better crd. I don't know the proto proto, at least with the cleaned up version, but people who want to use other api with the fields that are documented as better.

C

At least that was my my simplest plan to to to make progress and- and uh you know, provide somebody to use this.

C

A

I'm good with that. How about others.

J

I mean if we're gonna spread across two releases. That certainly seems I mean really what we're shipping in 111 is dark right.

C

Yeah, how can some fields move from from you know, values of camera and other places in the proxy, because that's that's part of this discussion like proxy resources and.

I

With gossip just to clarify so in 111, we will not create a new theory.

E

We might I want the proto.

C

To be created, we create a cfd. This is, uh if we have all the elements in place, that's fine, but we'll not promote it or or tell people to start using it.

J

As far as users are concerned, we're not creating a new series, we're not.

C

J

So we're not going to create an alpha security.

F

C

A proto yes, but I don't think uh even if we created segmentation as part of 112 work kind of uh to spread. The word no will not be documented. Basically we're not documenting 111 that you can use this new resource until we have, and it gives us more practice and more feedback from users on on how they feel about that.

I

I'm a bit confused. What is having proto do if we don't have a crd, yeah.

C

So uh you know, first of all, clarity on what fields are supported or not. Second, moving the other fields that are now in values.yaml into proxy config and again, I'm not against adding the proxy proxy crd is just I don't know if you have time to do it right and- and I would rather you know, I'm okay to have the crd and some code that is using the crd. So we can test and if it's perfectly working then we'll document it. But I do not want to commit for 111 do to the entire thing.

J

So I guess custom the the difference between having the api and recommending the use of the api right. We could have the api in experimental.

C

J

um With all the schematization and everything that you're describing.

J

The difference between that and 112 would be migration tooling and upgrade support for users between those two states. Yes, implementing the crd itself is not particularly difficult. Implementing the migration is the much harder thing is that what you're suggesting we try and do for 111, or is that yes, the more reasonable right? So it's we do have a crd.

J

It is experimental, uh beta, experimental.

A

What's beta experiment.

J

C

J

C

Yeah, I was joking, no I I meant I met, uh we have the crd, but we are not yet promoting domenting it us, please use it or start using. It is just we say that it's working progress and uh right. I.

J

Mean that's what experimental means.

C

Yep, which is reality, I mean it's brand new, just added pressure out of the oven.

J

Right so the the only thing where one question there is: what do we want to be alpha, because we want to progress it to beta very quickly.

C

Alpha two is twenty: we can do alpha 2.

J

What do you think's, then.

J

Normally, if we don't want users to use it, we would probably keep it experimental, but it sounds like we're in something of a hybrid here.

F

Yeah, I don't know, I might, I think it's fine to do it in experimental or even alpha honestly, um because those are that's what those are for. I agree. We should not go straight to beta, but.

F

I don't have a strong opinion on verbs on experimental versus alpha for 111.

C

Well, it is already alpha, it can be a lot too. I mean roxy configured. We well.

F

C

F

C

Well, you know, the content is what matters and right.

F

Right but so still, if you produce the crd, you should not use a direct debate.

L

G

Question is what what what is the exact kind of feedback that you're looking for, because the shape the general shape is in use today, the uh the override structure is also in use today, sans sort of the name space scoping, which is missing. We have a mesh scope and a workflow scope, so that is not changing, and then the thing that is happening is a cleanup of fields that have just accumulated.

G

uh So I I'm working like what kind of feedback will like. Are we looking from users here?

G

It's not really a new api.

A

For me, I'm making sure that the upgrades actually work and if, if you're saying it's a better quality api, then the migration upgrade better be spot on. If you make it uh alpha experimental, I think we can have some mishaps along the way.

C

Do you even know if the api structure.

I

Yeah, it seems like adding it as alpha doesn't really do anything like. It seems obvious that an api should go alpha. Beta, stable and skipping levels is wrong, but that's because that's how other projects are able to do it because they have proper versioning, but for us we can't change it anyways. So if we ship it as alpha, it might as well be called beta, because we can't remove any of the fields when we promote it anyways. So is there really any benefits.

F

I think that's true today that doesn't mean that's the long-term state of the project right. We want to fix that.

I

I don't think we'll fix it before we go to beta for proxy config, though.

J

That's probably change yeah.

J

But john, we are able to have the same api in both alpha and beta right that we are capable of doing infrastructurally.

F

J

As you know, we can't remove.

K

F

If we add it in output and we have to remove it from the alpha to remove it,.

J

F

J

C

Hide it from docs. That's.

J

What we do yeah.

I

And that doesn't mean you can even do that. Actually, the schema has to be identical, like fight for bite, identical.

C

And not only is that, but if people start using alpha because they have cross versions because they want to use it 111, they will put alpha level and you'll be stuck with alpha level forever, because well not forever. For six three releases, basically for two releases.

A

Currently, right.

K

Yes, we also should have clear communication to users, while apis can be available as both alpha api and beta api according to kubernetes schema. Our support for the feature probably should not be described as both alpha and beta.

K

C

J

Yeah, I mean literally, the only thing we can do today between alpha and beta is hide things from docs if we actually built the feature to do that um which we haven't built in many ways, that's already aligned with our well, it's not quite aligned with our deprecation goals, as we would like to deprecate api alpha. Api features faster, but.

C

J

Okay, paying ischemic compatibility cost, even if at runtime we drop support for fields.

J

And hide them from docs.

J

As long as we're comfortable with the shield right the basic structure of the api and don't make large structural changes, which it doesn't sound like we have that problem here,.

C

How about next week we we we discuss again briefly to figure out, I mean, let me update the doc and answer those questions.

J

B

Yeah yeah. That sounds like.

J

Maybe pink people online, so we get the the review sped up a bit.

C

Because if we all right, if it answers the problem itself, because you will not be able to have time to do it in 111, so it's.

A

Yeah and thanks for the dog I mean it's, it's a lot of fields that you have to look at right.

B

uh Lynn, what are you saying something sorry.

H

No, I was just going to thank you.

A

Yeah well, we have five minutes. So let's discuss brian's topic. I hope it's a quick one. uh Brian do you want to talk about it.

L

Yeah, so this is quick. um I've gotten requests from people to be able to use the release, notes, tooling and um separate projects without actually pulling in um the entire tools repo. So the only question here is for permission to create a separate repo, we've already discussed it in test release.

J

Is it do we expect the repo to just be for release notes or what other things also go in there, or could they if they were release related artifacts.

L

It's just related, it's just supposed to be the relates notes, tooling,.

J

All right, so we wouldn't put shaz or things like that in this no yep is that correct. Does that make sense? Is that right? There are other release related artifacts. I don't want to have release, notes and then release shaz and then release xxx.

L

So this is the tooling so that um you can pull the actual. So we've we've got the the tool that creates the release. Notes takes all of the files and it generates release. Notes from that, and the request here is um to be able to pull in that um uh tooling without putting in the um rest of the tools repo. So it's only for the uh command itself. Oh.

J

It's for the tool: okay,.

H

Okay, so just making sure so when people submit a pr to istio istio, if it has changes if it needs to add something to the release notes, the pr student needs to check in the release notes file in the release, don't stir so that process remains unchanged. Even when we move okay, I'm good.

J

Can we can we just call it release, notes, tool and or something to indicate um it confused me yeah.

H

That would be good.

F

um Can you explain what what problem this is solving, so what? What is it about pulling in the whole thing that was causing problems? Why do we need to do this, so this is just because.

K

F

Sorry continue. Sorry, I was just saying generally don't like to create a lot of repos, so we should. I want to understand why.

L

Yeah, so this was specifically a request from steve dake. um He likes the seo release, notes tooling. He wants to be able to use it in his project that he's working on now, but he doesn't want to pull in all the seo tools to be able to do it.

L

So I was supposing it to a separate repo under the istu organization.

F

That doesn't seem like a good reason to do it. Yeah.

H

F

H

You know honor, is your community.

I

Yeah just compile the binary like. If I go, I don't I don't get upset when kind adds dependencies, because we just we don't have a go dependence on them. We just use their binary right same with cube, cuddle or hundreds of other tools. It doesn't seem reasonable to expect that we have small dependencies for a binary tool.

G

J

To do this, for kind of internal reasons to the project which you know if they were getting, that would have been.

J

Fine okay decision is nope yep that works for.

A

A

All right, this was indeed quick.

A

Thanks, yeah anything else. We have just one minute: if not, let's take one minute back.

J

Let's take another pack, all right sounds.

F

A

Yeah yeah thanks everybody.

F

F

F