Kubernetes API Machinery Special Interest Group, 29 Mar 2017

Previous Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG API Machinery 20170329

Description

Bi-weekly SIG API Machinery meeting

A

B

B

That's a good turnout for being cute Gunn.

B

Who is mr. Cooper netting API? Machinery is obviously not Daniel.

C

Was not me hey, this is Cameron's a hidden, the guy that's been emailing y'all about all the zoom updates and meeting updates, and things like that. You know. I have to sign it as the official account for now to make sure that I get the video recorded, so I can upload it eventually. Ideally somebody else wants to, or we can maybe rotate through somebody else's signing. It is the official account recording the video.

D

We're trying to.

E

F

You something something that's.

B

A

D

Hold on I need to I know. It is very okay.

G

Sorry that my camera is pointed at me, there's other people in the room with me.

D

Let's see, let me find you find the document, so my agenda document I.

D

Have too many tabs I.

H

Just post it in the comments or in the chat.

I

E

Yeah I haven't sure I guess I should probably should share my.

A

G

Is that working so yeah.

C

I can see your screen. Okay,.

J

Do you see my whole screen.

G

Okay, I see it highlights it and okay, okay, cool all right, then I think we're in business needs you, man, a little.

D

D

J

I

On the on the agenda, I had the several several of the proposal.

J

Docs that I had put out and I think if we have time at the end, Phil wanted to show us some of the.

D

User-Facing stuff that he's been looking one he's our face: Michelle over.

G

Every coach anything else that.

I

Anyone wants to talk about I.

K

Didn't want to ask about thinking the repos have what we were gonna do not that we've got a one-sixth tagger. Are we trying to think tagged out or tagged across repos for people who are trying to pull those in on other projects? So we couldn't add it. That's the end. Yeah.

G

So we started the at the at the top ten so uh week or two ago, Medi sent around a proposal for like what is what does it take to get a new client language in a library, a new client language, Mosul sort of sets out? What what do we expect to various support levels for a client there would expect for a table with levels. What does it take to have a have a stable client.

G

We sort of split it into like bronze silver gold and alpha beta is stable, so yeah idea I'd like to have a bronze client. Basically all you have to do is be able to get some call to work somewhere, but that means you know a file.

D

And parse the stuff sends the auth stuff over the wire, so you can just any standard. Rest call should work for silver requirements. We.

G

Wanted to add, like you, should be at least you a watch for gold requirements. You should be able to additionally issue the exact attach port forward, those the the stuffs that we've implemented with speedy.

G

You should also do proto encoding, and you should generate examples.

G

So it makes sense to everybody, so it seemed like the right breakdown.

G

I'll, take that as a yes yeah.

H

I had a quick question on the exact exact, isn't, particularly the actual protocol for doing an exact, isn't particularly documented anywhere is that is that.

J

L

G

Running off of my laptop by the way, so people won't be able to hear you if you're not located close yeah, we're speaking roughly so and then then like as sort of mostly orthogonal issue. We define like alpha beta, stable for clients, so alpha clients, you know whatever knock yourself out, doesn't really matter for beta clients. You should at least implement the the bronze global support.

G

Your releases shouldn't, like you know, are MRF my machine. You should have some sort of instructions, so people can try it and it would be nice if you had two or more maintainer of the repository. So if someone gets hit by a bus like keep on going and stable, we want all that plus good documentation. Have a deprecation policy document. Your versioning procedure document your release process and actually have a few users.

M

One more thing occurred to me this morning: yeah.

L

M

Is it you ever tried to build any use for macaroons?

M

G

Someone talking yeah Brian is asking about running our clients on Mac or Windows.

B

Here anyone is.

G

Suggesting that the clients should be buildable on Macintosh.

G

What's the sense of people out there, do we want to define like platforms that that the clients work on.

B

Or I, don't really think that should be a requirement. I mean I. Do wonder about I, don't think I have a stable client that didn't support. Watch calls right, I, don't think. That's a client.

K

B

Is unlikely to change right, given how critical watches are to our overall logic flows and, presumably to the one else, is trying to use the client as well.

F

B

Your client doesn't support the watch. Can you really be confident that you are not going to have a break to support it, watches in the silver requirements which are not listed as a requirement for stable, nor they.

L

I think stable names, community, okay,.

B

Good then I, agree I, think it needs to be silver I, don't think it needs to be gold, because I can imagine lots of use cases that don't require exact attached work forward, they're useful, where those are pretty specific. Well.

