VMware Cartographer Community Meetings, 16 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Community Meeting/Office Hours blended session - March 16, 2022

Description

00:00 Intro
00:35 Project updates
03:07 Conventions service intro and demo
29:48 Review outstanding RFCs

A

All right welcome everyone to the cartographer community meeting slash office hours today. We will have a planned session covering content from both kind of sessions. So I'm glad that you're here and then we'll get started all right for the agenda. um I will be the note taker uh unless you have an objection just to go straight to the content.

A

um Okay feel free to add yourself to attempt an attendance list. First, a couple of updates on the project. First, one will carter is now in the cnc at landscape.

A

You can find it under the continuous integration and delivery subcategory.

A

uh This one could look symbolic, I mean which is a new project, another project in a not so crowded landscape already, but uh but the reality is that it opens some doors. I mean the most concrete outcome of uh cartoon. The landscape is that it falls into the scope of the global cncf meetup communities, uh hundreds of meetups around the world. um Their scope is to cover the projects in the landscape, so that opens some doors um and one of those doors. We we have our first talk as a project under the synthetic landscape.

A

Next tuesday, I'll be pairing again with cora, but this time much shorter, not not two hours, just 50 minutes to cover the intro to the project and brief demo of a couple of his cases so hope to see you there. This is now um the cncf hosted webinar.

A

So it's it's part of the outcomes of being foreign, you all for your support and for making it happen.

A

Yeah. Thank you emily and thank you to all the team. I mean this is the first milestone on several steps that we need to take towards working with that foundation. This is great all right and next up, you know, as you probably remember, last uh office hours. Scott, um you know share briefly about how the conventions controller famous convention service repo, is now public. It's basically a new open source project that now lives under the cryptographer umbrella and scott was kind enough to prepare the brief intro, especially for the community.

A

What's the value proposition the conventional service for cryptographer, so I'll pass it on to scott.

B

A

Stop sharing can.

B

I share yeah thanks uh so just to set context. uh Everything we're talking about here is in the context of rfc. I guess 17. This was numbered before the rfc process changed, so I'm not sure if it would keep that number what going forward, but this is what the pr was originally opened with um we're basically just proposing the idea of hey cartographer is great.

B

It does a lot of choreography of the resources that you're creating, but the workload resource itself doesn't expose everything that you might need to make sure it gets set on the resulting running resource.

B

So the proposal was to introduce the notion of conventions which is basically a cross-cutting way of applying behavior to, in this case, a pod template spec to be able to enrich it to sort of contain more of those um necessary knobs that get turned in order for a workload to run efficiently on kubernetes.

B

uh So what we've done in the meantime, uh so we've basically taken the uh the convention controller that is, uh or was it is a component of vmware's tap our tons of application platform and made it open source so prospectively, we just put it under cartographer conventions.

B

This can change as needed. Just sort of doing it here as a first place, pass to get it public based off of people's feedback from this group and elsewhere. We can sort of continue to evolve in this regard, so nothing here is locking stone.

B

um So streep is available, vmware tanzu cartographer conventions. If you want to go, take a look in the readme there's instructions of how to get the source and compile it. There is also a I guess: it's not actually a release, but there is a a build that's available if people want to take a pre-compiled binary and use that instead um might not be the easiest. I don't know if we have instructions about to actually consume this yet, but we can sort of work on that up all again. This isn't a real release.

B

It's just sort of to plant a flag in the ground.

B

um Within this, you can go several different ways with this session, depending on what people are interested in, how much time you want to dedicate uh just thinking, just to kind of quickly run through the design, do a very quick demo and then open up for questions all right.

B

So in terms of the design.

B

uh So we have a design dock that describes a lot more of the details, so people can go through and read this at their leisure, fair amount of overview, but the things I really want to call out um are just sort of like where this fits in in the grand scheme of cartographer and don't. I need to recreate this diagram. uh This is quite old at this point and not what actually uh exists within cartographer today.

B

