Kubernetes SIG Cluster Lifecycle, 19 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Cluster Lifecycle 20181219 - Cluster API

Description

Meeting notes: https://docs.google.com/document/d/16ils69KImmE94RlmzjWDrkmFZysgB2J4lGnYMRN89WM/edit#heading=h.sp1hfrs780gt

A

Okay, all right welcome to the cluster API project meeting. This is Wednesday December 19th 2018.

A

If you are in attendance, please add yourself to the attendees list and the meeting notes I'll post, that link in the chat and if you have any topics or questions, please add them there as well, and it looks like actually a just to recap. Last week there was a meeting that took place during koukin and it was on Wednesday also, but it was a slightly different time.

A

I know some people joined and we took notes and they're also in the agenda agenda doc and there's a link to the recording we discussed sort of H a you know what what you know what har you know how highly available clusters sort.

B

A

To the various parties in the cluster API project.

C

A

And yeah now we're sort of back to our regularly scheduled programming. I. Think last week we at least I'll try to give a quick, quick, summary, I, guess, I I'm, not sure that we reached consensus on exactly. You know the way forward for highly available clusters, but we heard you know ideas. We heard ideas from the from the Gardner um project, how how H a is is handled there we yet talked about.

A

You know whether whether we would need to handle at CD clusters, as part of you, know, cluster API and yeah, so it was just a kind of an exchange of exchange of ideas but I. As far as I understood there wasn't any sort of consensus on you know what what we should do. I think a few people did voice the the idea that you know there there's sort of time for experimentation and that you know once once we try some some approaches. Rather than just talking about them.

A

We can see we can. We can judge them based on how they work and then perhaps you know, adopt one or perhaps more approaches to to a che in the insert. The common cluster API code and yeah.

B

A

That's all I have I think for for last week, and it looks like the next topic on the list. There is from think of my sin. Do you want to you want to take that yeah.

D

So we had a lot of discussions about the Machine machine. Epi is working with other cluster object, so this is this PR that I sent is pretty straightforward. All it does is that it still it just ash. It goes all the way to the actuation layer, so it will call the machine actuator, but it might call it with Nilka straight cluster object and that's primary.

D

That's a primary difference between the behavior of today and the mean behavior with that this introduces it also, we feel like this is the right way to go regardless of the direction, because it allows the Machine actuators to Oishi take some action without being completely blocked.

D

This does, however, mean that we that all the providers would need to actually read machine actuators which it can take, which expected nil coaster object, so they would need to add that check.

D

That's basically, the idea of that.

A

Something that will work with the existing actuator interface and and yeah I. Don't know that we've talked about changing the interface but yeah. You know making the interface doesn't change.

D

It is basically that the interface takes a cluster object and a machine object, so the custom object. I can be nil. Now, that's a change.

D

C

Looked at the PR a little bit, I think it's pretty straightforward and it looks good I saw that you also have to release notes, which are nice. The only the only thing that I was thinking about it's like a now. That's no. We should probably make it very explicit in the interface dog that could be nil and the the closer is just often yeah, yeah.

D

C

Some sort of, like the other thing, I thought about to provide some sort of like a default like dummy cluster, but that's like probably like down the line. I, don't know if you want to do this right now, I think.

D

Passing a dummy like passing a dummy cluster object is interesting, but I don't know if that's the right thing to do, because it's hard to like it makes it harder for the providers to figure out. Is it a default object or am I supposed to do something else here or what right.

C

So that that's probably for later to discuss I'll.

D

Definitely have it the dot comments, I'll update the dog comments on the interface.

B

So one question that I have with with regards as separating them as right now we do store some information that is needed for within the specific provider implementations right now.

B

Would the idea be there that it would be a provider implementation, specific thing that the cluster would be required, or would we expect that there'd be another level of defaulting on the machine suicide for provider implementations right.

D

Now, the right now, the idea is to have it be provider, dependent and then figure out what we had to do next. This only makes it since this is only basically says the cluster object is optional.

B

All right thanks! That's.

D

Basically, all I have on that.

A