G

I don't know I think you could have a stable client. That is extremely simple, and only if the bronze requirements table doesn't mean, but you never change it. It means that you have a user separate, reasonable expectations about how you will change it.

G

Right staple doesn't mean that it's like caste and like it.

L

Means that that users can rely on your deprecation policy I.

I

Mean these are, these are libraries not.

G

We probably should say something about platform, because otherwise people will add on like incompatible extensions, but it like the thing that we care about is.

M

G

M

Which pages work yeah sure just work with our building refused me, but general clients are more I, think lose their other parts of the system. Clients are more likely to use. That's true. You control a list.

F

Of we read for.

M

Sure no yeah yeah.

D

This is not about cute control.

M

B

It made a dial.

K

The battle every minute, it's really hard to hear anyone talking yeah.

B

I can't even tell whether I can talk or not I'm.

G

Sorry I can't do anything about that.

F

You know Sarah has a microphone.

G

K

G

We're now should we take as an action item to.

L

Add something about platform I couldn't.

B

Really hear that part of the discussion, my immediate thought is that, if someone wants to have their client must have a stable client and doesn't support Windows.

K

B

Doesn't want to support Mac OS I. Don't see that as something that was talking for being stable, maybe.

G

We should just define, like the client as per platform,.

G

Maybe maybe we should say that you can state your support level for each platform. Yeah.

K

Does that make sense, and again these are libraries, so, like your library supports some set of platforms, you have to state that I didn't a proto discussed. Maybe I missed it. Yeah.

B

Proto was listed as a gold requirement.

B

It should definitely not be a lower level requirement.

G

Okay, so I added support level documented per platform under.

L

G

Debbie, that's probably.

A

I

Proto is listed under gold requirements.

I

Yes, so, given this I think our current go client is closed.

G

Meeting the stable level, but not quite there and.

B

It would be silver gold.

B

As I recall, we don't support exec.

I

You know, that's, is that not is that only it is that only within control, I think.

N

It's mix, we have some parts, a client and some are in queue.

O

B

O

Sure that the revoke command.

B

Package is not inside a Clank. Oh.

G

Okay, we should probably adjust that, let's see so, can you hear me we just switched Michael I can.

B

Hear you just Brian once I talk, testing.

C

K

Much better still.

B

O

B

A lot better yeah.

G

J

P

We need hear me right.

K

P

G

We we adjusted, we added a bit about what did I add for for stable clients. We said document your your support level per platform that seemed at least think their.

O

Main time oh yeah.

G

Yeah we can, we can expand that when we get more users. Okay, does anybody have any objections to just approving that document?.

F

J

K

There are a couple up in questions about the cubic and big stuff and but I mean I, don't have an objection to taking business or starting.

F

K

It once it'll be painful to evolve it once you have people in the different buckets and then we decide. Oh, you know what this thing actually should be in a different bucket. That's gonna be pretty tough.

L

L

B

Didn't specifically highlight it, but this also describes breaking apart the client repo in two pieces, I'm in favor of it, but I wouldn't want to surprise anyone. Okay,.

G

I can realize you'd updated this document that.

B

Wasn't me I, didn't think.

F

B

L

K

P

G

We're still not convinced that our microphone is working.

B

Anyone I'm in favor of this I just want to call it out because we can go over here. This was our client Riesling two pieces, one that maintains not pipe specific pieces and one that has clients for the particular types. So one would be something like a schema list rest plant and the other would be like this client can work with pods and with extensions and it's a distinction. I think we need to be able to build pieces on top of it.

B

But if we agree to this proposal, we've agreed to that and I'm in favor, okay.

M

The document, but also just using you know, separate github work for all the clients. Yes, that is in the document.

G

Thanks both here and deal yeah, this goes here and the other one. Okay, so so it seems like people are generally in favor this this document we can clean up remaining things. We converted markdown.

G

Let's talk about the other document, one thing at a time I think this. This one is less controversial: okay, I'm gonna, write more or less approved.

G

Okay, so moving on the next thing that I had written up is like an overall client structure, and so the basic idea here was just a factor where we store what so we just to sum up for anyone who didn't read it we're promoting the split to make a kubernetes client github repo, take all of our generators, put it into a Gen 3, both sorry everybody's client, org, taking all of our generators, including the go and the swagger generators, and putting that into a gen repo there and then I had a proposal to split the her language clients into you, two or more repos each one, repo for utility functions and like yeah yeah.

