KCP KCP Design Discussions, 31 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Workspace Redesign Debrief 2022 10 31 08 02 GMT 6

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

B

Stormed and went through topics so so the result you will see it's basically from that meeting.

C

B

um So maybe just as a summary, as some new people are here, um the problem and I think there's a sketch here, probably is a problem. We we put into the cluster workspace system into the data structure. If you want, we need to have access to the parent through a number of things, just to know that a workspace exists. We need the workspace object or the cluster workspace object in the parent workspace to know that a user is able or allowed to access the workspace. We have to look into airbag of the parent workspace.

B

So there's always this reference as a parent and imagine the hierarchy of workspaces is distributed, so it's distributed over charts for sure and it might even be Regional distributed, so your parent can be in the yes. While the workspace is in Europe and that's a bad design and we we saw the struggle already before in some areas like virtual workspace implementation, we had it already there and we were thinking about ways to to solve that. Basically to remove this queue between workspace and parent yeah, so I'm not sure Andy.

B

Can you read what we have written there? Yes,.

C

I can because it's my handwriting, so um so we were we. We had several different topics that we discussed as we scroll through this drawing here. So the first thing that we were talking about was- um and this was something that is in the hack MD- that Stefan started a while ago, which is what, if we made workspace, which is currently a projected virtual resource, an actual thing that's stored in at CD, and then we take cluster workspace, which is the name for the the thing that is currently stored in fcde.

C

We either keep the name, or maybe we change it to something like logical cluster, but workspace would be the user-facing API like it currently is, so you would create a workspace delete a workspace Etc, but the act of creating a workspace would change a little bit. So you would say I would like to make a new workspace called Foo, and the first thing that would happen is that would we would generate a unique identifier to represent, should I keep going Serge or should I.

D

No, no just a small question, maybe also for the new uh listeners, but also to remind myself. Can you elaborate a little bit on the reasoning why the workspace is a projected resource and why we want to go like we're, storing it in a city directly, okay,.

C

So um today, workspace is a projected resource, uh because there are details on the underlying cluster workspace that we don't want to expose to users such as The Shard that it's been scheduled on. So there are fields on the cluster workspace that are system fields that we don't want to be visible, and so, when you go and you create a workspace, there is a custom rest Handler for V1 beta 1 workspaces, which implements the logic to create a cluster workspace on behalf of you as a user.

C

It right now you automatically by default, get scheduled to the root Shard. But you know you could get scheduled to a different one, and so we just hide the underlying data details. We would continue to hide the underlying data details for the most part and to a user. You wouldn't really know that there's any difference between a workspace being a projected resource versus an actual resource back to net CD it'd still be the same type of API.

C

um So the first thing that would happen is we would generate a unique ID, and this unique ID um basically represents the um The Logical cluster and there would be a scheduler that would create the cluster workspace, slash, logical cluster on some Shard somewhere, um and this basically represents itself or like dot in Linux parlance, and so it would contain this. This unique ID that was generated.

C

So that's the association between the workspace and the theological cluster and once the um once it's been scheduled and we've created The Logical cluster, wherever the phase of the workspace itself would move to scheduled.

C

um So this was the first thing that we talked about um and let's see.

D

So sorry to interrupt again.

C

Yeah, no, no! It's okay, I'm! Just trying.

D

To remember what else we talked about in here right to get an understanding so like essentially the semantic would remain the same. We would have like two things uh well yeah. We would have two things: on the one hand, side the workspace that the user isn't directing with and they think that has additional metadata attached to it, and that would be the logical cluster. The biggest difference would be that The Logical cluster would be created asynchronously using the scheduler, like literally.

C

um Actually, Stefan remind me: did we want? We want the new command to wait until it's scheduled or return immediately. We.

B

We already do that, like we wait for Readiness today, like the command in the CLI. It does that today. So nothing isn't there will change yeah and workspace, maybe to to add uh to your uh rewording. Cycles.

B

