KCP KCP Community Meetings, 9 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: KCP Edge Community - Explainer Series - Edge Placement

Description

Mike Spreitzer, in the March 7 KCP community call, talking about a draft API for saying 'what' goes 'where' in KCP-Edge. You can see the code at … github.com/kcp-dev/edge-mc/blob/main/pkg/apis/edge/v1alpha1/edge-placement.go

A

So um so in the in the uh Edge MC repo, we do have a package for apis. We have an API Group called Edge uh and in the V1 Alpha One you will find Edge placement.

A

um So the idea here is that this is. You know we started with the TMC placement and um made the changes that we think are appropriate for Edge, I will say just sort of qualitatively the um the biggest one is that it is multicast rather than any cast. So like the TMC placement, it has what I call a wear predicate that selects amongst possible uh in in our case we call them.

A

Edge clusters or I may speak more generally of destinations, um and actually this is in particular in service, uh we're doing a proof of concept um that he has deliberately Limited in scope. uh We're not exploring all of our ideas, but we are exploring some of them, um and this multicast is definitely one of the ideas we are exploring. One of the things we're not exploring is uh the possibility of multiple Edge clusters in one Edge location.

A

um We do have a more particular usage of vocabulary here um and so, while TMC I think has a very general uh potential use of the location concept um or data structure or object type, um we're actually poaching on the sync Target and location from TMC, uh but we're giving a particular interpretation to location uh one, that's natural for Edge, uh you know you think about Edge locations um and in general, education can have multiple clusters, um but in this case in this PSE uh we're saying it's one to one so there's a one-to-one association between sync targets and location in this POC uh and this interface with us at this level of development um anyway.

A

So a uh the where predicate, which uh so you know as usual, one Edge placement right. It's got a spec and a status and in the spec there's a where predicate, which is a uh you know like in TMC. It's a slice of label selectors um over um location objects, um I'm not entirely clear on whether and what, when in TMC, I, think in TMC it's it's a selector on sync targets, but I think uh it makes well.

A

It doesn't much matter here because it's uh one to one but I, think it defined it to be a label selector on location objects um and then, as the spec also has, of course, uh as it's it really this this. The placement object here is a binding between what and aware right. So the wear is similar to the TMC placement, but it's multicast real in any class anycast of what we started with the this.

A

What TMC has which is a label selector over name spaces, but we also want to be able to handle non-namespaced objects, so there is additionally, a slice of references to non-names-based objects or or selectors really, and those are in terms of those are identified by API, Group and resource and potentially some names or some label selectors to identify the individuals of that API, Group and resource.

A

So that is really the what and the where in an edge placement. The other thing I'll say about Edge is a difference. Let's see somebody put their hand up and I'll get you. Let me just say one more thing: um in TMC what has to be transported is relatively bound and known at development time, because in TMC only the computation gets moved and everything else stays behind at the source of server in edgemc.

A

We want to transport everything and produce self-sufficient Edge clusters, so the set of things that have to be transported is not known at development time.

A

um So I'll stop there and ask for questions and I can't quite see in this format who raised their hand. Let's see, who is that that'd be dated? Okay, David.

A

Go ahead, David.

B

Sorry that was muted I was just saying that um yeah, what you mentioned about um non you know being able to define the what um pero source and not uh per namespace I think we already have an issue for TMC as well, because there was also the requirement to possibly Point directly to some resources and not uh you know, stick to the namespace scope in terms of of defining the what in the placement. So that might be interesting.

B

You know at least to have something you know um converging or or consistent here that we have the same on TMC, but we didn't implement it. So.

A

Please do review what I've drafted here and tell me if you think, that's appropriate or if you think something uh different would be appropriate to converge on.

B

um We might you know, take from what you you need as well. I mean I, don't know just just mentioning that the the same need exists on both sides. Obviously,.

A

Very good, thank you. We have another hand up uh mengirdus.

C

Okay, so I remember: two Community meets the ghosts.

C

Capability to deliver their objects, but not to act on them in the kcp cluster like airbag, for example.

C