G

What did I say here like transport rest, client, work, you and former dynamic. Just every client still be function says what will go, make a client that doesn't require me budget yeah stuff that doesn't require any generator parts this stuff. Some people might just want to use that some today. In fact, I stayed back here here.

G

This is like the yeah, the client, without any generator the parts yeah so off, all the stuff that you need to build the kubernetes planet basically and then or every you know, grouping of avi groups like for our core API for the Federation API for the Service Catalog API is for the, but each of these logical distinctions could choose to publish a repo with the generated client.

G

Alternatively, people could choose to just consume the generator directly and build a client for themselves as part of their tool chain. I think.

G

Honestly, my preference would be to like not publish the pre-generated clients at all I think it is friendly to users. If you do that, though, I think.

M

Like I, do not use this for actually speaking I don't see how particular.

G

There's no there's just this to this to awful like many people, if you're doing it for production, you have more than one user, you more than one developer, I.

B

Feel like I'm here in half.

O

B

um I think that a go library that doesn't actually publish the results of running the generator for the fret is of limited utility is. Is that what you're agreeing with or is that? What you're proposing.

G

Sorry I didn't follow that up. Iii.

B

Think that we need to actually publish the generated code, the results of running the client generator I think that why, because I think that's much more reasonable for someone to try to include right rather than and have to like someone similarly required, go, go generate this.

B

Instead, you depend and go get the libraries already been generated for you, it's ready to go and you can compile against it, and then you can also reason to believe that anyone you try to interoperate with is gonna have the identical types to you: they're pack, the interfaces will match and one if, if, instead you tried to force everyone to generate their own, then we're gonna end up trying to convert between clients. As you try to integrate multiple projects together, I think.

M

Journey your own is not a viable option like I, can't imagine a scenario where that would actually work. The generator is oh yeah. All the generator is written in the languages that they generate.

M

No, no so language, every language has a different build system and somebody's like we just don't even have build systems so uh and go. You know. We all know how badly mentoring starts and how about system science yeah, that's like so.

K

M

Only language it would be native, but it's kind of selves and I really would just committee non-native and nobody's gonna want to do that. Yeah.

K

It's a little unclear to say if you want to use our Python client. First install, go I'd run these generations.

G

The Python client generator does it use, go no.

P

But does go something, don't even work and also a girl code generation is maven, but actually it can be from independently can be known as an excludable file. They may publish that.

K

Just seems like we go on a whole layer of friction, yeah we're making every consumer. It just seems like putting the burden on the consumer you're fanning out. All that friction and work and I don't feel a bit a bit.

M

So we don't want people to use.

B

The generator we want people to know.

G

We still want the.

B

Generator for those people like Service Catalog and actually generate their clients right. We want to have them able to generate clients that can use the same base type here. If we're saying that.

G

That users are gonna, consume pre-generated, clients that puts a lot of burden on anybody, producing an API to maintain a client repository yes and keep it like in sync, with the rest of the ecosystem. Yes, yes, and and- and it means like we- it means there's an explosion of like.

G

Collection, language must be by.

G

Api group collection so like one per Federation, one for Service Catalog, one for her like core kubernetes, yes, and you have a time for the number of languages.

Q

Yes and whoever's consuming us to make sure that they're pulling out of all versions when they try to if they want to use more than one group in an example process. Yes, that means not.

G

Everyone from the branches have to be they like they have to have a you know: 1.0 branch, 2.0.

Q

Branch 3.0 branch and they have to roll other. So earlier, Daniel was talking about things like the language utilities that the generator is going to clip, and so, if I'm pulling in go every one of my life breeds better, be using the same copy of that language, utility or there's.

R

Like a go very pop yeah.

Q

It is exactly but I mean it's not specific to go right. Every language is going to base this.

R

Q

Well, assuming that whoever's building this wants to go to the effort knows enough java black magic to use class loaders to separate them, which they're not going to so you're, going to hit the same problem with the jars and in their double libraries in Python. The every language is going to fix this I.

N

Mean every actually recall all those all those we knows how to make you release everything. That's.

Q

What I'm saying yes, essentially, if you want to do, if you want to pull in different vendor copies of these libraries, and you need to be able to make sure they were built using the same underlying system so that they're safe to be compatible in one process. I think it's just.