There was a separate issue may be filed, it was, it was related and I. Think one of the one of the alternatives was to make a cluster optional or cluster object optional. One of the alternatives, I think, was to actually remove the cluster object from the machine actuator interface.

A

So what would happen is instead there would be a reference from the machine object to the cluster object, and so in that way the provider there sorry, the machine actuator, would would check if such a reference exists and if it does, it would fetch the cluster object that way, but yeah. That's something I think to discuss I, guess down the line this this is this change doesn't doesn't doesn't change the interface yeah.

D

Okay, all right I'll, add the docs I'll, be the docs and then we'll merge it in a day or so. I.

E

Have a quick question: I mean: can you maybe just if you talk about maybe what the benefit of like what maybe the use case that you're specifically looking at when you do a personal cluster? What would be the benefit of that? I personally haven't really gone through the PRA, yet I'm just going through it. But you know some background will be helpful. So.

D

Thank you. The idea is that, regardless of if whether the provider expects a custom object or not right now, with completely block the provider from doing any actions as the cluster object isn't not provided right, the actuators are basically just blocked, so this is makes it possible for them to run some actions, even if the cluster object isn't present and if they were. This also makes it possible to have. If you have a bespoke cluster implementation, you can still use the machine implementation, regardless of that.

D

So it kind of allows you to have two separate like use machine. The machine ep without using the cost rate gas eventually.

E

Okay, so the question it may be, a nerve is like I get that you probably won that we should be able to create machines and they call you know they call should basically get to the actuator to do something right.

F

E

Only concern is like, let's say, even if that actuator comes in like that call to the actuator goes in with the machines back and let's say the cluster object is not there yet now. You know if you just at a very high level, think about what they actually create an instance on, whatever the cloud provider it is and and for most parts, I think you know where they feel creating like the master. Probably it's okay, but if you creating a worker, you probably need some more additional information, but.

E

B

E

Need ultimately, that you need to tie that machine to a cluster and if there is any sort of information dependency that you know, information about, let's say the cluster that needs to be part of or somehow linked to that machine. Would that have any implication in here.

D

So we, as in that word it's just that's not- everyone uses a cluster api's, but more providers want to use a machine api's, so the cost of references or whatever information required to create the machine. The actual instance can be part of the provided spec as well right. So there are ways around this problem that other that people might be doing today or want to do.

C

So, just to add, like a little bit of more information on this I, open, 6, 3 9 to the basic, actuators and I, think this ties into it, because one of the things that we discussed is the concept of cluster actuator actually in the providerís sets up like, for example, for BBC subnets or load balancers, and some of the parts don't need that. Also them like, we don't have a concept of like control, plane, actuators, which we might want to add later on, and so this my sitter. This might answer your question.

C

So the the whole goal is to pretty much like, say the cluster, which actually just sets up infrastructure for the provider might be optional, and this is a confusing concept. So this was also like the next stop on the agenda, but it was mostly to revisit like how do we name these actuators and also like? Where do we go from here? So.

E

The issue that I don't know I mean this may or may not be an issue for every provider, but I guess one of the usefulness that I see of the closer object is if for the given entire cluster definition, which includes I cluster and the machines and the Machine sets whatever that may include. If there is like a common set of information that needs to be common across all of these objects that say that are belonging logically belonging to a cluster.

E

You know to me, it seems like the cluster object seems to be the right place where we can put that common information. One example that comes to mind is, for instance, when you're, creating when you're creating the communities cluster you we all need to configure the kubernetes cluster with the underlying cloud provider configuration and that configuration to my knowledge at least would be.

E

You know one thing that is going to be common, regardless of how you create the machines with us is key for a given cluster and the given set of configuration you want to have a single set of you know: spec, driving that cloud provider configuration file or conveyux essentially onto the cluster. If we make the cluster optional and we break down that information into all the different machines, then it kind of becomes. My opinion is difficult to reconcile that, because more you have a you, have a possibility where you could.

E

Somebody could create different machines that eventually are going to be part of the seen cluster, but they all might have some slightly different variant of that information. That's using to be you know the doable certificate, like the global cloud configuration setting for that kubernetes cluster I hope that makes maybe a little bit sense. Yes,.