Yes, I was wondering: is this still a path to go and was there any considerations to do something more like uh Helm stuff, where you just object, encapsulates a different object or list of objects, and just a little bit of those like I'm, just interested? What's the thinking overall, on this.

A

Yes, yes, that's a very good question. It's a question that we've struggled with um you know we uh I went back and forth uh throughout last year on this. uh It is definitely a possible way to go. um You know the the way I characterize It is Well.

A

The way I would put it is uh you know in edgemc you need some kind of a container for the description of the workload and the question is: do you use as your container a kcp workspace or in general, a I describe it as a denatured, API server, um you know, that's one kind of path to go and the other is to define a container object type and you can find other projects that do that. uh For example, ACM has defined a container object type.

A

uh Another way you can go is uh in some sense delegate. So git Ops is all about saying, oh well, the container is git rather than anything in kubernetes, the the.

A

um So that's that's another way you can go and in fact my first proposal for Edge MC last year was exclusively focused on git, Ops and I was proposing that we adopt git as the container and people said. Well, that's great for some use cases, but not all so I want something that is more generic and works with the whole kubernetes ecosystem.

A

So that's why I went with uh the container is something that looks like a regular kubernetes, API server uh and then the consequence of that is that it has to be denatured because it has to be only a container. It needs to not process the objects it needs to just hold them, because the actual activity on the objects needs to be happening in these independent self-surgent self-sufficient Edge clusters, not in the central place, that's holding the description.

A

So is that a reasonable answer to the question.

C

Yeah, it makes sense that wouldn't be my first option to do that, but I think it's like. If there is some is this: what you're, showing is the current architecture document or something I could drop some ideas.

A

So um there is an outline of this POC um that is merged in the edge MC repo that you'll find that there's a docs folder that has a subfolder for this POC.

A

um We do not currently have um like a PR, that's discussing the overall design or architecture, um I believe Andy. We do have do. We have a mailing list.

A

C

Yeah I know if it is.

D

For that- and we have our kcp-edge.io I'll just add you to it now.

D

Okay, I guess is where all our docks are located, that describe the interfaces and the and the uh demonstration that we're planning, cool.

C

Okay, we'll not take more time, move the conversation there. Okay.

A

um Let me move on to the status, so um the status uh right now is um very preliminary and spare um it's just uh tracking the generation of the spec and the number of um locations that matched um in general. The uh problem of returning um reported state from The Edge uh extends well beyond this object.

A

um You know we have a fundamental problem in kubernetes um which connects to the previous question. Actually, the the kubernetes object types are defined on the assumption that, for every object, it's basically going to have one running or used copy, um and you have to set you know for every desired State there's one reported State and that there's a status section. That's these data type is designed to report on one of them, uh but in this multi-cluster world, where you're explicitly about this is a prescription for many of them. That data type is not appropriate.

A

So part of the edgemc problem that I'm not trying to present our answer for now is how do we deal with these multiple reported States I'll just say briefly, uh there's kind of a two-part answer. One is you can try to return all of the reported States and keep them somewhere?

A

um The kind of the in-spirit of answer is a separate objects, so this POC has mailbox workspaces in the center so for each Edge cluster there's a corresponding mailbox workspace in the center that has all the objects, and so the individual object reported State can appear in the center in the mailbox workspace objects, but back in the original description, which is not mailboxed, um there has to be some kind of summary then, and so there's this issue of how do we prescribe the summary?

A

How does how does the user Define, what kind of summarization they want? I think it needs to be programmable and what representation? How do we write a generic representation for this programmable summarization, but the results of this programmable summarization?

A

um So that's more of the reported State answer, but I didn't want to get into that here.

A

um Okay, other uh thoughts or comments.

C

Is this in a pull request for comments or is.

A

It already in the repo mic. uh Yes, this interface is in the repo. um Of course, it is all you know in some sense, in in spirit, you know a draft in progress right, we're working on a proof of concept, so nothing here is carved in stone. uh It's all subject to commentary and revision, um but since it is not in a PR, uh perhaps the best way to comment is uh to the mailing list or to Slack.