VMware Cartographer Office Hours, 13 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cartographer Office Hours - Dec. 13th, 2021

Description

00:00 Intro and updates: Office Hours paused for the holidays, resuming on Jan 10th
00:52 Updates on RFC process from other OSS projects
05:36 RFC 12: Discoverable Input Fields
19:37 Reusable templates across workload/deliverable

A

Hello, everyone welcome to the cartographer office hours today is december. I'm sorry december, that's 13 and um well. This is the last meeting last office. Hours meeting of the year will be recently on the second week of january and updating the calendar accordingly.

A

So with that, let's get started.

A

um Okay first thing will be the note taking role. I don't know if anyone wants to volunteer or want me to trigger the will of names.

B

I have not taken nuts yet so.

A

A

Thank you. Okay. um There was before this. Let me put here.

A

From previous meeting there was an action item, it was checking out cncf project.

A

I've been checking some well several cncf projects, their contributing guidelines, governance, docs and all that the rfc process is not especially widespread. It's interesting to see very large projects that leave a lot of the criteria to use what is a large change to the contributor or just to ask a question in the slack channel. That's it so it's uh interesting to see that that we have an receive process.

A

I I found nevertheless the grpc project, a very large project.

A

They have also rfc process, and here they have some criteria to see if the the change you're proposing actually fits into the rfc process, uh features process changes anything that changed the public api also is considered something that falls into rfc criteria and it's interesting because I I also explore some projects outside the cncf umbrella. For example, react.

A

They also have a rfc process in place and again the word feature is there so kind of the common thing between these processes is that if you are planning to introduce a new feature that also changes the public api, that's something that goes under the rfc process, also well removing features and uh yeah, for example, for react, introducing introduction of uh features or some other functionality that involve multiple languages.

A

Also, um it's part of the rfc process. So it's just information that could potentially be useful for the rfc process, improvements that we were discussing last week so just wanted to point that out.

A

Okay, uh before.

C

A

C

um I mean that's good information and I think I think for us to get some action on this.

C

We have an issue to document the rfc process yeah, but I feel like we should propose the rsc process and that work should actually be done, maybe as a part of that story, but instead of the story being I mean it can either be an rfc so that we make sure that that's how we ratify it, an rfc itself or we put something together on that issue, but we make sure we bring it to a public meeting next year.

A

Yeah, maybe yeah, okay, so yeah, I would say the action item will be to update the issue. I don't remember the issue number, but oh, I can find it. Let me see.

C

It was an early one for sure.

A

Well, I I can. I can update that later on.

C

A

With the number uh the rs the process issue, with uh earnings from other projects, let's say.

C

Well, I think, with a I think, with a proposal that we should bring.

D

C

D

C

Update it with a proposal or create an rsc off of it that we should bring to the group. What do you think.

A

C

I just feel like this thing will never really get done until we've won try to document what it should look like and then get some argument about whether that's acceptable as a first stint at first go. What the rfc should, how you should pose an rfc and what constitutes one.

A

A

Cool uh anything else or we can move to the next item.

A

That will be rfc 12.

B

Yeah um yeah: this has been hanging out for a while uh and.

B

uh Josh- and I ended up talking about it uh recently when we're doing params, because the new implementation for prams means that you no longer have to specify at the top of a template default values for params.

B

If, if there isn't a sensible default, just align it and expect that the workload will provide it or the supply chain will provide it, um and uh while josh thought that that logic made sense, one of the things that we lose is well. The necessary parameters are were previously self-documented. You can just go and see at the top of the spec, like here all the parameters that are required and uh instead of the time. Well, you know this. This is much more sensible and also much more comprehensive.

B

There should be some reconciler, that's just going over to every template. That's submitted and using its great machine brain to be like. Okay, here are the things that are required in this template and just put them in an easy to read list down at the bottom of uh down in the status of the object.

B

um I've put an example here, that's kind of like a nested structure. It could also just be a flat structure, so every place where you see uh you know where you see it at the top, the template. It says service account, name, workload.spec.service account name. Maybe we just put that entire string down in expected inputs right now. I've got a nested structure, but I'm not tied to that um yeah. Pretty straightforward.

C

So I would like to see I mean because I I don't know if you remember, but I told you I had a dream of this and then asked about it and he says: oh I've got an rfc open on it.

C

So I would like to see the defaults on ones that you can supply uh alternatives, so parameters that I can fulfill is more useful than parameters that are required all right. So if they have defaults if, but they can be overridden I'd like to know about them as well and I'd like to know what they default to so I'd like to see that added does that make sense.

B

um Yeah, the second part is I'm trying to think like how to best.

B

Yeah, I suppose every parameter would just be a list of both the parameter name and then the parameter default.

E

B

Yeah and I assume that we omit parameters that have us.

F

B

Isn't yeah? uh Is there such a thing now.

C

You can override.

B

C

B

You can write override everything in a template. I guess the question would be: do we presumably we're going to build on this work and have a have a similar status on supply chains for the oh? What's this.

C

Status, this is just.

B

I think this is just on the template. I'm trying to put.

C

B

Myself, because it would be valuable to have it on the supply chain as well. I guess.