The workspace is basically um it's like a claim on a new thing, and it also it's a claim to keep this new thing alive. So if you delete the workspace and the luxury cluster options, are there on the right, the safe object and everything below, of course, in that workspace would be deleted.

B

um We also thought about I'm, not sure this comes later. Maybe there could be a luxury cluster existing without a workspace, for other reasons, like think of this Google Cloud Model, where you create an object, a document and it just exists right, nobody cares about the directory if that would be possible. So workspace is really just this one way to claim there might be three others.

D

I see so, but my hypothesis still is correct that The Logical cluster is created. Asynchronously, oh yeah, by the scheduler, slash controller that we want to introduce. Okay, all.

C

Right um I'm gonna skip down here, okay, so we had some discussions around homework, spaces and organizational workspaces. So um one thing that we said was well: we don't really need a user's home workspace to be under a root. It doesn't really need to be anywhere in the hierarchy. It's their homework space and it and the fact that we group homework spaces together under root users. Now is because we have to put them somewhere, and that is the most sensible place to put it.

C

But um in this particular model we just need a workspace that is homeless or parentless. Essentially, and as long as you know the like, where it is, then you can get to it um and.

B

So we talked about having we come to that, where it is in a second, so yeah.

C

So we talked about having some sort of secondary API to create a parentless workspace or or we just we need to figure out some way to say. I would like to create a parentless workspace so that that was one thing around homes and then for org workspaces.

C

Do they have a parent, uh like you know, do they all have to be under root or something it's not really required uh and that the use case that we're really needing to solve is give me a list of all of the the orgs or all of the like top level workspaces I can access and um I can show you uh in like Google Cloud console, for example, um if I log, in with my red hat account, I, see the red hat organization and a whole bunch of stuff under there and then, if I were in any other orgs which I'm not I, would see those and then there's another option, which is just uh projects that don't belong to any uh any organization and there's some um I think like k-native Bosco's things that show up for me.

C

uh Let's see where does a user need to or what? What is that right? Here, what just needs you need to? Oh: when does the user need to do something with an ID so that we were having a conversation around um if we generate going back up here? If we generate this unique ID? That represents a logical cluster and really you know the workspace has a friendly name, which is Foo and it has a unique ID.

C

Are there situations where the user needs to put that gobbledygook of an ID somewhere and um right now, the API binding has a reference to an API export workspace cluster workspaces point to a cluster workspace type, which includes a path. Cluster workspace type, exp extends other cluster workspace types, so, basically anywhere that there's a workspace reference, we need to be uh referencing either the um human readable name or an ID and Stefan had an idea around what to do with that in terms of resolution, if you want to share that stuff.

D

I mean sorry small call like correction I, think you or were talking about cluster workspace, pointing to a test. Workspace type, isn't that in the new lingua logical workspace, pointing to a logical workspace type, because I think we got just three yeah like.

B

Term I mean it's a: we need it on both sides, probably but yeah as workspace will have to type yes and everywhere. We, where we have those colon separated paths, we would resolve that to the ID, probably in that mission very early and stored in this pack and the user, they can use the ID I mean it's totally fine, but they can also use the other notation, and maybe it's a woodwork space which we have today.

B

It just has a ID root, nothing special, it's just R oot, that's the idea of it and basic notation is ID colon subtree right, so wood is not special at all. It's just one, one of those, it's a primary canonical root of the system, but if you want to reference something in your home, you just write the idea of your home, colon Something.

C

Yes, let's see, we also talked about like right now. The cluster workspace type resolution depends on the full workspace tree uh and we could, if you have a workspace and it is of a particular type, you would look in the current hierarchy. So, like I, have you know a b c like a is a parent B is a child c as a child and I'm going to create another child.

C

We would look in that hierarchy to try and find the workspace type that your cluster workspace type that you want, and if we can't find it there, we will have a platform wide or system-wide root hierarchy like Stefan was just talking about.

C

um One task is to audit uses in the code where we take a logical cluster name and get its parent, because if we, uh if we move to this model, trying we need to know what are the use cases where we need to navigate to the parent and then make sure we can accommodate those appropriately.