C

I mean the mixer make sense to me. It's a very valid point. I think that could be achieved also with machine classes to share configuration between different machine or or like I mean the provider that you will be implementing like could just like keep using the cluster for now I mean I, don't I, don't think that's gonna go away.

C

It just is optional for some other providers to pretty much, not use it. For example, if down the line, we're gonna use, eks or gke as like a variant or flavor, we you, you don't have like the ability to customize the control plane instances or to set up like any Flags for comfort for Covidien or something so the cluster. In that case, I, don't think we will be needed.

C

So that is one of the use cases for it. I think.

G

Oh sorry, one thing I thought to call people at cube con about was right now, cluster sort of conflates two things one is that it sort of defines the control planes per cluster and the other is it. It defines sort of cluster wide properties, which is what arts is talking about. I, think a lot of the cluster wide properties are required for many of the machine actuators because they define things like network ranges so forth. I think it would probably be worth maybe splitting those concepts apart and having a separate API object.

G

That is really just the control, plane and and I. Don't know if cluster becomes the right name for the mish, the properties apply to all machines, or if we can pick a better name for that, but you know I think that making those things concretely separate makes a lot of sense. There are also people at cube con who were hoping that we could, you know, split those things into two different API Hertz as well.

E

Yeah I mean I, think I, like that idea, I mean essentially due to what Robert is suggesting I. Think I like that idea. If you have, if we can have like some sort of a concrete API which can govern, let's say the cluster white things, that's something that needs to be shared across all the machines, because you know to the point of machine use of machine class. The VIP machine class is like you can define one sort of variant of your machines with one machine class I can have within a cluster.

E

I could actually use two different machine classes to this little out to different group of machines, for instance right so your machine class. Yes, it's common across a set of machines, but that may not be all the machines that comprise your cluster. You may still end up having you know, be able to use multiple machine classes for a given cluster, so having maybe maybe, is creating a separate object which can really cleanly define a cluster wide configuration.

E

Yeah I mean then that definitely makes sense. I.

A

Have a question on the implementation, so is this: if I have a provider that is not checking, you know, or let's say sorry is assuming that the cluster you know is that there's a cluster object being being passed in, will you know, will this potentially break I mean you know, have a look cause? It causes seg fault for handlers.

C

A seg fault so.

A

Okay, so that's that's I, think. That's that's something important for providers to know about, even though it's probably the case that you know for a particular provider writers if they need a cluster object and they're there's going to be a cluster object and and most of the time but it'll be a surprise right if it. If there's no cluster object, then there's an unexpected seg fault and then that I also I also had a quick. You might assume. You said it was a. It was blocking certain use cases and what I'm wondering is it.

A

You work around this issue by passing in a you, know, a dummy cluster object and, and it you know, why is that, if that's not a, you know good work around what what is oh yeah? What would it.

D

Assumes that you would have to define the clusters your bees as well, and you might not want to do that here right so like I, should be able to create a machine machine, said machine deployments, er these without ever creating a machine, class, CRT or ever interesting. The cluster CRT so I think that's what I was thinking.

D

A

So that, though, those are the trade-offs, so the not creating CR DS, but then you know the actuators you need to. If this change is merged, the actuators need to need can no longer assume that there's a cluster cluster object being being passed in great.

D

So, that's why it's also part of the release notes, yeah.

G

And I think to that point there were also a number of you, like Yukon I, think it specifically the open shift, folks, the cops folks, and maybe one of the group that was saying that they really want to adopt the machines API and don't really care about the cluster API part of it, like the part, that's currently in a cluster, API and I think this. This is the sort of thing that puts us one step closer to allowing them to do that right.

H

I'm turned about people not reading the release, notes which, hopefully we're not some considerably kids change the interface signature in some way to force a realization because, like force to be a compile time, failure.

G

How would propose changing it to force a compiled family.

H

One way would be to just add another message or would change the signature of a method in some way: I, don't like the v2 method or the v3 methods right where you just basically find. But that is one approach where you define a method which is like it's sort of like a sentinel method, but doesn't actually do anything.