But the general notion is that you have a supply chain that defines a bunch of resources that get templated out and then one of them is this pod intent resource and then the output of this resource gets picked up and put into the final resources that get delivered. So everything we're talking about is this sort of within this red box and, more specifically, what we're doing is we're introducing two new crds, a pod intent and a cluster pod convention.

B

uh So basically, the focus here is just on applying conventions to essentially pod template specs. uh We couldn't spend the conventions in the future to support other types of resources, but it would basically be a new effort for each of those. But basically what happens is that the pod intent resource gets defined. Oops.

B

Inside it defines a pod template spec and then the status of it gets enriched by the controller and emits back out an enriched version of that same pod, template spec, and we can look at what that looks like a little bit later internally. The convention server is basically taking this pod sample spec for each image defined within it.

B

It's going off to the image industry and it's looking up a bunch of metadata about that image, and this metadata allows conventions to have knowledge about, what's actually inside of the image that we're being asked to run so right now we basically have these cluster pod conventions that are defined over a web hook.

B

There's ideas about sort of extending that to have sort of other styles of defining conventions in the future, so you don't necessarily have to have an http server running in your cluster, but right now what we support is webhooks, so basically calls out to each of these convention servers. Lets them enrich the pod templates back, collects that aggregate result and then updates the status so that cartographer can then read that status and then propagate it further along the supply chain.

B

So a whole lot more details about what these resources actually look like, how they behave, but for now I will actually skip into a demo.

C

B

C

That future ytt convention.

B

So it's using ytt to apply a convention, um so if something doesn't exist, just notionally uh we'd like to have a way of being able to apply conventions inside the controller without having to have another external service running.

B

So basically just be call some ytt script with some data input, collect the output and then propagate that so no new functionality just sort of a different way of applying the same behavior.

B

And then similar to ydt we're also kind of thinking about like what would it look like if we used wasm or webassembly to do that same um logic? uh Basically, ydt and wasm both have the ability to run arbitrary code safely within the sandbox like, so we could take a user's business logic and apply it inside of the controller safely, as opposed to right now we have to do a web hook to sort of maintain isolation.

B

Cool, uh so I have a cluster with uh the convention controller installed, as well as our spring convention. So this is one of the samples that's included in the repo.

B

Basically just applies uh well-known, idioms to spring boot applications when it comes to when it can detect and discover that it is a spring boot uh workload. um So, basically, I have an image here. It's in my own uh docker registry. It's basically just the spring pet clinic app compiled using vacated, build packs. So nothing too fancy about it uh other than just the version of the kind of build packs that built it support s-bombs.

B

So we can take a look at how that information gets passed to each of the conventions in a little bit. So if I go ahead and create this.

B

We should just see it create the resource and, if I go and.

B

Immediately, get it back.

B

uh We can see we have sort of our same spec that we sent into the server. In this case the the status has been enriched from the controller, and we have our output pod template spec. That has a whole bunch of extra information encoded into it. One of the common things you'll see is this applied conventions annotation. So this is sort of a list of all the annotations. Sorry of all the conventions that were applied to the specific pod intent.

B

So you can kind of see what the system is doing on your behalf. So in this case have a dumper convention which is basically just logging, the the raw context of the request to standard out. We can look at a little bit later, but we also see that the spring sample convention was doing a lot of things so like it detected it with spring boot detected. It was a web app that detected that it had the spring boot actuator installed.

B

It detected that there was a mysql driver and it detected that it was a postcast driver and what this actually does and what it looks like and what it can start to do for you is start to apply common behavior that a well-behaved workload on kubernetes like should define, but developers, don't always remember to do so like in this case, a couple of things. It's doing is it's defining liveness and writing this probes, and not only is it defining these probes, but it's defining a probe, that's appropriate for the workload.

B

uh So in this case it knows that because the spring grid actuator is available that this path, actuator health liveness, is where spring mood is exposing and expecting to be invoked for lightness, cribs and then. Similarly, with readiness, the path is a little bit different and this is a place where, because the convention technologists bring boot and kubernetes, it can sort of glue these two things together and apply this behavior.