M

And we used one, but if like Red Hat wanted to freeze one that also included open, kids, I know and also be possible for them. But we shouldn't require thing.

Q

P

Q

Think we agree, we don't want every end user, but at some point they're users are going to have to do it. Writing in I'm, using my own aggregating, API, or there are times when we should. We.

B

Are still providing on use, so if someone, if someone has you can do, but if we don't actually publish the generated code, the code that runs as its created as a result of the generator, everyone will definitely.

K

Have to instead.

B

Of a few people may have to yeah.

K

B

K

Incentivized to make the tooling the generator generators, usable and as as usable as possible, because you know we're gonna, be maintaining generated clients. So we have incentive to do that. But, like David said, if we don't publish it, we're requiring everyone to use it that change bad, so I have just.

G

Something few ditional thoughts like as written this document does say we will publish it like that was the intention. What that makes things a.

P

Lot that makes.

G

Something is the other repo.

P

Is completely generated, the other evils or generator does not change manually in any way.

K

P

Then any any any of those coins that we have in in our port, we can actually robot can actually update them all together, only trees that would serve us, so we can keep them in sync by just generating all of them. We can. We can force that there is complete fire somewhere at the root of the Rico, so SN stays up to generate this triple then you're. Looking at leads into my next question.

G

Which is, if we're talking about having in repose and trying to keep them all all in sync, why not just publish all the generator code and similar ethos? The the issue with that is that people would be importing more clients. Their cluster may support that really like a league yeah.

M

G

Geiger's, although you can have groups for any language like Federation, Service, Catalog, the main repo just stuff them all in any no complaints.

N

G

We should just know separately.

P

But is there any complete candy there.

G

Shouldn't be API, groups are named to prevent conflicts, I mean.

M

As long as clients.

M

G

For clients, because it wouldn't be composable, so I get yes. This is this is what I'm asking is: is composability and requirement for the separate API group, collection repositories or.

M

Whatever, yes,.

G

That's basically the question that I'm asking like I've got a resource or an aggregated API for my cluster and I want to provide my developers with a type client for this thing. So so, when I went to generalize, you guys I said.

M

We put all of the api's under our umbrella article into a slowly, oh just for convenience, and as long as users don't have to link all the libraries they don't need into their programs doesn't look for them and you have a test which ensures that it's possible to act. Another faking a group and you get together with that library so that we don't break composability, but we don't actually force people to. You can see what will be posed. I like.

B

The idea of having a separate, unrelated four types but I'm not sure I, would want all the kubernetes types there right. I see things like Federation as a distinct set of api's, and also things like the aggregator api's yeah logically separate I. Guess.

M

It's true I mean the direction we're going with. The project is in order to get anything into the kubernetes repo or whatever you want to call poor or required. Api's they're gonna have to go through a lot of cycle where they started incubator. So I think that is worth taking into consideration and as a way, a factoring like we have the mature accepted I mean for some definition immature but be except instead of API is and then the up-and-coming API is will Aliki to.

M

J

G

I'm not sure how that cashes out in terms of like I.

M

Should we just try like I, think how much do we need to buy credit before we actually do do it right? Can you just try trading by Reaper thing? You know so right now there are only those right.

F

B

A

G

Would make sense actually yeah.

R

Do you what we're.

G

Suggesting that we link the aggregation, ap registration API in with the rest of the could be music guys, I.

B

Would you would you try to make the same argument for Federation.

P

G

I would not make this an argument for Federation I. Think.

G

Okay, so it seems like the part of this proposal that is relatively okay with everybody is putting the generator and it's the generators together in their own repository I, don't think was arguing against that.

G

So I have one one more thing that was probably with group discussion in this repose in this roseola is: do we wanna the the base library for each language? Do we want a group? Do we want to publish that, together with the venery clients, I I think it's normally.

B

Alright, what was that David? Does that I think it should be a separate repo that the the generic pieces should be in a separate repo from the generated uses, yeah.

G

I I feel like if we, if we want to have any hope of, like composability between the generated pieces.

G

How much I was a big advocate for well.

M

Mining them just because it would be simpler. Well, the non generator ceases are going to need to be able to be used by all of the generated repos correct. So how would that, if we split the generated things into multiple repos? How would that donkeys brain work right, yeah, right, yeah,.

G

I think if composability is like even if there's desire for any composability at all, I think they have to be in separate yeah.