B

um And be able to probably we might reference parents some in some way like through a rotation, but we we talked about that. Like basically do we want a singularly linked list or if it will go into both directions for every path in the hierarchy, and this is task to look for. Parents is exactly for that to understand what we want.

C

So this bit of scribbling was about um how do we figure out which users are authorized for like an organization?

C

And so we were saying well, we could have like a group membership authorizer that lists one or more groups that are granted access to the root of a tree and that, um like working with an identity provider, to make sure that those groups get set up there would be. What did we say like we would annotate or something the yes.

B

So the idea is a question we had. We want an authorizer doing that which is basically like this top level thing we have for organizations today, but we bonded in some generic. We form like something you could use for other stuff like. Why can serious access his homework space right? Maybe this mechanism could also work there, so we talked about maybe using annotations or something directing the authorizer system.

B

That's a whole chain that there's extra group access necessary for the subtree or basically because it's wooden everything below so we could use something like that to generalize what we have today.

C

Go ahead, um Mauricio.

E

Just quick question, because I'm super new here to discussion and I guess that, like what I'm trying to wrap my head around is about how can like something like this, like a mechanism to track workspaces across different regions, maybe uh is something that it shouldn't be pluggable from day one right because storing this kind of information, maybe you just want to store it like externally and then have a way to consume it in which sort of information uh like workspaces and organizations right like in the example of Google cloud.

E

And what do you see on the dashboard there? That's I'm guessing distributed and again, like organizations can have projects in different regions and stuff. So it sounds like you will need some kind of like external storage to handle this channel.

B

When you come to the to the index, question I think yeah and you do. We have something.

C

We don't we'll come back to it, but short answer: there needs to be a global workspace index and that needs to be built perfect. um Let's see what we're talking about here are. This was the same thing.

C

um This was just more about like how do we specify the groups that are allowed to access, and we were talking about how like imagine we have this annotation. That says, like the Acme access group is allowed to access the Acme org, and this is an annotation on the root workspace for Acme or the acne org workspace and anytime. A child is created that information has to be copied and if we need to make any changes to you know, maybe the the name of the group changes or we add a new group.

C

We basically just need it to be eventually consistent and synced all the way I.

B

Think safety is a question about which you just had twice. If you put something on the root, you would be in the same problem again like you would have to look on some words. This can be somewhere else, so we have to distribute this. uh The special annotation in this case.

C

B

Something um Andy um I think we took for granted because we talked about it before, but for for new people, um the actual access inside of a workspace to operate, oh yeah, but whatever we just assume um this is totally done just done by in workspace Network, nothing special. Basically, everybody who has access to the workspace hierarchy in general by this mechanism, for example, buys a scoop. Then it's basically an authenticated user, but without any permissions.

B

So you have to put something into the workspace to give this user permissions and there's nothing like this access and admin special logic, logic anymore. Everything is inside everything is natural, normal cubic.

C

A

Yeah so I think this. This is where we come to the threads we discussed on the flag yeah.

A

We currently okay, we're building a hierarchy where we give a workspace access to their IDP user, like user logins to IDP at Cascade gvt token, and we just point them to the workspace with provision to them where we can play around, and the beautiful thing about the Heritage University is currently is that the role binding is granted by the system by our process to the inside of peer and workspace means that customer user can go wild in the workspace and basically there is nothing they can delete to remove access from themselves.

A

So they have to go to some other API third-part API, which we control to let's say delete my workspace or something in this model. We're talking now that if the workspace becomes self-contained, where the airbag some kind of either group based or user-based- and there is a different question that we didn't talk about user based, one here is inside workspace- we can get to the situation where you kinda can remove them. Just you can modify your access as a tenant to your workspace, I.

B

Mean we can basically use the same mechanism as with a scoop authorizer, to give you more permissions. If you want that, we can build it. Yeah.

A

B

Thinking something.

A

Like that, that's it's so.

B

So make it another annotation MJ becomes admins whatever you do. You admin in this workspace, so.

A