D

That's more important to me.

E

D

I'm missing the value of putting the inputs on the template because, like as it reads right now, I'm reading all right input workload metadata name, but I can see that 10 lines up.

D

You know in the template, so I guess I'm I'm, I'm not understanding the value.

B

uh So it just comes from, like I said that conversation that I had with josh that his his perspective was that he would want to have that easy to read list and not have to go through and parse the template.

B

So that's the value there. The second, the second order value is that then, when you have the supply chains, reading these and putting status on on a supply chain that you uh can parse this easy easy list instead of having to parse each individual template, it has to be done at some point.

C

I actually I should have kept this. I should have kept the branch I did a. I did a spike on this and it's it's fairly easy with the tooling that you created to extend it to not need this on this document to get the supply chain documented. I mean because.

E

C

Really quite straightforward code right, so I definitely want to see it on supply chain. I didn't realize this was on the template and I propose that when you're putting together the supply chain, you throw in the templates, you want, you apply it and you go. Oh now, I've got my list of all of the parameters I might want to override or fulfill, and the documentation is done there where it like, where I think it'd be most useful to me as a supply chain.

C

D

C

Think it'd be better on the the first place that I'd look would be on the supply chain status, and I also would really like to see this on the workload. If that doesn't break some, it doesn't break some kind of like.

D

Permission privilege.

C

Missions yeah privilege issues, yeah yeah,.

D

C

Too, I'd like to know what what parameters are being waited on for me to be successful,.

D

Yeah, I think that makes.

C

D

Sense to have it on the supply chain, like so.

F

I'm still, I'm still missing the value because, like.

D

I'm not saying like you are 100 behind this idea and think, like you.

B

Had a conversation with.

D

Josh great but like it's the it's still the template author, who wrote this in the first place so like they put the inputs there.

D

That's all that are the the inputs to consume.

C

And then the operator has a little bit of work to do. I think that's what josh is probably saying right. The operator has a little bit of work to do when he goes to consume. He she goes to consume this. They say: what's the um what's the parameters, I need to fulfill on this and I feel the most valuable place to document that is in the supply chain.

C

What it does is it assumes that people develop their supply chain, iteratively, applying it back onto a cluster, with the templates handy to see what the results are, and then we get a nice resolving list of all of the parameters that are or need to be fulfilled by the supply chain.

B

So, to be to be clear or to clarify over the top summary says, templates and supply chains should report in their status. What input fields are expected from workload, so this is no way is meant to exclude supply chains. Doing that, and I can certainly write up an example of like here's, how a supply chain would do it.

B

um I think that so I then have two questions, because one question that I was coming in with- and the reason I put in the example- was: what actually should it look like, um and what should that structure be, uh because I'm not totally sure about that nested structure um and the now I have a second question of arf are other devs saying that they think, including this.

B

These input fields on the templates is unnecessary. Work that we shouldn't do that work, or are you saying, let's do that work, but also, let's totally make sure we do it on the supply chain, because I don't disagree like.

C

We start with supply chain personally yeah, that's what I'm suggesting I'm suggesting start with supply chain and if anyone ever says on the template says they'd really like to see it when they apply it, then let's do that work, but where huge value comes into my mind is in the supply chain. It will make. It also help I'm sure I'm totally hypothesizing, but I have high confidence in this hypothesis that anyone trying to build uh visualization or assistive tools who would find the one on the supply chain very valuable.

C

I don't underscore that yeah yeah um looking, I mean yeah, and I definitely want to see the default values. I didn't even think beyond parameters. All right, I think you might be. I think it might be easier if we you were talking about the structure, I think the structure could just be exposed as keys like the full key that you would normally use in a in a template style template a dollar parens template that key would probably be them more than adequate.

C

So when you say keys, you want, you were talking about the structure so.

B

I'm saying flattened.

C

Flattened, like you, suggested, with the the keys being like spec dot. That's all right, not spec, dot, um workload, dot, something or other nice.

B

C

I mean it's just an opinion, but I think easier for machines to work through they can decide whether the structure is important or not. My only concern is those would never have defaults right, so you'd never mention default. You just do value.

C

Oh, no, you just mentioned the name and you wouldn't mention the default value for it. I should say so.

E

So some of those like workload.

C

And um input all right.

B

Yeah so uh there's one thing in terms of.

B

uh The status that we have here uh talks to sources. I guess that goes away like because the supply chain uh splicer need not specify to someone to the workload author, like here's, here's what values I'm passing between, so we're just looking at a list of the workload essentially metadata, spec params.

C

Yeah, can we generalize the other thing I'd ask is? Can we also generalize the language, because this is true for blueprints and owners sort of thing not like blueprints instead of supply chains, now that we've got names for them.

C

Very keen on this idea, I think it will help resolve. What's going on.

C

And then I'll be really curious to see if we'd like it on workloads and uh deliveries, deliverables.

C

But that could definitely be a separate.

B

So the idea would be that the workload would pick up from or just.

F

Trying to get like.

B

Early early validation that the first, like the first thing through uh before before, starting to stamp, I think I can see if you've provided all those values. I think.

C