M

Just try that even.

K

Even if we end up putting all of our lands into a single repo, there will still be other parties having clients for their API is that are never gonna live in a Cuban, Eddie's repo. That would right.

S

You pull in on.

K

Generators enough together, we.

S

S

K

Making someone pull in all the kubernetes api is just to build a client that makes use of a watch utility that isn't API specific doesn't seem like a good idea. Yeah.

N

You're not going to go there just specific thing: it's a dependency management in.

M

Separating it yeah more strongly so I don't actually bring down work. Gridlock, yeah, general, just.

N

Tend to output today final single, it's easy to make cream! Therefore, the yeah.

K

Doesn't matter means we haven't in the same repo, but I want them separate, so whether.

H

K

What that looks like my language right, so in Java, you have libraries, your different jars and go. You could have different packages and we can have package enforcement on the repo says these packages are the.

I

K

Ones, API specific: these are the utilities it doesn't bother me I just want to make sure you can pull.

G

It the utilities right just.

K

G

Like a severability like these repos, are you can choose what you get this repo everybody needs.

G

A generator the output relies on a.

Q

Particular version of the base that I think is the bigger one is that the generated code has an implicit dependency on a particular version of the base. Library and.

B

I think it's better for us to experience that then you have someone else, experience it and then us be like, while I hadn't seen that before so I think separate.

K

B

K

Problem that has to be solved and yeah. We we should either on dog food as far as like generating the types on top of the generators and the utilities yeah.

G

That's something else: I wanted to talk about, maybe not in this meeting, but at some point does it really makes sense to.

Q

Do we at least have a scheme for making sure that the customer knows that if they're pulling in this generated and they're composing, they have to pull in this utility library.

Q

Well, that's that's my boy and, and we need to have a way of expressing adding go in Python every language we support. We have to have a way of expressing that.

Q

As long as I mean this has to be something we do, we have to have a way of indicating what that dependency is in every language we wanna.

N

Make sure that generator code and the master branch.

M

N

M

Can step with our default branches, so we can make master.

N

Organ tomorrow.

H

Because it's really it's still really hard to hear anything that you guys are saying over there yeah.

P

This is it's as.

B

I think they're plotting their takeover of the world later on.

J

P

Just okay, I just switched this that to be the speaker, does it work I, don't thing is it's that my.

G

Documents now the speaker and a microphone: okay, okay, we have a twenty minutes.

G

Getting proposal then I sent out Jordan gave me a lot of comments. Did anybody else? Look at this document.

B

I'll assume I agree with Jordan. I did not I'm, not read it in detail. This is the one that let an api server decide. It was gonna, reject someone's input right, but still this is about letting users.

G

Tag their fields and API types with.

G

Or not able and then like maybe we're disabling at runtime.

G

Additionally, if fuel can have a warning attached with it, we know if we want to go down this route. I'll go, find Brendan's PR about adding HTTP morning headers and see where that is- and this was you know.

B

This is an alternative to the last three things. I tried in this space, I'm trying remember. We had one that that we I thought we were close to agreement on. That was alpha fields, always break and yeah.

G

I think we were actually like, like aratoon, was sort of arguing for that, but not really because he was not on board with always breaking alpha fields and I, just the version that I wrote it up like that, I just don't think it's feasible unless we're really committed to that and I, don't think we are yeah that one that one was nice and that it required nothing new. Well, you said we would gate alpha to alpha fields. Yeah.

G

This army about thing you.

K

Can agree, it makes it hard to look at an object and know whether it's using alpha fields, so it requires submitting it to a server and seeing if you get a warning back know whether or not this thing is using alpha fields. That's.

G

K

G

I feel maybe al her not valid, depending on the server that you're sending into well.

K

The one where we named Alma fields alpha if it's clear that you're integrating with something that is alpha I like that aspect of that proposal, then.

G

You always have to bring people and we're not willing.

K

To always bring people so so then, the the other two things about this. If a field starts as alpha, so you have an object definition, a yam will file locally and you have a client that is not if I'm reading this correctly, the client is not intended to be aware of gates. It's not responsible for scanning gates. The server is so. The client is just going to take that yeah mole and submit it to the server and the yam is what the server is going to say.

K

Is this a field that I have flagged as alpha and disabled then reject or warn, or whatever you still have schema breakages version to version right. So if I have a local object, definition that is using that, but that I built using an alpha field with one schema and then I submit it to a beta server that changed the schema. Well, the server.