B

But at any point like if a user wanted to in their pod intent, define a readiness probe more explicitly the conventional back off and the convention will respect that.

B

uh So basically, this is just kind of filling in the gap, so it's like really smart, intelligent defaults, um like it has a potential doing other things as well, but that's sort of like one of the the key samples that we tend to look at so then what that web hook request ends up looking like is this pod convention context, so this looks like a kubernetes resource, it's styled as a kubernetes resource, it's not an actual resource.

B

This is basically just the body of the web hook request going across the wire. What we see here. We have our image configs, which are very large.

B

We have our template from our workload, which basically is just the same content copied over and then the status is what remains to be filled in based off of the response coming from the server.

B

So this template basically is what's available to be enriched, but we also provide each of the conventions, this image config and which gives them maybe too much information, but a lot of extra information.

B

So, in this case, it's both looking up the oci metadata for every image that exists within this resource, as well as it's looking up the bombs, the bill of materials that exist within this image. So in this case we're basically grabbing s-bombs that have been defined via cloud-native build packs.

B

Now we can extend that to support either s-bomb uh or other ways of storing s-bomb information on an image in the future, so, like cosine, has a slightly different way of attaching s-bomb to an image like we can go, add support for that in time, but basically, what we're doing is we're passing these s, bombs that we can discover to the convention.

B

So in this case we see like the actual, build pack that produced this s bomb, the the format of the s bomb and the encoding. So this is a sift uh spawn and json format. uh There are others that will probably be more interesting for those who are familiar with spring boot applications I'll just copy. This.

B

If we actually look at what this I actually is encoded to, you can see there's a lot of data here uh but effectively. This is containing information about every single dependency that exists within that was basically provided.

B

So we can see things like. Oh there's a mysql driver. You can see the version of that mysql driver. If I keep looking, we should see spring boot and spring dependencies. um It's basically just whatever data is available. Just we basically collect it, pass it through and let conventions decide what to do with that.

B

And you can see there's a lot of some of these s. Bombs get quite large. We basically just pass through what we find. That was our question.

A

Yeah yeah, let's just say a question in the chat. ah Sorry man, there was a question from emily in the chat, so the both intent will be. The template in the cluster conflict template correct. We and pull the config from status.template.

B

So it depends on what perspective you're looking at at what time so effectively the pod intent defines uh on its spec a template, which is a pod sample spec. uh So the idea is that would be created by cartographer when it's stamping out the pod intent resource, then the controller basically applies. All the conventions takes the resulting pod, template spec and updates the pod intense status with that enriched pod template spec.

B

So then cartographer can then read that enriched pod templates back and then go do other things with it: sort of in the next resource down the line.

B

So then, from the perspective of what any individual web hook, request looks like uh so we were in the middle of looking at the the sort of the the spec for the pod convention context. So that's sort of the the request side of the web hook.

B

So that again has the the pod temple spec, that's sort of the input, so it might be the original pod template spec. It could be the output of a previous convention depending on where it is in the chain.

B

So these things are applied sequentially so that the the sort of the behavior aggregates uh and then that resource faux resource also has a upon temple spec on its status. That is basically the enriched version of the pod template spec coming from a specific convention that, then, the controller sees and passes off to the next convention or returns on the status of the platform. All right, sorry on the pod, intent.

A

Right, thank you. Let us know emily that answers your question uh now. Next up wishima, please yeah. I just want.

D

D

My hypothesis, from what you've presented so far, is if you're, using a version of k-pop k-pac that did not produce s-bombs, that no useful work would be done with convention service. Is that correct and.

B

Does it require.

D

B

So like, if so in addition to the s-bombs, uh just there's also just oci metadata, that's available um so or you can also just base conventions off of uh the pod template that gets injected. So, in the case when, like there's, really like nothing interesting in the ocean metadata and there's no s available, um so it depends on what your convention is doing um so, like we have another sample that just injects an environment variable it doesn't care what the image is, doesn't care what what's going on it just blindly injects an environment variable.

B