A

I guess we could just combine the combined the ideas, the control plane out or the renaming cluster to the control, plane, object and merge the two together and that is breaking I.

C

Mean I think I think this is a result of like the wrong abstraction and we're just trying to fix it, which I think it's fine and we can revisit it later when we have clear ideas and requirement.

E

So how likely have a follow-up question regarding the use case, for this I mean so from what I heard I mean like you want to use, maybe like G, K or K s, some other services, where they just want to use the Machine api's? Now, in that particular use case, are you guys planning thinking that the trust or API will still create the actual master nodes or is? Are you looking at only then trust API to create for the worker nodes? I was.

D

Just it could be done used for both, but the majority of the use case that I have at least heard about is using it for the worker nodes.

E

Okay, so would it be fair to say that you know, regardless of what you say it's kind of like you want to use less than the API as a means to let's say, extend an existing queue vanities cluster in a generic way? And then you just want to use the Machine api's to do that. Where you know the cluster API is not managing the entire cluster someone else's, but you're just using it to extend it, and it certainly that'd be fatal.

G

Yeah and that's it that's how I understand the open shift use case also, which is the open shift, already, has tools to manage clusters, but they want to improve their machine management and they like to improve it in a way that's compatible with where the direction of our sig is going, and so they can also reuse what we're building.

F

Just to comment a little on this I think there are two things we have to differentiate here. The one is the API as API as types and the other is the implementation of this machine. Actuator and the implementation does currently not really support, not using the Casta part of the API, but I would argue the implementation as sort of a default you may or may not use, and it doesn't suit your needs. You could also add another one to the app single vehicle or bill just had one downstream yeah.

E

So one thing is we would it I mean, given that the use case here might be to extend the existing cluster? Would it be possible, maybe that we can add additional field inside our cluster object, just to symbolize that that you know it's like import a cluster n into the cluster API concept.

E

So that way, you know you still have a cluster object, but you know it has a special flag or something that says you know I, don't do anything really with it, because this is something like externally managed but crystal fills in the same place, holder and and keep the rest of the you know workflow in the same way as it would otherwise it.

D

Makes the user experience on key because I now see a cursor object, that I cannot change or with.

E

It true, but then I mean having you know, I mean. Hopefully what I'm thinking is that cluster object. When you look at it, I mean it's clearly from what's inside that cluster Allah should be able to see that ok, this is an externally managed cluster, so it doesn't have anything like meaningful in it.

E

Just like a reference was okay, you know it's an externally managed cluster, so it kind of so the point is like someone who's, let's say familiar with the cursor API and the way it has been used today goes and suddenly has to interact with this kind of a cluster, and they look at that cluster object, but they can clearly see that this is an externally managed cluster, so they don't really do anything with the cursor but they're, just creating worker or additional nodes.

E

For that matter, I mean I, don't in my mind at least that seems I know it's an additional object that we create, but to me, that's like a more explicit placeholder to suggest anybody or any controller for that matter that this is. You know an extension, and this is not really managed cluster by cluster API, like the management for the control plane.

E

Because having milk and of suggest that, but that is like you know, it's kind of saying that if the value is nil, then assume that it's a managed one, but it doesn't make it concrete like. Where is that other cluster living or what is the information about that other cluster?

E

Whereas if you do make it a class object with some like Laughlin deferences, it seems it makes it concrete in the way that now we can explicitly look at that object and actually say and tell about the cluster that, yes, it is an external cluster that we are just extending and here's the some sort of a reference to where that list. I. Don't.

G

Think the distinction is managed versus, not managed I think it's sort of more like existing system versus new system right. So if you have something like cops or OpenShift or they already have an API, this represents what the cluster is then to have to replicate that information into another API object, because the common code in the machine controller, fetches the cluster API object.

G

Think that's that's the distinction.

D

Two obvious points like it's having the cluster odds. It's not like, like he said it's not about manager on my it is they we want the Machine actuaries to be able to do something, even if the cluster object is not present right now they cannot do anything at the raw straight-out rate is not present right. I think that's I, see that as a bug and this fixes that bug so.