I

Is from user perspective, it.

K

I

K

I

Can you say is the the thing that I'm showing on the screen is that's a scenario that you're trying to talk about.

K

Let me get back to the mobile.

I

Because I can't quite follow your description.

K

No so where it says, the dynamic client is not affected by this problem. This is sort of the the reverse problem, so the problem on the screen is an alpha client can't that has strongly typed structs can't decode beta fields right. So that's gonna, that's gonna make an old client. This is.

G

Talking to this isn't about clients to decoding stuff, it's about servers, not accepting the stuff that the client is sending to them. Yeah.

K

This key right, so there was a schema change. I built my object when the field was alpha and you know if I had submitted to alpha servers, they could warn me or reject or whatever, but then the field graduated to beta and change schemas, and now my alpha object definition. My yellow file can't be submitted to beta servers like for number 4.

M

On this list, which is we disallow that, like you, pick your favorite name and if you screwed up- and you have to break this changes scheme in a braking way, you have to pick a new name. Sorry, practically speaking, I'm, not aware of a single instance of that ever happening. I can all the peels we've ever added I, certainly easily roll the dice. That's.

G

Certainly easiest I, also like three is, is also appealing. Don't worry about. It has never worked that didn't work previously.

M

I'm saying it's like: it's never never worked, but I never happened. You go yeah I mean in general. We don't find out until the thing is GGA and we get user feedback that we'd screwed up like we try to push things so aggressively to stable that we don't discover those kinds of major issues and.

K

So what it would look like it would be less a schema change and more of a and we're not going to go this direction. This feels like the.

M

K

Is dead? Sorry, yes,.

M

Yeah, so in general, I think this approach is very compatible with other things. We need to do anyway, which is we need a dry run operation which says, you know tell this, wouldn't succeed or not or what the result would be, but don't actually do it. We need that for every kind of mutation we need to have server-side validation, so we can rip the validation code out of queue control, but it needs to be optional, so the flag gating of alpha fields will play very nicely with that.

M

If you specified an alpha field and that field were disabled and you requested strong validation, then you would get back an error. So I think this would be very complementary to other things. We need to do anyway. Okay,.

B

Now is the only difference that we're going to have from exactly what we have today is that we are going to have a wait for the server to be configured to reject any any object that sets these alpha fields. No.

M

We're gonna be able to make those fields be as if they weren't there yeah exists.

M

K

Just that it won't exist, but it can reject it, but just because it's rejecting it and we're sure we have no data in that field does not mean we're free to change the schema of it. So I would.

M

Say we should only read well, so if it's as, if the field weren't there, the field would be dropped on the floor. If the client requests strong validation, whether it's an alpha field or not an alpha field.

G

We can go one step nicer than just dropping it on the floor. We can drop it on the floor and give a warning so.

M

By the way you had alpha fields so.

G

We should do that not.

M

Just trial four fields, but in general, if someone specifies a few and it's not valid, we can generate a warning by DL and allow the clients to request their yes. Disabled alpha fuel should be no different than any other field. That's not understood. I. Definitely.

G

Agree with that, but one of these things is like ten minutes of work once we have the thing and the other is significantly more work. So it's a question of how much effort for the benefit.

P

Okay, it should be, should it be something like we do: a strong validation and warm people anyway. Yes, but anything not just dropping yes, I default. We.

M

Warned and they request that we give an error really given in there. No that's 55 89! If this yeah, it's just just like compiler reporting earth, yes, yeah, okay,.

G

Is are there any remaining objections to that document? What is exactly is non-portable? Oh now, I'm part of all the idea was to like suppose you use the GCE persistent disk. The idea is that your cluster administrator can disable non-portable fields like GCE. Persistent, just only works in GC p, doesn't work on pram or an AWS, so the server can be like this consent. Back I'm warning message should be like sorry. You need to use PV C to accomplish this.

G

The idea is to force the users of your cluster to only write applications that can be moved between cloud providers. I.

G

B

Alpha and the beta I can I see and that's obvious dev is less obvious to me how dev is different than alpha and Norma.

G

B

I may be related to the rest, so so.

G

Deb is different from alpha in that dev is no clients out. There are built with dev other than once for developers own testing, so you are free to changes. Pima's of death fields like there's no clients out there right.

M

The intent of that would be.