So if you wanted to do that, like it'll work for every image, is that meaningful?

B

Probably not maybe, um but it's something that's available um so like something I've seen people consider, is uh something like a mitigation to the log4j vulnerability recently, where, if you sort of set an environment variable, you can sort of turn off the feature that had the vulnerability in it.

B

So if you wanted to just sort of blast out onto every single container of that environment variable, you might write a convention to do that um sort of like there are other places where you could kind of do that same mitigation. But this is like one place where you could do it.

B

um It's kind of a very dumb approach, in terms of, like it's just bluntly, applying to everything but being able to introspect the oci metadata being able to introspect the responses that are available. Allow you to have greater confidence about what the content of the image there. So it allows you to kind of create more precise and focused conventions, but you're, absolutely right that, like if you're using different, build packs within the cloud native bill pack, ecosystem you'll get different s-bombs that are produced.

B

If you're not using build packs like you, won't get dull pec s bombs, you might have some other s bomb so like as the controller like we don't try to distinguish about like what each of these s bombs means. Semantically, we just say here: it is forms we discovered, have fun.

B

uh And if you want, we can dig into what it actually looks like in the convention when we grip apart sort of the buildback metadata.

B

I'm sorry, not the dull technology.

D

And at some point I think I'll have to care a lot about that yeah.

B

I mean I appreciate that there's a lot here um and some of it's useful, some of it's probably not like do you care about all the diff ids of the oci layers that exist within the image, probably not that maybe um like a lot of the s-bombs, like you, probably don't actually care about, depending on what you're trying to do, but typically there's one or two that you'll care a great deal about.

B

So in this case, like underseeing, all of the the dependencies for all the sort of uh sort of the jar artifacts that exist on the class path is actually really useful. To being able to know like what this workload is, what it's doing, what capabilities it has.

B

So I guess just to kind of really quickly go through sort of the actual convention sample.

B

So basically have a main that basically just starts up a web book server. All these requests are tls enabled so there's a little helper util that will actually start up a server and actually detect the tls certs.

B

But the sort of the convention handler is probably the more interesting part where we expect users to actually plug in custom behavior.

B

So in this case, what it's getting is both the the pod template spec, as well as all of that image metadata, so it can sort of go through and find the images that it cares about and then sort of add some uh some dependency bomb helpers. That sort of allow us to sort of ask questions of the metadata and then what this ends up actually looking like in practice and sorry ignore all of the uh the compiler warnings.

B

This is a nested go module which their ide doesn't really support very well, but we basically just have a bunch of these conventions where we have like one function to detect whether or not this particular convention is applicable and then a second to actually apply the behavior of that convention so like in this case. We're basically just saying: does our dependency metadata have the spring boot dependency? Yes or no, then, if it does, it basically just sets a label, an annotation saying like yep.

B

This is spring boot, and this is the versions from good so like not very interesting in terms of what it does, but just sort of sets up the context of like yes, this is a spring boot workload like we know it's a spring boot workload, um then sort of getting more advanced um sort of just like there's a graceful shutdown so like the kubernetes graceful shutdown can now interact with the spring boot graceful shutdown. Those two can cooperate and have an understanding of each other uh when the spring web app.

B

So in this case it has spring boot dependency and has spring web dependency. We can start to do things like telling what port to listen on and then make sure that port is then reflected on the container ports array.

B

We can do things like knowing that actuator is installed and making sure that the management endpoints and the measurement ports are set up appropriately. Then we can actually define probes based off of the actuator endpoints. So basically, you just start to like apply all these logic, and I don't want to go too deep into what this is, but you can kind of just.

B

You could really go deep depending on how much you want to intersect the metadata, depending on how much you want to do within the content plus spec, but for right now I'll stop there. Unless there are other questions.

B

C

uh This is really cool, um are, do we support writing conventions in anything other than go? Are we going to is that in scope.

B

So it's a web hub call, so uh we basically we define the resource, that's getting uh they're, basically the the payload that's getting sent as part of that web hook. So any language you want to write the convention server and it's fine, um but it looks like we have sdk.