B

Yeah I think the challenge here is: how do we represent the common information for machines that are part of a distinct kubernetes cluster without necessarily having to buy into all of the cluster CRD and control controllers?.

B

Well, not all of its provider dependence so like the API endpoint that you have to do to bootstrap a node into a cluster. Is not provider dependent and the same thing if you're I mean the pod and subnet ciders are less so unless you're talking about specifically being also able to bootstrap control playing instances and not just work or nodes, but we do need I think we do need to solve. How do we bubble up that kind of common information and still make that available?

B

Otherwise that needs to be replicated at the Machine level for every kind of machine that you have to create, or machine type object. So.

D

I can imagine a use case where you create a machine, so you run a machine controller and you pass in the whatever contributions that you have for that specific cluster as parameters, and you could have your actuator taking any sorts of parameters and that could it could take in those startup scripts as well. It could take in the bootstrap configuration or whatever is required at that point. Well,.

B

If you do that, then your you're, just limiting what kind of the scope of the machine controller is today, because today the machine controller doesn't limit just being able to spin out machines for just a single cluster, but it should potentially be able to spin a machines for multiple clusters. Yes,.

D

And in that case, you would probably want the coaster object, but if you don't have the coaster object or like it's, it just enables the use case. It doesn't prevent the other use case from it enables another use case and from the user. You define them because both are applicable and both can be done. I.

E

Mean I think maybe what if I understood what Jason just said and what you initially what you suggested here right now that you know maybe as a parameter to the controller the challenge with that is like yes, you can probably start one instance of the controller with feed information from whatever the accessor that you're extending. But then what happens?

E

If you want one more cluster to extend like then then you're kind of a nurse, but you can't do that because then you have to either run another instance of the controller with the new information, feed information or parameters, so to speak from the others. It's a second pleasure that you want to extend, which is not essentially you're kind of bounding yourself into operating into just one cluster and not necessarily more and I. Think that's what probably I think Jason was hinting correct me if I misunderstood Jason, no.

B

That's correct and you know it also limits you to not being able to really run multiple controllers. You know, in the same, you know cluster for the machine object as well, because you would basically be reconciling the same objects using different based parameters.

D

So I was just saying that I see those as two different setups and two different configurations of the machine controller, one in which the machine controller, the all the machine objects, are defined in one cluster and they are there.

D

The Machine controller is able to create machine objects for multiple clusters in that world. The other use cases that you have a dedicated machine controller per cluster right and I, see that both has valid options and valid configurations.

E

And I mean I think but having to make that choice like whether you're it's like you, rather than putting the controller to say you're earning as a controller you're operating in two different modes, and you can only have one or the other I would I mean. I would rather think that you know you should still run the controller in one mode. But, yes, you can realize both the use cases that will be ideal, I, think the most flexible and I think you know going back to the previous suggestions. You know.

E

Maybe if we can figure out a way to represent some common information, maybe not in the class of object. Maybe we can create a new specific API pipe for that, because anything even for let's say the extension case, I'm sure there will be some information that is needed by the machine actuators to operate upon. To basically add that to the X to the X. You know to use them to extend the existing cluster so any of those kind of common information.

E

If we can either with a new object- which you know not a cluster but kind of feels like a class but not exactly a cluster, but you can still create you know sort of a global pseudo cluster white object that you can then jeffer where you can put in some information common information and then you can operate in that mode. Where, then, you know you can have both a mode where you have a complete cluster object existing today, as it does and then another way where you don't have this cluster object.

E

But you still have that global configuration option or you know which you can actually use to drive anything commonality across the different machines that you want to extend.

D

So, as this is a little contentious, we should I think take it offline and talking have the discussion in the PR, and maybe we can mean in a later meeting to figure out what liner here.

A

Yeah, it sounds like a sound like that would be a good way to go. We're 35 minutes past the hour. We have a few humor topics to discuss it. I guess it would also help for maybe providers or provider implementers to take a look at at the PR and maybe in the PR we can call out. You know whether this this changes is, you know, sort of okay in an interim or whether you know merging the change. Somehow you know change changes fundamentally the the design and yeah go from there, so I think yeah.