G

For features which aren't even complete, don't work right right. The intent is like I'm still working on my API I want to submit my API, and my implementation suffers. The guy will be half-baked until like implementation and I would look to say. This feature is not ready for this. We're not gonna allow, and then this feature this feature is not even alpha. You can't use it your cluster, that's that's what Deb is for it's like even yeah. It's like you know,.

K

Once we start using our own generated client, how do we avoid generating clients with dev fields like I I, definitely understand the intensity.

I

G

The ideas we will start generating clients from the open, API spec and the dev fields won't be included in the open, API spec.

Q

Is it also true that something like there's a corollary flag on the API server build, so you can have a devil which will accept dev fields and a non-death build? Will yeah.

G

Yeah, the idea is this: dev would be like a bill time flag like if you, if you want to build a banner because it's like you probably want to enable you to be testing on your dev feature stuff like that, so it needs to be a.

B

Comparable to the rest, yeah.

I

So not portable I included, I I, don't feel super strongly about implementing it right away. I think it. I I.

G

Think it's a pretty compelling use case like like admins, want to force people users of their clusters to only submit jobs that they can move between. Cloud providers like well.

M

At least I would portable is a little bit stronger than something which I do think we definitely need which is any features which don't actually work on a given communities, service, sort of distribution. You should be able to get back to same kind of warnings or errors as features that are otherwise disabled like it's, not yeah I mean to submit something that has no chance of working. Like you know the elastic block, storage on Google Cloud, or something like that, yeah I, guess.

B

I, nothing in this talk except non-portable bit really gives me pause just because it's it's kind of like an extra layer of nicety on what we already have. Yes,.

I

So not portable is sort of like a like.

G

You could you could easily split that into two things like the the mechanism. Described is really also just could define their own feel gate, so you could have one for GC 1 for AWS well yeah. We.

K

Have a provider you.

G

Have one for every cloud provider and you label each field like the gate of the cloud provider and the non-portable gate, like thanks company that fee and can like turn them all off, or they can turn off turn on or off justice.

B

System on providers or the non-portable and go ahead with the rest of this knot and reevaluate non-portable later well,.

M

I would also defer the dead stuff and especially there's gonna, be a bill type of thing and you know I agree with the point about you know: how do we address the generated libraries and stuff like that? So I think if we just start with the dynamic gates.

M

G

I mean this stuff is easy, I mean it will. If we have the mechanism in us, like you, know, half a dozen lines of code to add the damn thing or whatever all right, yeah.

M

I guess how has the same problem if you have generated libraries with the alpha appeal, yeah, yeah where's? We if we don't.

K

Allow schema changes for also things, then a lot of my questions go away like old, client, new server, new client, old server. You know if it's gonna just accept or reject, not have to deal with different schemas I. Think the other.

M

Rule we need to make which we learned when we changed commands is changing semantics, but about changing the schema. We also need to ban right because it.

K

Was impossible to.

M

Find things which expected and obedient like ours, and then we changed man said mean entry points and added arts and I was just impossible to basically find those.

K

So we need, when we're doing API review. People need to be aware that, like if they fix their like all-time favorite name for this field, and they just want to throw out an API as an alpha API. They need to know like you.

M

Know yes, they do do they need. Yes, they do need to know that so I want a related topic. I think we really need to write a validator at this point to catch common API conventions and snap boos, and one of the things we could actually check is. Are you changing the schema of the field that already existed in a previous release or something like that would just make API reviews I, think less painful? It can't the number of times we look like fix, capitalization or stupid crap, but I'm.

M

Sorry bill doesn't look like if we're going to get to your.

J

I must say.

G

We haven't gotten to Jordans repo syncing.

I

Jordan, what do you want to talk about with regard to repo.

K

Now that one sec cut, we have people who are trying to vendor like the one, six API and then associated repos, and there aren't a set of matching or not matching shah's, but a set of Shaw's that are coherent among the repos and I was asking how about it, and he said we couldn't push shah's from the one. Six branch or tag I wasn't sure. Why not.

N

I mean it's a we're using a robot to do the publishing and it will always call the hats off a branch and unpublished to every repos. So I'm saying we should just make sure release branch in each of the publishing and this release branch were tracking the kubernetes, Pervis, 126 and robots. Will roll over publish whatever is community into released 1.6 mm it shouldn't.

G

Actually, pull head of the release branches, it should pull the last tag right.