The organizational concept stays the same like we. We have had like these buckets of organizations, but- uh and this is where the air pack would be located as now, it is with access.

B

It's a different system, I think what we talked about is basically it's basic access to the subtree. That was a group membership thing yeah and we could add another thing like when it's uh user MJ or are you in some group whatever? Then you have other informations, it's a different annotation, a different authorizer which gives you that okay, it's like a union also either it's not a chain that just ended.

F

B

F

Top level authorizer and the org authorizer, what do they do in this new situation?.

B

That's just um you need extra group membership to access the whole hierarchy. It's Extra Protection, basically so I cannot. um So if I'm in company Foo and I want to give you Steve permissions for a nest that very deeply nested workspace today. I can't do that because you are not in proof in general, because the choice of the system and the thing is I mean it's special at the moment that groups there's a first level in the hierarchy and perhaps his property with the new system.

B

You would basically generalize that so, if you want it as a kcp, integrator put those annotations. If you don't like it, if you don't like annotations but have different concepts, don't do it.

F

And do we retain the idea of sim links.

C

Yeah we'll get there. Yes uh go ahead. Surges.

D

um I'm, so so sorry I just didn't get the idea with the group membership, but I can I can re-watch the recording as well, um but uh maybe if you could like give a tldr again, that would be my first question. Second question is at.

C

A time all right.

B

um If you want to only allow Tenon colon, better people to access the redhead hierarchy, we would put an annotation with a special format. We haven't talked about the details um on the root workspace, there's a root workspace, but the orc workspace method, which tells the authorizer to only allow those in who have the school membership and we would copy that down. Basically, the system would do that.

B

Every time there's a subgroups best created this annotation would be copied down and if it must be changed, we have to do a depth first search or something to update that. But that said.

F

Yes, can we delete the idea of an org workspace? What does it work.

B

C

We need to clean the code base of anything. That's called org, it's just it's.

F

At the root first places.

D

B

Workspace that is rootless. It's a rootless workspace, probably which the integrated inside has special properties.

F

Okay, so we we basically are saying that kcp the system on rootless workspaces, there will be an API to.

F

Have an authorization step above barback for all children, eventually consistent, yes,.

C

Okay, sergius did that make sense. Yes,.

D

That made that made much more sense, I um and why is it different from the roots, like literally the root and its children,.

F

B

We just say um we don't want to put everything under Woods. Maybe wood becomes more like something like a system. Yeah.

C

B

Like kcp system gotcha.

D

But the, but the authorizations, like um semantics that you just described, also apply to root or kcp, like whatever. We call that individual wood.

B

Is a generic normal workspace? It just happens to be called wood yeah.

C

I mean we, we could say, everybody has a read or whatever we want to do like we can. We can do the group membership or the group authorization bit or not.

C

um You know, I don't know like if we have a root level workspace and it holds Global stuff that generally everybody should be able to at least get into so that they can be governed by normal Cube rbac. Then we don't need to annotate it saying only these groups can get in, but on the other hand, if you decided like I, don't want everybody to have access in here, then you could do that. Gotcha.

D

Okay, that makes sense. Okay, cool. No second question: did you maybe have the chance, because we always talk about literally kind column, user objects and we I would say twice a week at the question as well. How do I give the service account from workspace one access to um do stuff in workspace too, um like I assume we are retaining or like we are keeping this very high tenancy boundary between.

B

These okay, very good. We don't use them for that purpose. If you want service accounts, your single sign-on system, whatever it is, has to provide those. Yes.

D

It has to provide technical users which appear as kind column user in kcp. Okay, that is yes.

C

um I thought I saw another hand, go up, I, don't see it up anymore. We any other questions.

E

I would just kind of like still like trying to get my hair around like the concepts like the question is: uh will it make sense to have like the concept of a workspace to be like region based so like you're, including like some kind of like sharding into the concept itself, so.

C

Every every workspace, the the workspace object, lives in one and only one kcp shard, the so like when I do Cube control create workspace, I Target, some kcp instance some kcp Shard, so that workspace definition lives in where whatever kcp instance I'm talking to so it's a.