A

My thing you had another another topic which is adding a provider ID to the machine status or spec, and using that to link machines and notes right.

D

So, on the so there's a PR open, I forget who opened it with me, see if I can pull it up, where someone was adding extending the Machine status to how to provider. Id I think it's five, six five! So right now the way we link the nodes and the machines is wired. Every annotation on the note object. Sorry on the machine object to tell it's it's funky.

D

It's weird I think it's added on the note object, and then it has a name of the namespace in the name of the machine that it's really relates to right. I.

D

We were thinking that it would make sense to, instead of using their arbitrary method to actually just use the provider ID that is defined on the node object tray. So if the Machine object in, if the Machine controller can add it in the status or the spec or the provider ID is we can write a generic controller. I have a working prototype of that which would link based on based off of that instead of an annotation I'm, not sure if it goes into spec or The.

D

Saturdays I think that's up for discussion, but I wanted to know. If that's something we want to consider. I can link to PR that I. The change that I have.

A

Any comments or objections, I think there's been a pretty sensitive discussion on the PR as well, so maybe I could continue there. I.

H

Guess I would try to summarize and see if people agree with my summarization as a sort of strong man type thing it feels like. Everyone is agreed that we should have such a field and it feels like the debate is spec status or annotation and yeah I. Guess that that's where I would stop and be like is that is that the case and then I? If that's the case, I think we just need to pick one and move on.

B

So if I was gonna say, if the argument is, is that we should be able to pass in kind of pre-existing machines, then it would definitely fit under the spec. Otherwise, if we consider it just something that is just kind of an artifact of the reconcile and can be recreated at any given point in time, then it should be status.

G

B

Think we should avoid annotations if at all possible and be explicit.

D

On your point, so, in my opinion it is, it should always be. We recreate able the provider ID, because the Machine actuators needs should be idempotent on creates, so they should be able to using the machine spec. They should be able to generate the provider ID otherwise, like they will leak resources, I.

H

Guess very much calling out another use case which is I want to adopt an existing machine right. First.

H

Which is valid to mean a little bit like I. Imagine I. Imagine many providers will not support that, but I imagine for bare metal. It is likely to be important. Maybe.

G

Yeah I guess the other thing mesm to point out is on providers like AWS, you get, you can get a provider IDs or some fields sometimes only on create, and then you can never get those values back again, and so sometimes it's useful to store those things in a way that when people are pivoting with the resources between clusters, you don't lose it.

C

G

Think VMware had a use case like that too yeah.

H

I, don't know we're talking about I, don't know what you were afraid wanting to dress, but.

G

I thought someone told me that maybe that's when you've created when you create a machine that it gives you back some information that you can't get later like. Do you only get on the Korea call?

G

Maybe that's not true. It.

H

Might be try to recall what that would be.

C

There's a as I know my only bid request, ID, but anything else on the machine should be yeah. You should be able to get it afterwards. Yeah.

H

The only thing I'm thinking of is like AWS I am credentials when you create like a secret, and you can see it once, but in that day right, but that might even just be in the UI rather than actual API calls.

C

But if you do that, then we have the talk.

H

Yeah I mean that's assume that there is such a thing in some other clouds. Maybe.

C

E

Mean one other distinction here is I mean yes VMware. You do have a use case where, for example, if somebody has created already a virtual machine, we want to import that I personally actually use that in a bit different way, but in our product family. But, having said that, you know one of the other thing. Is the provider ID? Yes, it is a unique sort of a unique identifier to point to the underlying VM, but, for example, I can talk about, for example, in be spheres in.

E

In specifically, for that case, we have the concept of managed object, reference or a moref ID, as we call it, which is essentially like the unique really the unique ID for a VM like 10:04 handler to the VM on the vSphere side.

E

Essentially it isn't- and this is not the same as what the provider ID, for example, that vSphere is needed, because the provider ID is more of I. Think is the UUID instance UUID. That is part of the guest OS, which is being populated up as a provider ID that is utilized by the vSphere cloud provider to get feeling things up.