E

B

Go right, like it's a very it's, a very small sdk, but yeah there's a couple helper methods that basically just make it a little bit easier.

B

Any language with a web server like you can use.

C

But it's not on the roadmap or anything to like support other sdks for other languages or anything like that.

B

I haven't done it uh just because I don't necessarily have language expertise in those other ecosystems, um but certainly people could.

B

So whether or not it's on the roadmap is kind of whether there is interest.

C

D

uh I would look at the file structure over on the left. I was like. Are there tests yet or yes? Is that the first thing that we need to do.

B

Tests for the samples themselves, there are tests once you start getting into the actual uh like controller code, so like the reconciler has.

B

Tests so like, if I just uh let's go, take a look: what the coverage.

B

Why is this so slow? um Basically, yes, there are tests. um There are also sorry end-to-end tests uh using uh okay percent coverage.

B

um There are also end-to-end tests uh using github actions, so uh we basically uh deploy conventions under controller. We deploy a couple of the actual conventions of this a couple sample conventions. We create a pod intent and then we basically do assertions on the potential just to make sure it produced the expected output.

D

So I I would have said that that is tests of the samples I'm glad.

B

D

B

Yeah, there's not tests in the sample directory. Okay, so like we don't have unit test coverage of the samples.

B

But we're really just using the samples as more so to make sure that the controller itself is behaving correctly.

A

Right any other question.

B

Nope great well, you you all know where to find me.

A

Yeah and no I scored I I this confirms my suspicion that we need to incorporate the conventional controller into a content generation plan for the project I mean talks, blog posts, etc. I mean I feel we need to to share the story on all the features that it brings to the project. Thank you. Thank you. Scott um all right back here next up will be to review outstanding rfcs, um so I will start from left to right, starting from introduction for new rfcs yeah. We should oh actually yeah. That's exactly what yeah I know.

A

So I I will encourage you an old team. Whenever you you file an rfc, please add it to the rfc project, so we can see it here the cards, so I will move this for pending introduction. I mean then the introduction, but there there's already a long discussion and the thread for this one. So um I don't know if you wish you might want to provide a brief, intro update on this specific privacy or you want to share your screen.

D

um Yeah, why don't I share my screen, still make it a little easier.

D

Yeah uh we've got runables um and I have twice now written about runnables um and how to use them and it's complicated um in part because first you've got to like teach people like here's tecton and here's how takton works and deckdown's not trivial. um And then it's like okay, now wrap that tech down thing and run a ball and then wrap that roundabout thing in a class in a carto template.

D

And so this proposal is to leave. All of that. It is meant to be additive to to leave all of that behavior in place, but to enable users to cut out one of those steps that being that users as they when they get started. They don't need to define their own runnable that you could just put a flag on your cluster source, template and say this is meant to be an immutable resource and cartographer would say.

D

Oh okay, I understand this is an immutable resource, I'm going to create a runnable and I'm going to make sure that there's a cluster run template that matches with that runnable um to and.

D

And then yeah, that's, that would be the responsibility of the workload supply chain. You know technically the workload uh controller and then the runnable controller would do its job. uh The the once that resource is created uh cartographer doesn't need to care much about it. Although there's uh yeah, you would need to know how to how to read the outputs off of that runnable.

D

um That's the really short um uh I know scott has has given lots of great feedback, and so I've made some changes to the syntax and uh the the the this is meant to be an additive change, but one of the things that uh we would acknowledge is in order to allow cartographer to to take this work out of the user's hands and say ah you don't have to create runnables I'll, create runables.

D

The workload controller would need to know that the runnable crd exists and it would it would be. We would be encoding logic to write runnables into the workload crd. So um that's I'll say for my part, because testing, because I see testing as a core responsibility of a supply chain. I am unconcerned about uh adding that uh knowledge to the workload controller, but I think it's uh it is worth pointing out.

D

