Kubernetes SIG Testing, 2 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sig-Testing Weekly Meeting for 20230502

Description

Sig-Testing Weekly Meeting for 20230502

A

B

I guess we can go ahead.

A

And get started.

A

um Welcome everyone I'm Brady.

A

This should be a short and quick meeting. It looks like we have one main agenda item and Jack. If you'd like to introduce yourself, we can go ahead and jump into that.

B

Great yep thanks Brady um I'm, Jack, Francis I'm, coming to you from sincluster lifecycle, primarily I work in cluster API and capsi in particular, for Microsoft, and we have been I've, been working with the various cloud provider, communities tracking the cap that will set I'm, not sure the scope of the camp is not going to completely remove it's called phase, four, all right. So for folks who are unaware, the the emergence of out of tree clap writers and the deprecation of Entry providers is almost like a decades-long effort.

B

So it's been amazing to finally see this, make progress and we're at the point now where um Upstream kubernetes is going to be disabling, the feature flag that allows entry, which is something that was introduced a bunch of releases ago.

B

um It's going to default that to uh to to it's going to default it to True, which is a disable um entry provider. So essentially a vanilla kubernetes cluster that is created with 128 will not permit entry cloud provider by default. Does anyone have any I know we're just a few folks? But do we have any questions about what I mean by entry versus out of tree? Is that clear.

A

um I'm not super familiar if you have a brief overview, but I also don't want to derail so no.

B

It's okay, I can I can definitely be brief, so so, essentially um original kubernetes, the some of the main clouds uh Google Azure Amazon and some others integrated um providers for infra directly into the Upstream kubernetes code base. So it's it's in the actual KK. If you look at the source tree, you'll see it in there, um which meant that the uh you know positives the the release Cadence for those was integrated with kubernetes, and so as development went forward in time.

B

Cloud providers sort of went forward in time at the same rate um and then eventually, as you can imagine, uh the the the Divergence in sort of feature velocity from core kubernetes and then the actual Cloud providers themselves um made that type coupling not ideal, and so now all of the main Cloud providers are in their own projects and they release according to their own release. Cadence.

B

So you know, there's no such thing at least going forward as like a gke Google gcp cloud provider that is 127 specific, like tightly coupled to 127., um there's some like plus minus version support, but essentially the auditory independent cloud provider.

B

Projects now have their own release, Cadence and and version requirements, and all that kind of thing, and so that's now becoming the the requirement with with this PR, you will have to explicitly feature gate, enable um entry provider to use the Legacy code, and one of the outcomes of this effort is that the the entry code bases for for all the the cloud printers that are there do have Legacy code.

B

So over time, that code has become less and less frequently patched, certainly uh for features, but also for bug, fixes and all that kind of thing. So it's not code that folks should be using so um I'll paste, a PR Link in chat, uh dims's cap that is going to do that disable by default.

B

So that background being said um strictly speaking, because we, the Intrigue collaborator, is still a a quote, unquote supported feature: it's still possible for users who explicitly opt out of that feature flag when they create their kubernetes cluster. When they configure their components, they will use the entry prep writer and we don't have any test end-to-end test signal for that once that PR emerges.

B

So the open question is: what is the plan? I? Don't think we have a plan, so we're going to come up with what I think so from the from the Azure side, it's fairly trivial for uh the cap, Z team capsi is the Azure provider for cluster API. It's fairly easy for us to produce um uh testing for job that would create an Azure specific cluster using the entry we've been doing it all up until this you know very recently till that PR.

B

So we can just insert that configuration back into capsie and create a testing for job um I. Think we can do that at fairly minimal cost. We can talk about the periodicity of that job or maybe make it just a pre-submit running against, like particular changes to the entry, but at least we'll have some kind of coverage. So the the question really is: how sufficient is that to cover the full end-to-end scenario?

B

Any does that make sense? Well everything I'm saying.

B

We can also not do the Azure store. We can do something else, um but I think that's something. I can confidently uh propose and we can do that at least as a first step up until this point there, if you, if you like, are integrating a kubernetes, PR you'll notice that if you do like a test, question mark or whatever slash test, question mark you'll have access to literally dozens of different end-to-end scenarios, and those are all now running out of tree.

B

So we can't practically like Fork all those scenarios and make entry equivalents, but I I think uh having zero test coverage is probably not great. So, where like, where do we practically sort of want to Aspire toward in terms of supporting this feature flag scenario for the next several releases, cool I? Don't either my best idea is I kind of know how to do this. I can just do it for cap Z and um we can see how that goes for the next release cycle.

B

I'll, definitely check back with the folks who pay for these clusters, but I. Don't think that it'll be too much spends. I think it should be pretty non-controversial foreign.

A

Agree with Michelle it makes sense, but as far as moving forward um it does seem like a bit more complex of a an answer to who would make the decision? I guess um you could probably reach out on slack to dims or or Benjamin, or um those would probably be the best I guess, uh and they may have more concrete opinions on on which way you should go, though,.

B

Yeah for sure I, so I know them a little bit so um I thought best be to just show up here and get this. You know unrecorded video and if anybody has any chat, I mean that's so adorable. Thank you for that um uh yeah and then I'll I'll. Just let them know that I presented the sort of background and a possible solution and see what they think um and if, if I am continually continuing to be involved in this I'll pop my head back in here and let folks know, what's going on.

A

Yeah, thank you for the overview. This is great.

A

We have any questions, I, don't think so.

B

Yeah I think that was a good explanation but, like I said I, it's an interesting question of how cupboard should work going forward.

B

Yeah, there's probably some stuff that doesn't have any coverage, but I don't want to go on record as proposing that it's copying that whatever model there is out there for that I'm gonna say: let's do better a lot per capacity of the a carrot we'll see.

A

Okay, um that is the only agenda item we have today. uh Unless Vladimir has anything that I think uh we can start wrapping it up. It's nice to see you, um okay, everyone I think that was a nice short meeting. You can have the rest of your lunch time back. I hope everyone has a nice afternoon yeah. Thank you. Thank.

B

You bye thanks.