E

So again, the provider ID, what I'm trying to take make is you know that may or may not exactly be the very string that all providers would use to basically say link me back to what the VM or the instance that has created to this I mean it might be two different things as well.

H

That feels prizing to me because I think the provider it is supposed to map like to their like. In the know, the cloud provider is supposed to map to a particular instance in the underlying infrastructure by the cloud provider right and it is specified by the cloud provider. But.

E

Yes, I mean essentially so okay, let me maybe correct myself or he phase myself as well I mean so the ID I mean so the modified II that I've talked about. So there are like number of base I guess you could say how can I look up a given instance on the infrastructure? One way is using that provider ID. That instance, you idea that we get that bear sighting.

E

Yes, we can also fetch the same VM with that ID if we need to that is possible, but we also have another mechanism in our infrastructure with vSphere, which we have as I said, modified II, which is from the IPE pointer, which is a much more straight and a direct connection to basically Phi's that object from the back as opposed to this the ID. Would we look up kind of a thing, so it's more efficient if we have the modified? Is that way slightly better, but again, yes, you're right provider.

E

Id still, yes, uniquely identifies the infrastructure like the VM on that back infrastructure. That is true, even in the vSphere case,.

H

I think I understand better what you're saying now yeah GCE. Where do you see? Pgce has a similar concept or they have note sorry, innocence, name and instance. You IDs and instan.

B

Cui these are the.

H

Better permanent identifiers, but instance names are how you actually pretty much things. I. Think I wrote right. Bobby say that one more time that GE has instance IDs and names, and instance IDs of the permanent ones, and for you IDs but instance, names are the primary querying mechanism.

G

Yeah I think most people refer to machines based on the name cuz. That's Kelso guaranteed to be unique within its scope right, but not across time, which is a problem right. A given point in time, yeah.

A

Alright, so maybe we can also continue this discussion on on the PR. We've got a few more topics, and it's about. We have about 15 minutes left.

C

I wanna try to be as quick as possible, so the revisit actuator is a larger issue that, like my all you to discuss, there are a few ideas, the first ones to rename the class structure to a control, plane, actuator and which would be optional, which seems like we need to discuss about that and maybe make the machine actuator like being like work, is specific and not like actually like spin up like lost control, plane and worker notes.

C

At the same time, and the other thing is to separate the like right now, like the Gloucester Schrader, as I was mentioned before, crispy PC subnets have load balancers, so we could have like a I, don't know cloud setup reconciler, which is a completely separate and again this would also be optional, because then we could also like use other existing technology like confirmation, terraform or whatever you want to use to fulfill the requirements of setting up a cloud environment.

C

So just want to raise some awareness on this, and if there are any ideas, please do add them to the issue. It would be great to have more use cases.

H

Nothing requires you to use the actuators today right so like you can you can you can experiment and make it an experiment whatever you want, and we would like everyone to come to the same or a similar API, but it may be that machines are that are similar in other and clusterings of dissimilar, at least for now.

C

I

C

Think it first is wrong, like I, pretty much I should renew you're like refresh. This is like introduce the control plane actuator instead of renaming the constructor ater, but the idea is also like right now. We have like, like control, plane configuration inside the cluster actuator so that, like probably move out if the cluster trailer is fulfilled as an interface.

I

So the activates provider- this is the cluster actuator for exactly one thing right now, that's not true. We also use the service and pawn fighters, but we depend on the each guy.

I

All of our machine and.

I

We want some of the machines to be controlled playing those because that simplifies our upgrade story later, where we can relax, it would delete individual towline note and then wait for another one that come up, but since we, since both workers and control playing those are represented as machines and since we coop apply all of these at the same time, what it means that grid is time when the control plane nodes are being created.

I

All of the workers nodes can't be created and the way that we determine when it's okay to start creating control for workers nodes is by looking at the API input. That's the field that we use to determine this. There is a control plane and it states to join.

I