B

Claim to be, besides the claim, it's not a definition anymore right.

C

Yes, uh I mean we don't call it a workspace claim, but yeah you're, basically saying I mean it's a request to provision. uh It's basically a request to provision a logical cluster somewhere and by default it will get provisioned in the same region and cloud provider as the parent, um but you hypothetically could ask for a different cloud provider or region, and this stuff hasn't really been built. Yet like we have the idea of like in in kcp today, a cluster workspace lives on a Shard. The definition of the cluster workspace lives on The Shard.

C

It has a URL that says the content like when you want to Point Cube control at this workspace. Here is the URL and it's entirely possible, but you have to jump through some hoops to say that the definition of my workspace and the content for the workspace live in two different places.

C

But for a you know, for a user like let's say that you have like your your it. Department sets up a workspace for your team. Like you work on team control plane, so you have a control, plane, workspace and then you need uh I, don't know some workspace for an app that you're working on, and so you create that workspace within that control. Plane, parent, your app workspace could be completely in some other shard.

C

um It really it, but it's meant to be fairly transparent. Like you use the plug-in for cube control, and you say I would like to switch to this workspace and you don't really care or have to know where it is.

F

What's our straw, man for um availability.

C

uh In terms of what is.

F

This chart or crushed you or whatever, on that hob to the child. You.

B

It's a whole. The whole idea of being self-contained is so I mean it's a most important answer. Right, a workspace keeps working if there's a reference to it. It keeps working even when.

F

Everything more so like what Andy was just saying: I created a new workspace for my project. Within my team. It got scheduled to Frankfurt uh the you know: fiber optics between the US and Frankfurt got cut now, I can't access my child like to what extent do we want are straw man for availability across Network destruction to be contained there.

B

For the moment, I mean, if I put this down, you don't have access, we can talk, it's completely different topic and we had some chats about that. We could talk about special workspaces which are globally available like cross region.

B

It has consequences for latency, supports and everything um different topic, but we could have a region basically, which is across region actually um for those use cases where it really matters.

C

B

You have a highly consistent, um basically a workspace for your application, which must always be available where you actually, your most important data, put it on this special region, which causes Azure cloud provider, regions Yeah a.

F

Different topic- yeah I, wasn't thinking like necessarily that as much as.

F

C

We're not trying to make an individual workspace highly available outside of wherever it is.

F

Right, yeah I meant more so, like kind of a foot gun for users to be able to put their work across different regions like that. If, if they somehow need to access the object, I don't know thinking through the cases of the workspace is functional. But I can't get the object to find the url to talk to. It seems kind of annoying.

B

C

um Workspace index.

B

This index and we always store so everything which is persisted, should be um the ID based uo, which means, for example, your workloads. They will talk to the ID based URL, so they.

E

D

B

C

Also makes movement a whole lot easier because.

B

C

Hierarchy is entirely virtual at this point, makes.

F

C

Yeah, so we had some sketches here, uh speaking of like uh human, readable names versus um not and like issuing 302s, if you ask for the human readable name, you would get a 302 back to you know. Whatever the idea is um yeah, we talked about like we need to figure out for quota roll up, how to do that in this type of model.

C

We thought- maybe we could add, like if you're trying to do upward, traversal to get to a parent. Maybe we add an API endpoint where you give it an ID and it spits out a parent, because if we, when we build this Global workspace index, it wouldn't know all of that.

B

B

If you list all logical cluster objects, those LC objects here and you have a global picture. That's what our font Box is doing. Super naively, of course, not persistent anything, but if you do that, you have the complete picture. Okay, so you can, by watching all charts you can get the whole hierarchy memory at some point. Of course we want to store that and replicate it and everything, but this is enough, so everything we lose on the lower level data model we get back when we text a big picture.

C

um So we you asked about Sim links earlier. This would just be a new um API resource schema. Where you can say, I would like to create a workspace link, and that would you know it's basically like a Sim link, so we'll have to define the data model more.