L

K

I mean if it's just a tooling thing like having, if he doesn't have the ability to do this today. Okay, but do we agree that we need the ability to pull like a sink shah's out to the repos from a given tag? I think.

B

That you two are talking about different things. You don't realize it so so there is a a pile in each pose called kubernetes Tom when I initially made that file. That was the show that you synced with right, that is, the you synced on sha foo and one sings to Xiao foo, and they all list that in their community sha file, regardless of whether there are any changes.

B

One of the changes that Chow made to the robot was that if you sing Xiao foo, but you haven't had any changes since the last time, you synced you don't actually get new permits, so the kubernetes sha is not updated to reflect the last time you attempted to sync.

G

And so it sounds that should be. That should be like. Even if there's no changes, we should.

P

N

G

Using that to differentiate published, you know, maybe we should add a file that map's like this. Everybody sha means this.

G

A shot may increase before the.

K

G

K

Want to be able to tell people who are looking at the v16 Oh tag of kubernetes, like what level of the other three repos to pull honestly.

G

I think this is a bigger problem in, like our group, I think, as we start to split pieces of kubernetes out into other reasons like we need to test things consistently when you release Mrs, Bailey, yeah I, think it's it's it sort of needs a project-wide solution, I'm, not sure what to do in the short term about it.

B

Well, it's a piece of metadata that would be useful in trying to link these together. I mean I, don't have a huge objection. I guess the only objection I can see to doing it. As you end up a lot of commits I.

G

Don't think that I don't.

K

Know that I can probably.

G

Yeah I mean this is gonna, be like what I won't commit a day. That's.

B

Every few hours certainly sounded nice to me. It's a robot, we I mean I. Guess we technically pay it by the hour, but.

K

Tracking head of master and ahead of release branches is one thing, but definitely on the tagged releases like that. That's the thing I care about at the moment, and that seems like something we should be able to do. Yeah.

G

Like we're, gonna have all the same problems with the API machinery, repo that we've had a client repository that people are gonna want to know what the release schedule is. They're gonna want to know what they depend on I wanna know what the duplication policy is, how we version it.

G

So we sort of improve things a little bit in the client go by adding a bunch of documentation to the readme page, like all the stuff captured in the readme page for the ICO repository needs to be captured for all of these other repositories. Client go can't answer this question either.

B

The the issue here is its its metadata that just isn't there you end up trying to describe to someone that either they just get the latest or they try to find the latest of all the kubernetes shah's and all the libraries they depend upon and then find the tag. The minimum tag that match it. That has that particular commitment, and so it's it's possible to describe. But people have been complaining that it's not obvious.

G

I yeah I agree. We don't do a terrific job. This isn't Clank Oh like like there's not actual like this Shaw's can paddle it. With this shock. There's there's a theory that comment yeah, there's there's a matrix of like this. This branch is compatible with this branch.

B

K

I am I missing what I was expecting was when we looked at the given kubernetes level and synced out to the repos. We would then tag the same tag across those repos that no.

G

I like if there's like five tags in the in the released 1.6 branch in Cooper ideas, there should be five tags in the release of API machinery.

N

B

Means we give up on Cimber, at least for now. I don't have an objection to giving up on semver. Just oh.

Q

No, why december, why? Why does the semper have to have anything to do with the tag right? If we have a kubernetes master prefix for its AG, you say: look I had built the master kubernetes I have a client go, which is tagged with that. That has nothing to do with the version of client go. It's saying that this version of client go is for is compatible with correspond.

S

Q

This job, nothing.

S

To do with ego, verse, yeah.

R

K

R

K

Want to do all kinds of things, but a reasonable client. A reasonable request is hey.

I

K

Was a kubernetes release? I need to pull in what I used to pull in, which was like API types, and now those are split across three repos and I have to pick a sha from these three repos. How do I do it for.

M

The last release yeah.

T

Q

Continue, yeah I think you can do any and you can even retag the same commit for multiple releases if you want, but.

T

K

Like the idea of a prefix to tag that indicates this isn't a version of this. This is like tracking an upstream tag from the yeah core.

P

K

That makes much as me good.

M

I guess there's feedback distorted, saying that the FICO version makes no sense secretary. That meant emerging that we're doing for trying, though, is that actually viable. Okay.

G

I think I think that's something to do pick up in another meeting, we're driving it this over yeah. Alright, thanks everybody.