So those are there's a couple different things here, but I guess for our implementation. I would prefer that control, plane, node represented as machines, and we need some higher-level concepts like cluster or control plane in order to represent the state of the control plane.

C

Yes, that's exactly like where I think like I was going for this.

C

It doesn't mean that, like the control pin wouldn't be a machine, it more means like the whole setup and configuration it would happen a step before even we have the same problem in the it up provider that like we need to wait for, for example, like the cluster trailer to finish before running the the the machine actuators and right now we do that kind of on our own by checking some of the parameters and not waiting for the first run of the cluster, but that's more dependency issue.

I

I guess my wonder, is why can't we just use the putter actuators for this separated out I.

C

Think the concept like at least like when I joined the concept it was very confusing. Then the cluster trader was set up. I mean we could create the control plane in the class structure at or sure, but the concept of creating also like a V PC subnets and, like all the other things that setup the provider.

C

It's kind of confusing for a newcomer, so I would work to like bring that logic out like something else and actually like set up the control plane on its own and make that optional for, like for other use cases that I don't want to a marriage control plane.

C

A

Think I think this early in the project right we're still alpha.

A

We yeah, we want to think about the naming, and you know if, if we're gonna be happy, you know six months or a year from now when we're pretty much, you know set in the way that we've named things and and if we think we might not be. You know that now is the time to know. Now is the time to reconsider so yeah I think I, think good to uh you know.

H

A

Good to think about this, and- and let's not- let's not you know just because we made the decision you know about cluster actuator early on doesn't doesn't mean that we can't we can't change, but we may not. We may not be able to change later on so.

C

Yeah just trying to raise awareness, the other two things that I want to bring up is just the control of runtime in those out it which also tastes to kubernetes 112. This needs to be approved. This also removes the said: dependency I'm, the makefile, which I mean for me like when I first pulled, cluster ABI was blocking on Mac and the other thing is. This is an issue in the SS provider and this fixes Jason's PR about shorts, again return on the cluster.

C

When we add a finalizer, this makes the first pass in the clustering machine on Trafford to fail, because when we try to update this the status or the machine or the cluster, the revision ID is actually already outdated because we updated here, but the cluster doesn't get updated. They object itself. So this fixes that issue and I wouldn't want to give time too.

C

David forget book I.

I

Only have a little bit to say about that, so so the current state of the guest book is that it's actually not online in life. The the problem there is that, in order to deploy it, you need a get sub module called sub tree which isn't available everywhere.

I

We have another problem associated with that, and that's this. Whenever someone makes changes to the gift book we have to republish and in order to publish you have to be able to push to the gh-pages branch- and this requires permissions that ideally, we wouldn't hand out to the world. So a task that I've signed up to do is I would like to have a CI job which will automatically publish the good book so that that CI job alone can have the correct permission and can have the right version of the gift modules necessary to publish.

I

So all of that said, the other comment is just this, especially with all of the changes that we're talking about right now. It would be great if people could take a look at the good book when they're making changes and see if they can keep the good book up to date with the evolving API.

I

So those were just my comments.

A

All right and then to wrap up I just wanted to ask if anybody's been attending today is interested in the generic provider, so a provider that doesn't target a specific cloud or specific infrastructure. Api.

A

David and I are working on a proposal. We expect to publish it next week and that's of course, when all the commenting and everything starts, but I just wanted to just to give a heads-up I know that last week a kookn there were a few people that attended the deep dive that Robbie and David gave and afterward. You know I had questions and we're interested in the generic provider so yeah.

A

If you're here today, you reach out I guess to to us on on slack and then, of course, the you know when we published a the draft- and you know all the comments. What will be will be looking forward to your comments. I would.

C

Love to participate great interesting.

A

Yeah, that's uh I, think I think that is that it is anything else going once going twice all.

B

A

With two minutes to spare calling it a meeting thanks everybody for joining for the lively discussion, please look at the PRS that we had discussed at length. The you know, machine controller without without needing a cluster object, PR and then the machine status or size provider, ID PRS, and you have the reviews at actuator, PR and then yeah anyway. All of them, please take a look and yeah have a great rest of your day. Hi everyone.

I