Beyond the status.

B

C

Don't think it's the provided values that, like I know that we say hey, we didn't get this value, I'm also not sure if we list all of the items when we mess. So when a workload misses like there's, five params right and three of them must be provided. They don't have defaults all right and if you missed the first one, I'm not sure if we bothered to list all three.

C

So this is a way we could ensure that we list all of the ones that we should have provided, but we can also prov list the ones that you would never get a warning about and would never learn about unless because they have defaults on them.

C

It's just there's a broader discussion, then about do we want to expose these. Do we have to have hidden or something else going on.

C

I hope not, but.

B

Yeah, I think that my expectation would be if you are providing a default yeah.

F

B

You are expecting your users to and.

F

There's no way you would do that.

B

F

If you're not allowed.

B

um Change the rfc to focus only on supply chain.

A

Okay, great thank you now it looks like we should move to the next one. You agree reusable template.

C

Okay, so this one is simply that uh those params we were just talking about the ones that come from the uh either the blueprint, sorry, the uh workload or the deliverable, um if I'm writing a template that is capable of doing something that would work just as well in a delivery as it would in a supply chain.

C

I I cannot be reused today because I would type something along the lines of especially if I was referencing the owner, so I might type workload.name to create the name for my object and then you could not use it in a delivery, because you would have to be delivery, dot name, and so I would prefer that we just genericize on owner, even though people aren't entirely attached to owner it's what we have today, it's in our docs at the moment.

C

We could always rework that as well, but I think it's a separate issue from the fact that there's no reusable term.

B

F

B

One that totally makes sense to me, I assumed you say we could just use an alias. I assume that you're saying like yes, let's use an alias, let's not remove the ability to reference a workload, but rather the ability to reference owner.

C

Yeah but I wouldn't document the ability to reference workload and supply chain. I would just expect people to reference the owner, and um I mean we don't have backward compellability concerns at this moment, but I know people already using it. So in this case I'm just like: let's be kind, let's just use an alias.

B

Yeah, I think I think we mostly do have backwards compatibility issues now, because if we, if we make a breaking change, we'd have to cover this.

E

Counts as a feature.

B

We'll be a breaking change and then we'd have to cut a release right and.

C

We have to cut.

A

A lot of releases.

E

C

Yes, because people are already depending on us yeah, it's true, I mean we might put a little note, but I don't think we'd put any focus on it in the documentation to go with the story.

C

I don't know what I meant about the compound naming thing there. I really don't know if anyone can think of a problem when there was a delivery in a workload in the same namespace.

C

Oh, I think it's because there's a template that could then emit an object that decided to name itself based on the owner's name, and it would now have a problem of omitting. It twice sounds like something I can put in the documentation.

C

Or is that I mean it doesn't fix anything right because I bet when you make the other. I bet if you made the other like if you made a template and you went oh, this only works with supply chains because it references workload, oh and they're, going to need it over there on delivery. I'm pretty sure you would create that template by copying it renaming the the one ref and then renaming your template and completely ignore the same problem, which is oh.

C

If anyone tries to use this in the same name, space we're going to get a name collision all right.

B

I mean: would we get a name collision because it's totally mediated by cartographer? So if you have a yeah, if you have a workload and a deliverable in the same name, space with the same name, uh the supply chain, reconciler is only going to look for the workload and the the delivery.

C

Objective will collide.

B

F

I think, like you said that.

C

That's what I was saying yeah, that's.

B

Not a new problem, yeah no.

C

It's not a new problem, and this way we get to document you might run into this problem so.

D

Then how would you tell them to not run into this problem? I.

E

C

D

Unique names for the deliverable and workload.

C

Add the ability, yeah or consider it and, however they're architecting their end. To end I mean the most common cause of this sort of scenario is that you would name your delivery, the same as your workload, all right, instead of maybe just calling it that thing's delivery or realizing that you would have this problem, I mean again, it doesn't apply to the story uh either way. You'd have to think to yourself. hmm I need to say something here.

C

Add something maybe support a parameter called prefix just so that people can use something other than just the default of their work, their workload or or deliverable name.

C

This conflict will happen either way.

C

So I think the action item there is to add a thing to make sure that we document uh making reusable templates and the the risk that comes with that.

B

I keep losing my tab with the notes.

C

Anyone has any major objections.

C

Just wanted to sound out a few people on it.

A

Okay, cool! Thank you um anything else. This goes for sure.

A

No okay! um Well! Thank you for your time and see you in the next year in the new year. Thank you.

B

uh David one thing.

A

B

Wanted to mention you said that the first meeting is going to be the second week of the year. I wonder um because of daniel and james schedules, if we should make sure to have a meeting the first week of the year.

A

Okay, yeah, I won't be available the first week of the year, but um there'll.

C

Be quite a few people out at that time too.

C

E

C

Their week off before some take it out off after.

B

Sounds like somebody's taking it the week after.

B

A

Okay, cool yeah: we will see how how can we arrange this, but so far the the goal is to resume on the second week of january.

A

All right see everyone then yeah. Thank you.

E

Thank you. Man. Thanks, happy holidays, happy happy new year as well, happy new year.

A