B

Fully so it's maybe a Boolean in the workspace could also work right, symbolic, one.

F

Yeah I guess: why is this different from the workspace subject? Doesn't.

B

C

Doesn't have it's.

B

Just not it's just not defining the life cycle of the.

F

Virtually impressed.

B

That's the only difference, yeah.

F

Oh, it's not. Okay,.

F

um Wait: I, wouldn't why? Wouldn't we do ref counting on these? The same way we do like should I be able to do the logical cluster. If there's links to it, we.

B

Could also do that they have possibilities. Okay, that would be symbolic. That would be like the heartling pattern right and Phoenix.

C

uh We basically said I'm gonna skip over some of this stuff. um We said that deleting a workspace was basically the identical to the process today, uh except if you're trying to delete a root. uh Like the you know, an org workspace or whatever a parentless workspace. We need to have some special way to do that, and we didn't really resolve that.

F

So quick question on the deletion bit.

F

We're taking the approach we have now that's controller based because we want to honor finalizers on objects inside that my cross workspace boundaries or be because like to the outside right. It's.

B

Always local, like the controller local answer chart, we do that and then find another logic, basically to synchronize. Okay,.

F

And then what's the requirement for deleting a roof.

C

Well, you, basically, you need to be in the the parent to delete the child, but if, if you're trying to delete the root, it has no parent. So we need some some convention that indicates I'm trying to delete a route and.

B

It depends, I mean I, guess the user shouldn't delete the homework space, probably or maybe he should I don't know. What's.

F

Foreign I guess I'm not entirely clear on, like so I have a root list for a root workspace or whatever, and it's got the logical cluster self inside of it. Where would the workspace objects for that be.

B

That's the question is none and you cannot access the grocery cluster object.

F

Oh and we don't have okay, so okay,.

B

So we need to weigh somehow if we want such a behavior, we need something yeah.

C

So we just need to figure out how to do it. Okay, and that was what we talked about.

F

C

That significantly.

F

Different from our previous conversation, no.

C

This was just fleshing out. This is just flushing out that the hack MD and going through some additional things yeah, so the the benefits. Just to summarize, we don't have to look at the parent anymore to figure out the permission model for the child. So it's an efficiency in terms of like quarter magnitude.

C

um We make it much easier for people to set up our back for their own workspaces, so they.

E

C

Need to go to the parent to do it anymore, where they may not have permission, and this allows us to have a much more flexible set of hierarchies. Instead of just a single one.

F

In what case would we in what case would a client not be able to provide us the you would or a reference I'm trying to think through, especially if we have Sim links the problem of dereferencing, a particular user's semantic name into an ID, might be tricky and or require a bunch of data?

F

When would a client not be able to just do that for us?

F

Why would we want to support that in admission.

C

You mean resolving a friendly name, yes, I, don't know, I think it deserves some thought exploration.

B

Why not in acquisition? Why not store yes,.

F

Very sorry, I'm thinking through the case Stefan, where, if especially, if we have SIM links the problem of dereferencing, a user's semantic name, a pretty name into an identifier, may require a bunch of data like context dependent data about who created the request. Etc.

B

F

Well, if I have a SIM link to a logical cluster in my home, workspace yeah and I create a new binding with a reference to that Sim linked workspace. You need to.

B

Know that right, I think we didn't even talk about the Deep. Okay, soil being right, I mean yeah. Maybe if you want that I didn't think about that. It's more like for um for the plugin Cube pattern, ws and then you enter something.

B

Gotcha so very simple:.

B

And I mean in every office references we have to think about, I mean the question you just asked about deep references and whether logically is an influence should physical description in the beginning, like on creation, because then it's basically fixed even on movement of workspaces, but maybe there are also cases where you don't want that I don't know.

B

And also Sim links, we thought about the feature in Google Docs. You can see the recent documents right so something like that you could create those siblings in your home directory right home workspace.

B

Just have a recent workspace have siblings in there.

F

That's like a side effect of the key control workspace use command.

C

Drawing like whatever yeah.