um Yeah there's there's some details in here about how exactly um there's there's an example here, and uh there are details about how things would have to technically work. um I don't know if we necessarily need to take the time to discuss that, so I will pause here and, if folks want me to go into that detail, I'm happy to do so.

E

um I have a question.

E

um First of all, this is super exciting and uh the one of the things that I ran into uh in using results with building some samples was, um I think, like in my own, like desire to simplify it as much as possible.

E

I was like well, I don't want to use pipelines I'll just run I'll, just go from runnable to task run like skip the whole tekton pipeline concept and just go straight to task, and um I found that I was and then I had certain situations where, like uh like the default, git cli task from the text on catalog didn't have all the inputs. I think that I needed so I had to modify the task or something like that.

E

You know, but I found like the wiring of like passing variables into the task, uh a little complicated like in it like initially, I didn't quite understand the approach in the samples because they, I think it's done for a reason. I just didn't get it until like.

E

I went through the process, um but they're done at a higher level, um and so I was trying to you know condense things, and so I kind of went a different way and found that, like I got stuck so I don't remember the details enough to ask the question in a better way, but if you know there's still the question of like somebody having to if you're writing your own text on task, maybe it's easier. But I guess, if you're trying to work, I don't know like work with a task.

E

That's from the catalog that has some stuff already kind of pre-designed and you're trying to manipulate that into something you want like. I guess the passing of variables into the task is: will that be simplified?.

D

D

Somewhat, um like I said so, as I said when I started off like the uh the tutorials that I'm writing uh can necessarily talk about like okay, let's, let's first start off we're gonna we're gonna, look at tecton and you're gonna have this? uh Sometimes it's a pipeline object and then tasks.

D

uh Sometimes it's just a task and then the task run so users will still have to if they're, if they're intending to stamp out something that's tucked on they'd, still have to create a task and then understand what the shape of the task run would be.

D

um I don't have a hypothesis for a way around that tecton-specific knowledge uh um than uh good at like yeah. Hopefully the tutorials make it simpler, like this didn't exist anywhere when you're working on that.

E

Yeah, I guess I'd have to go back and look at the precise like places I got stuck um but yeah it wasn't.

E

It was complicated because then I yeah, um like you know sometimes the answer is like well take a totally different approach about where you're, injecting the variables like, instead of putting the parameters at this level, actually put them up in the cluster template right. So you have to really just say this is the right place to do it, um but yeah.

D

I don't remember the details.

D

Yeah, my instinct is that um every you know you, you can see kind of here that um here we've got a pipeline run and it's got params and I think that.

D

I I've used tekton a handful of times, so my instinct is that uh every pipeline and every task should list out here the prams that I require, and so once once you get familiar with that um with that specification, you'll be like oh okay. This pipeline says perhaps here so I need to like create some params here uh on my pipeline run and then the thing that we're trying to simplify is that right now um cartographer asks you to define.

D

You know you you'd be creating this pipeline run in your cluster run template and then you would be uh creating a runnable. That itself is creating inputs that referred to here, and so that's like that next level of like because you're doing any cartographer, you have to pass it.

D

You have to like say: oh I'm going to have this cluster run template that's going to create these params, and then I'm going to have this or sorry I'm going to have this runnable that's going to define some params and it's going to pass it to a cluster on template, and then the cluster on template is going to pass it to a pipeline run. Another fight and then it it just gets into just the tecton stuff.

D

Where techton then says oh I've got this pipeline run, that's passing these variables into the pipeline, um and so we can't like I said I don't have a hypothesis of how to protect users from that tecton specific level. um But I, but knowing that that's there, I want to simplify the number of levels that you have to pass it through on the cartography.

E

Side of that second file.

D

I you would know, like the user will no longer be create manually, creating this cluster-run template and this uh runnable. Instead they'll use a cluster source template to directly just define a pipeline run and then.

D

Without you know, if you, if you didn't do this immutable thing like this, this just wouldn't work because uh pipeline runs can't be updated, and so that's why we have runnable.

D

But what we'll do is just allow we'll just let you hide all that complexity by saying like hey. This is an immutable thing and behind the scenes, cartographer will be programmatically, uh stamping this out in part because, like there's, nothing, there's nothing creative about um going from uh this to this, like you just need to know how to do it, and so it's like well, we know how to do that. We could just put that in code and do it for people.

D

Scott well yeah, it's good.

B

Yeah, it's actually taking us a step further. um I really like the proposal in terms of it really simplifies the user experience and sort of the resources that the user has to interact with when defining a supply chain.

B

um I'd kind of like to see us go a step further with it and actually update the shape of the runnable resource to not require a cluster, run, template uh and basically have what is the content of the cluster run template inlined into the runnable so that way, the supply chain, when it's actually stamping out immutable resource, just needs to make sure that it creates a um the runnable resource and not create a runnable and the cluster run template, because it feels a little bit weird because, like it that we have to sort of create like this extra cluster scoped resource.

B

That really is contextually defined by something else, but then it gets created and the scope of it getting created means it's cluster scope. Anyone could then go and use it, even though it's an implementation detail of something else.

D

uh So one, I think, that's a great discussion point for for everyone to weigh in on. um I part of my goal with this was to be.

D

Just to be additive, and so the or not just the additive, but also not to touch like there are no implications for how the runnable controller um does its work here, and the change that you propose is a change to the runnable controller. So I'm not uh yeah, I'm not opposed to allowing inline template templates in the runnable crd, but I also want to separate out that proposal from this one.

D

I I will say that, like that, if, when I hear that, like oh can, can we just create the template directly in in the runnable um it feels like we are getting even even closer to the question of. Why do we even have this runnable thing?

D

I think the the only advantage left to having runable is the object hierarchy that the um the pipeline runs that are created uh would then be children of that runnable object rather than children, of the workload directly.

D

I've heard um I've heard josh name that, as as an an advantage.

D

If, if we, if we didn't, think that that was an advantage, then uh I would say like oh, if we're talking about just embedding templates directly into the objects like, let's just uh allow the like one thing that we could do is say um you know you put this flag on here, that it's an immutable thing and and then you just don't like there's no runnable right, we're just like we. We understand that we are going to stamp out some object.

D

We understand that it's going to have uh a generate name instead of a name and when there's a change, we're just going to create a new one, and we take that logic that right now, the the runnable, um uh the runnable controller, is doing, and we just embed it completely into cart. The the workload um controller.

D

Yeah, so is there's my first reaction. When I heard like, should we just have template refs directly in runable? It's like ah wait like. Why do we even have this object again.

C

Yeah I like, I do think that object hierarchy is important right and like having that summary object. That can kind of you know aggregate all your collection of immutable objects under the hood. um It's really nice to have that there, uh because you know it gives information about that set of immutable objects.

C

um I mean the only thing it tells you is: what's the latest one and what's the latest successful, but I think that's an important informational architecture decision, um because it kind of fits the model of all the other resources that we depend on the hood right.

C

Kpac image has a whole bunch of builds, but the image is the thing that represents the latest good. um It really yeah runnable, really just like enforces that model.

D

um When earlier on, we didn't have so today, I would say the workload status um reports on the objects that it owns, and so we could totally put that, like we could just say, like oh yeah, when you, when you stamp out something that's immutable in the workload status like yes, there are n objects that uh that exist, that are children of this workload.

D

There are 10 of these pipeline runs, um but the one that's reported on the status is the most recently successful.

D

So you know, certainly certainly if we, if we had a theory of here, are other things that runable should be reporting on in terms of this. This set.

D

Those would probably be very different from the concerns of what the workload would want to report, but the current concern that is reported, which is just what's the latest good. What's what's the one that's going to pass on information, um that seems like something that could possibly be handled by the workload.

A

Okay, any other comment.

E

Question, I think um so as far as like, if we were to give like best practice advice, um would we ever advise people to use pipelines instead of task runs unless they already have pre-existing pipelines?

E

And I guess the like my instinct on that would be that if you have, if you're using a pipeline to like string together a bunch of tasks, then cartographer doesn't have any visibility on like the success of any given task.