F

This is an STD web for anyone. That's deployed kcp, oh.

B

We talked about that Andy. What do you remember at the end.

A

C

For any existing cluster workspaces, we assuming we created a new like logical cluster type, and you know where we're basically renaming cluster workspace. We could copy over the existing ones and instead of generating dynamic or random IDs, we would just use the pre-existing root colon whatever so.

F

I'm going to be confusing forever.

C

So so, like Legacy stuff could remain um if we wanted to try and avoid a wipe, yeah.

F

I think that the overhead of remembering that forever would be.

B

Postpone it's actually revive, like so authorization we can Implement now yeah yeah, so that's nice, and if we need two months complementation, that's fine.

F

Oh and then this sort of I think solves or not solves, but it reframes a bunch of the traversal questions in cluster workspace type. If you have disconnected trees.

B

Yeah, at least we need something like a jump to Awards I mean this opens a current one. If you don't find it go to the woods.

B

So it's different, but not super different.

B

Maybe one one thing we didn't talk about, we so to to make dot dot possible in Cube cattle. We will like these stores uh logical, the colon notation in the good config and just use that for dot dot. So it's purely synthetic syntactic operation.

B

So when the client knows where it is and the hierarchy can go backwards, basically that.

F

If I have a directory with a Sim link and ICD into the Sim link and.

B

I do something yeah, I'm, not sure I would say. The group sets of Steve to work out a consistent and understandable model for some links.

F

Cool it sounds like a good sounds like a good refresh.

C

So yeah I think next steps here are either writing up some more formal designs and um tasks or just start prototyping. Some of it and I mean for prototyping up. You basically have to disable a whole bunch of things um so that they don't get confused and then start to re-enable them piecemeal.

D

B

Mean we can keep things working and like we keep the cluster workspace, for example, and we add to the luxury cluster thing to activate it. It's not effective.

B

I think this is possible, maybe.

A

B

We switch the workspace to a real object in this moment. Maybe we have to do something.

B

And that's maybe the only hard change, I hope.

F

Can we delete the workspace of the service.

B

Yeah projection goes away, oh and and also.

C

What about the machine, but we we still need a rest Handler for it, for what, for posting to a workspace.

F

Is that not backed by a.

B

F

Api hi sweetie.

B

It's your normal API. It's not some special.

C

But didn't we want to wait until the workspace.

B

Oh wait: where are you taking this client-side there's always dreamed by inside.

B

C

You're talking about in the plug-in sorry I was thinking.

B

C

B

No I think it's already outside corners, so we can just keep that.

D

D

So what are the next steps.

B

Any expression was whether we need more concrete design right.

C

Yeah I mean I think this could very easily easily be something that some folks just start to play around with coding, or we could spend some more time like doing slightly more formal, write-ups and I'm, not talking about like 20 Page proposals or anything but just start to flesh out in a Google doc like we need to make this change, and here are the implications, etc, etc.

F

We do have the nice property today that everything is under root, so we could also just hard code a check that says: hey. Is this workspace under the root? No I'm gonna completely forget about it and then the prototypes can live in their own little bubble until they're, ready.

C

Yeah I mean we could even have like a workspace, 2 type, that.

A

C

Does this that, when we're confident that it works, we just rename it back to workspace.

B

I would start with certain types we have and just maybe, for the ID. We use an annotation to stop this.

B

It's empty I mean works with GMG, that's just yeah I think.

C

um So I guess Steve. Do you wanna, try and put together a mini plan for this? Is it too distracting, and you want to just wait like what's your feeling.

F

um I think I can try to capture like the big picture objectives in some Feature Feature issues on GitHub.

C

F

Probably had a low granularity level that makes sense, that might be the most.

F

And then, if we want to do more documentation, I think the hack MD is probably a good place for it.

A

D

Little stuff thank.

C

You, for the other, um we'll look to you to file some of that stuff and then, if we need to have a sync up again, we can do that.

F

C

Sounds good okay, cool thanks.

A

Thank you bye. Thank you.