E

um So it might be easier to. You know, use cartographer as a point of information about where things fail. If we just use one test after another, and so if you don't have existing pipelines, just go ahead and use individual tasks. But I don't know if we are on that or in that way.

D

I'd say the current tutorials that I've been writing use, pipelines.

D

Okay, yeah at the moment they use pipelines. uh I actually yeah.

E

D

I'm curious to hear what other people have to say: I'm kind of indifferent to it. I'm like yeah, you know, write your supply chain as you as you want, um and the tutorials are there to kind of scale you up in terms of the implications of some of those choices. But there's been no point when I've felt the need to point out like oh here's why you might want to avoid using pipelines- and I think you uh you know that idea like cartographers- should know everything. That's going on in pipelines are going to hide information.

E

D

E

Flipping the question, maybe in the tutorials that you've written using pipelines, have you ever found it to be beneficial or uh like? Have you ever found a pipeline to add benefit that's worth having over textbooks.

D

Yeah, I would say I have a couple of examples that do first, a git clone and then do some sort of test like I think all of them are linting tests at the moment, um but yeah like uh because I'm trying to write like the simplest, the simplest thing from the cartographer's standpoint, which is just like hey you've, got you define a workload and then you're going to lint it and then you're going to uh like build it and deploy it. um So it's not it's not leveraging flex cd.

D

So that git clone step is important.

E

The last question: sorry, um there was uh an example uh I haven't look. I don't remember the example. That's there now for the testing, but I know that the original example, like back in december, showed in that a developer could could uh contribute their own test.

E

uh That would be sort of, like you know, used by the pipeline. um Is that still possible with this rfc.

D

D

So nothing that is done in this rfc precludes uh you would still be able to to deploy exactly the example. That's there um the one of the things that my current hypothesis is like, we would just say like.

D

Oh, you can't use a simplified structure if you wanted to leverage uh selected um so runnable, unlike so all of our cluster templates, uh are able to leverage uh information, that's being passed to them from the supply chain, so you have some template, it creates an object and then it says like hey, here's, some values from this object, and so anything that a supply chain creates, is fair game for another, downstream object in the supply chain to leverage um what templates can't leverage is information about just like arbitrary other objects in the cluster um runnable's a little bit different.

D

We created uh this idea of having a selected uh a selector on runnable. um So if I pull up.

D

Is it in the cluster run template or is it runnable that we define it.

D

In runnable you can define the selector and it's just yeah, it's like hey. Here's, like any other object in in the cluster, and then uh the uh the cluster run. Template can then say like. Oh, I want xyz field from that uh selected object.

D

I and I know that that's there josh, you may be able to to say exactly how how that's leveraged by our tests, but I think that's there in order to ease the um uh to ease.

D

uh Defining objects more than once.

D

And yeah you can. You can probably tell from my description that, like other than hi like I have that high level of understanding of, like oh yeah, we're doing this so that we can just like leverage some arbitrary object on the cluster, um but the the use case always seems like pretty uh arcane to me.

D

um uh Anyways. I bring that. I bring all that up to say this is this. Is the one specific thing that I know that, like oh yeah, we've got some some use cases of runnables that are defining the selector, and uh this simplification is just like? No, we don't uh right now. This rfc says we're not going to do that. So somebody wants to step up and say like we should absolutely do that. Then there's more work to be done on this rfc.

A

A

Thank you. Well, we have just two minutes. Any other question comment regarding this rfc.

A

All right, what can we achieve in just two minutes? Well, just uh mention here the remaining rfcs. Well, we don't have time to discuss the r16 review and I don't see besides called, I don't see anyone else from the dlc.

A

This goes the two blocks with the technical oversight committee so again try to well the conventions rfc it's in review, so maybe I was to move it under the regular receipt process, looks like it requires a couple of approvals, additional approvals for this to be moved um and yeah, we'll try to keep the discussion going on the thread for the remaining origins. Please any question comment.

A

All right well, thank you. So much for your time see you next week.