VMware Carvel Community Meetings, 13 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Carvel Office Hours - May 13, 2021

Description

Carvel Office Hours - May 13, 2021
We meet every 2nd and 4th Thursday at 11:30am PT / 2:30pm ET. We'd love for you to join us!

This edition of office hours included discussion around GitHub Issue Triage, imgpkg Copy with rename, and kapp and Tekton working together (Thank you to community member, Charandas for joining and bringing this topic up!).

Full notes here: https://hackmd.io/5Bh2IXwTShSrA0YdBY4AGg#May-13-2021

A

All right, hi everyone and welcome to this week's edition of carnival office hours just a reminder to please read and abide by our code of conduct when attending these meetings.

A

We do record these meetings and add them to our youtube. Playlist we meet every second and fourth thursday of the month at 11. 30 am pacific time. So, if you're watching this from home, we do encourage you to to come to our next meeting if you're not able to meet for our office hours. We also have our carville community meetings and we meet every monday at 11 30 a.m. Pacific time, 2, 30, p.m. Eastern time today's date is may 13 2021.

A

If you are attending this meeting, live please and put your name and the organization that you work for or if it's just for personal reasons, that you're using karvel put that in the agenda.

A

uh Office hours are broken down into discussion, topics and open questions and help needed. So first up we have some discussion topics from joe wow one of the carnival maintainers, and I will kick it on over to him to discuss the first discussion topic. uh Joelle. Do you want to share your screen.

B

B

B

All right can y'all see hack him. The.

B

Yes, cool all right, so uh so, let's take a look at our agenda today. So our agenda is to topic, says: nancy said the first one we're gonna go through what uh a proposal that we did about the triaging of issues of our github issues, uh a little bit about like there was some thought put into it, and we added this to a document that we had prior uh that contained like what we would do, while triaging the issues so we're. First gonna, take a look at that.

B

Then I'd like to have some discussion about the the proposal to for image package to copy with rename discuss a little bit about, maybe the pros and cons of an approach or strategy approach and another one like the one that we proposed in this one here and then eventually talk about and decide if we want to postpone the overrides for it.

B

So let's get into it, because we do have some questions for the second half.

B

So, very, very briefly, um so this is a document that, uh where we try to delineate what it looks, what it makes, what we should we, what are we doing while we're triaging the proposals and there's some changes to this document and the major change is around the triaging process itself. What should happen when, when you're triaging an issue so.

B

The flow that is being proposed here is for the issues is that, like somebody, will create an issue right and that will get two labels. One is carbon triage and another is enhancement, because this is going to be a feature we have a a little bit down. Do we have like a bug triage and what we do. We do things a little bit differently, but so the first step is being done by someone that is an approver for the particular tool or the reviewer for that tool, and we are going to previously.

B

We had a community pair that was responsible for triaging these issues and moving them forward or not, but we are we are thinking about. Maybe this should be done by someone that is, uh that is more into the tool that is working more uh nearer the tool.

B

So the idea is that the approver or a reviewer would be first read uh first, read this issue and try to understand it, and if there is information that is missing or it's not 100 clear, they should reply to this issue and say like to ask for uh more information, and an important part here is that the approver or the reviewer that started this discussion should be the one that keeps on tabs on this particular issue. So we don't have like multiple people replying and having to gain context on it.

B

So this is like something it's a big change from what we had before.

B

If the approver or the reviewer uh understands like this has been like a good uh improvement, something that we want to have in our tool, then, basically- and it has enough context if the information- if the issue doesn't have enough context- the approver slash reviewer, will add the context so that it contains, like all the information on the issue, and it will change the label from remove the carval triage label, change it to carvel accepted and moves the issue to the carnival accepted swimlane.

B

So what I'm talking about is so if we go to our zen hub.

B

We do have this swim lane here the carpal accepted, so the story should be moved in here to this swim lane and changed it to be carbon accepted and we'll see why? Next, if it's not a good fit for the tool, then the approver or reviewer should close the issue and have some information explaining why this doesn't make sense for the tool.

B

In another, another situation here is that if the reviewer slash approver thinks that there's there is no need to add like acceptance criteria, or there is something that it's very self-explanatory, then the issue should be removed. The label carnival triage an accept coverall, except it should be added, but it should be moved. The issue should be moved into then prioritized backlog, swimlane.

B

So an example of that is, for example, like this issue, where it was kind of self-explanatory that we just wanted to make sure that an executable flag was kept into the into the file. So we don't need to create like a lot of acceptance criteria for this, so we we are okay, just moving them into uh ready to be picked up.

B

So if the feature is a bug, then it should change the label from enhancement to bug. So this is like the first step and it's all on the approver reviewer step. So what does our community pair is going to do uh on their day-to-day or something or every other day to every other day uh work? They should come through the carl accepted swim lane.

B

So now, instead of being asked to triage the bugs, they should go through this swim lane and the swim lane should have like enough information for for for someone for this community pair to create some acceptance criteria and they should try to create the acceptance criteria that is needed for this story to be done by someone.

B

And then it should tag whoever approved or whoever approved this. This car will accept it tag them and say like. Does this look like a good acceptance criteria and also make sure that the person that created the issue also is aware of this and make sure that the acceptance criteria makes sense for this full um for this full process, and if it gets a thumbs up, then it should be moved into uh 2rn prioritized backlog.

B

And last our blt, our product plus approver blt, is our balanced leadership team. They meet once a week to try to prioritize all the work that we do um or the product people plus an approver will get together and try to decide if there is something on the end, prioritize backlog that should be moved into the prioritized backlog for us to pick up next week or in the weeks to come. So this is more or less like the change on the process for feature triage for the bug.

B

Triage is a little bit different, uh because what happens is that? Oh, this is wrong that copy pasted this clearly, uh but the community pair is going to be responsible for trying to replicate the issue.

B

So the the issue should have enough information for it to be replicated, and the idea here is that you, we add another tag, another label, sorry that is, can be replicated and that information should be enough to see like does this have enough information for uh for us to proceed with the bug or not, and then, uh if there's not enough information, then it should follow up with the person that opened the issue to try to understand if it makes sense like if they can provide more more information so that it can be picked up later afterwards.

B

The approver or reviewer would uh would. If, if, if the bug was not touched by the community pair, then an approver or a reviewer can do this like this, the same part as above, and if the issue already has a can be replicated label, then, if it is a real problem, then it should change the carbol triage from should remove the label, carbon carbonyl triage and add the carnival accepted to it and move this move this issue into the unprioritized backlog.

B

If the scenario is not going to be solved, it should reply with the reason why it's not going to be fixed and close it. And if this scenario is it's not a bug, then it should be moved. It should be change the label to enhancement, and we assume that it is not a bug and it's something that we we want to do. Then it should be changed.

B

Our carbo3y should be changing to kerbal accepted and it should be moved into the carnival accepted swimlane and it will be picked up by the community pair on the rest of the triage for the features and then the again once again, the blt or the product plus approvers would check in these issues and will prioritize them when it makes sense so like this is uh somewhat of a change from the process that we had before, where basically the community pair would be responsible for triaging all the issues to accept them or not, even if they did not have like a lot of context on on the on the tool and so on.

B

So like this is our proposal. I don't know if anyone has any questions about it, um but this was something that we would like to eventually try, if everybody's okay with that and see if it works or if it is more helpful and can make us go forward quicker than we were doing before.

C

I have a question um more like clarification, so I think the trend is that only approvers or reviewers can decide whether an issue will be done or not.

B

So the idea is so the answer. The quick answer is yes, and why is that? uh In theory, the approvers and the reviewers are the people that are working more actively on a tool and have an idea? What the like? What is the idea for this tool how the tool should evolve? So they are the people that are best positioned to make decisions about. Should this be?

B

Should this be something that should be part of this tool or not, of course, and also they have like a bigger advantage that the time that they will take to triage this issue is going to be much smaller than someone that doesn't have like the full context of this. So we're trying to also piggyback here on the knowledge of the people that have more knowledge on this on the on the tools to make this this work faster than it was before, because before you had to build like all this context, and so on.

C

Yeah, I think that makes sense.

D

So I had a question about the community role um it seems like, given that the community pair would enter into this certain swim lane and try to add acceptance, criteria or try to replicate a bug um that this wouldn't need to be allocated. As often do you think that, like maybe this change in strategy would maybe put more responsibility on the approvers and reviewers than it does the other engineers who worked on the community fair.

B

Yeah, that is somewhat of the idea. The idea is to lessen the burden of the people that are doing community and to eventually even reduce the time that we are using right now to triage all these issues right. So there there is a proposal for us to to shorten the the need for this community pair to be maybe eventually like twice a week.

B

We would allocate people just twice a week to if there is need for it so like if there are things that need to be added acceptance, criteria to it or bugs that need to be triaged.

B

uh Maybe just have this pair work on community issues, like maybe twice a week, for example like tuesdays and thursdays, or something like that, the triage day, the t day right, but that's something that we're discussing still. But yes, okay,.

C

I'm excited to give this a try this this seems. Like you know, it's gonna address some of the issues that we've had so far. It's cool.

A

E

A

Expect sorry and I'm all about experimenting. I like this.

D

Idea, I'm a little curious about um cap. Do we have multiple reviewers or approvers in certain tools? Are there only tools that only have one person in at that level? Are we concerned about that at all.

B

A lot so we need to. We need to ramp up, because it's not it's not only to fulfill the needs on of these uh of like this new process, but also because sometimes we need people that help out with particular issues or if we need, for example, like in today's meeting. We're gonna talk a little bit about cap and there's no one in in here right now. That has like a reviewer or approval uh position on that tool. So we don't have like the full context. So I think we need to.

B

uh We are hiring right now, because we don't have enough head count to be to to have like reviewers and approvers in all the tools, but by default. Dmitry will help us out if we need to, but yes, we'll be relying a lot on dimitri, but we need to ramp other people up in different tools, and we have a problem currently on the tools that were not very that that that they are not like the our biggest priority that our cap and cable, so we don't have.

B

I do. I do think that I am a reviewer on k build. But I don't think we have a review around.

E

Cap can I interrupt here for a second, um I have something on the agenda, but I have to leave so I'll, probably be catching up on the recording later and it's just I wanted to clarify the issue I wanted to be talked about is on cap and it's the issue 77 on the github repo.

E

F

All I wanted to.

E

B

B

Make resources annotations more resilient.

E

B

All right thank.

E

You I'll catch up on the recording.

B

Okay, thank you. Bye.

B

Cool anything else on the github triage.

B

B

Cool okay, so let's uh let's try to give it give it a try and see um if you can organize, maybe starting next week or something to see if we can bootstrap this this process and see to see how it how it looks like in reality, because in paper it looks fine but we'll see how it looks like all right nancy.

B

It is the top of the hour right now. So shall we go into the other questions? First,.

A

uh We can continue on with the the other discussion item and then get to cap and tech time. uh You did mention joelle about no one on the call being a an approver for cap.

A

um Is everyone familiar enough to answer or discuss what the community member brought up for number 77 for cap.

B

So this is the issue, the one that I'm sharing right now.

D

B

Personally, I don't think I am, but I don't know if anyone is in this.

A

Because I can get dimitri's to see if he can join us.

A

In the meantime, we can start on the other discussion item and then um I'll pink him.

B

Sounds good like if, in the end, if we cannot get dimitri, this is something that we can raise and we can check it out, maybe tomorrow, during stand up and see if there's um if this is something because if this is impacting people right now, this is something that we need to look into. So we might prioritize this to eventually, maybe start this work or something maybe next week, if that's something that's very high priority as well.

A

B

And since it was dimitri that opened this issue, I do believe that this is inherently has the approval, but we now need to build up some acceptance criteria on it. Eli do you. They know that you're there do. You have any idea uh about something about this issue.

E

No, I don't no.

B

Okay, so if the immediately join us, we can talk a little bit about it.

B

Okay, so the other topic, the other topic that I have here it is about the image package uh copy with rename uh proposal, and it's been it's been open for some time uh to be fair and had a lot of space in my my to-do list to push this forward sooner. But I think that at this point we have two issues that we need to talk about. One is how um how the strategy definition would look like and another one is: are we okay or not?

B

Two do not have overrides out of the bat and eventually maybe build them later, but not as like something that is required to get this feature out. So I think those are like the two major, uh the bigger issues that we have here to talk about: okay, uh hey.

B

A

We go to the cap.

B

For a question then,.

A

Yeah that'd be great: okay,.

B

Cool, so we had we had uh someone uh sherandus here uh on the call, and he wanted to know about this issue number 77 of cap uh cap and tacked on working together in the issue. It is created by you and I think, jorge also opened an issue on tecton about it. Do you remember what this is about.

G

uh Let me give a read real quick um put your article with the user when texting controller replaces metadata annotations. Cap no longer believes that this resource is being directly managed by the user. It still tracks it, but as a cluster created resource, so that if some controller does copy over annotations from other resources, why there's still a tactile identity of the oh?

G

Yes, I think I uh so this issue was related to so if a user has so, I think tecton has this interesting behavior that it copies over annotations from one resource to another, and so, if you have two resources inside.

G

Inside your configuration file that you're sending to cap, then tacton so cap will annotate them appropriately, both of them and then techton will copy those annotations onto one. You know on to the second resource, and so, if actually that makes cap lose track that hey look, this resource is no longer being kind of managed by the uh by the system um uh it it's kind of it loses ownership, and uh I guess it considers that this resource has been created through the cluster means rather than created by cap.

G

So there's some, I guess, vagueness in there in terms of uh what actually should be the behavior, because it's kind of fighting the tecton is doing. One thing cap is doing another thing. You know who actually owns this annotation thing and there's a few different solutions in there. uh None of them are that exciting, to be honest but they're available.

G

Was there any specific question about this issue?.

B

uh So the person who joined us wanted to know if we are going to do this because they might be impacted by this issue.

G

Yeah I mean, I think we would be- I mean the first. The first stage for this issue would be to figure out what to actually do and then the next stage would be to figure out who does it right, whether it's maybe opportunity for anybody to contribute the proposed changed or whether it would be the core contributors contributing in this but yeah?

G

I think you know we're always interested in enhancing the tool, but for this one I think, given the complexity, it might require at least a lightweight proposal, or maybe a a list of options for what can be done.

G

B

Okay, so maybe what we can do about this is see maybe tomorrow morning, to see if anyone is interested in and giving a go on this. If not, if we have a hard time getting people, maybe can we rely on you dmitry to help us out and try to like understand this a little bit better and also get more uh a little bit deeper into the the options that exist, so we can create like a proposal and move forward. This issue.

G

Sure yeah we can probably we can start by, maybe writing down.

G

Maybe uh what are the options? As the issue comment um so happy. You know ping me on slack whenever.

B

Okay sounds good, so tldr we did not forget about you. We are going to um to try to get a little bit more uh color around this issue. Try to understand a little bit. What are the options and then, if you are interested in contributing code into this issue in particular issue or any other issue, we are always happy to get contributions so feel free to open prs against our repos.

B

Cool anybody has anything else about this issue.

G

Actually one one thing that uh somebody should take a look at is this issue still happen, because I do see that, even though a tecton issue was closed, there was a few other issues related to it that were that are still open, like precedence, order for labels and annotations.

G

So it would be interesting to see what's happening in the upstream, not saying that you know this is interior general problem. That could happen anywhere, but uh this is uh maybe specifically for techton. This may be something that gets fixed actually in uh in tecton itself.

H

Okay sounds good.

B

Like this, this pr strangely looks like the things there, but we would have to read it. Okay sounds good.

B

B

B

Okay, so it looks like oh thank you so much, whoever added the notes there. uh So I think we don't have yet another question. So, let's, let's maybe go back then to our proposal for the image package copy with rename.

B

So maybe, let's start with like the bottom one I don't know, let's start from the top and we'll see so.

B

Basically, there was a proposal for us to change the way we are going to provide um going to provide our strategies. And if we look at the proposal, it's going to take a little bit to open here.

B

But the way we were proposing uh our strategies to work was that you'd have a name: you'd have a strategy name and that strategy name would be somewhat of like a big name, but it would be descriptive trying to explain what each strategy was going to do. So, for example, there was like single repository on it that would copy everything into a single repository, and then there was relative to registry, keep name space, so each strategy had a name that would explain what a what that strategy was doing.

B

So we have another proposal of uh way to do strategies, and that was having knobs that allow the the person that is creating this configuration file to define to have like a more generic uh strategy. For example, we want all the the copy to be done relative to the bundle and then you'd be able to say okay, I want to keep a namespace or I want to keep the image or I want to keep the repository or I want to have the namespace dashed or something like that. So so two different approaches they have.

B

I think like pros and cons on both of them and I'd like to see, if what do you all think about these two options.

C

um I remember vaguely what we had before in the proposal. It was many. I think three different strategies um does this sort of new strategy where they're separate kind of map to like the same end state as what we had before in just a different way, or is there a fundamental difference here.

B

So this there are more things now that can be. That can be done with like this new proposal. Where previously we had, I think four strap strategies on it, and basically the strategies would do some of the things. So, for example, like everything is copied to the same repository or copy all oci images to a new registry, but maintain the original repository right. So this could be done by turning some of these knobs.

B

For example, I want to keep the image name or the namespace, and I want to put everything all the images relative to the bundle.

B

So, let's imagine that the bundle is in registry dot, io slash my slash bundle, so all the images would be placed in uh registry.io, slash my slash and then, if you said you want to keep it, the namespace you'd keep like the name, spacing you create from there, so some of the strategies will be able that we defined in the beginning, like on the proposal, we'd be able to be done with these knobs. That were that we have here.

C

That makes sense- I don't remember see dashed before, is that one new.

B

uh Yes, this one is new, it would be, you would be able to kebab. Is it kebab or is it the one with underscores?

B

I forgot what the name is so one of the two, but that's like that's a new thing.

B

D

So are there combinations of what you can supply to keep and dash that would make this config an invalid config.

D

What would it mean to keep namespace and dash namespace.

B

So, for example- let's imagine let's imagine so- I'm just gonna go here and write something. Maybe this is so. Let's imagine that we have reg dot, io, slash my slash image or my team, one image right. So the namespace for this particular image is this piece here. So this is namespace namespace equals to that okay. So if we did keep keep namespace and dashed namespace, we would copy everything to my so, for example, let's let's call let's say that our bundle is inside some.

B

This is our bundle right, so everything that one image would be placed in some.

B

B

Or if you just say, keep the namespace, let's assume that you say: oh, I want to keep the namespace. So let me just move this up here, so I don't have to copy it all over again. So if you wanted to, if you say just keep namespace as a configuration you do, it would look something like this.

B

E

B

That there would be like another one that, instead of being like relative to the bundle, it would be like relative to the registry. So in that case, if you have like a strategy that is, for example, relative to registry, then these two configurations here would become something like that and something like that.

H

B

So it doesn't so it looks like it moves right.

D

Yeah, so I guess I'm a little confused of why you would keep strategy um as a field and also have uh keep and dashed. It seems like all that strategy is telling you is where we're going to be relative to.

D

So maybe I see something that instead of strategy it's like relative to as the key and then you could have bundle repository uh similar to how you have namespace image and repository, but maybe there's a subset of options.

D

D

That could be relative to instead.

B

Oh, my god, like that and.

B

Something like this.

D

Yeah, it's just an idea um because I find that the strategy key a little bit confusing that I've defined like relative to bundle as my strategy and then I'm also defining bits of my strategy and keep and keep and dash.

B

Yeah, I don't like I don't see, I don't see why not I like it like insert instead of having like a sweat, because in the end it kind of loses the the idea of the strategy in itself. So it could be just one more knob that we had here.

D

Yeah and I find like the second configuration- is actually more different than the original configuration that had like all these different strategies that encoded information now we're kind of exposing all that information in these three different keys.

B

Yeah, I I do feel that this is going to make it a little bit harder, like the the major. The major problem that I see with having like all these knobs here from now on, is that every time that you want to do something it's going to make it harder right, because now you have like a lot of other possibilities and to be fair, like I was thinking about this, and our current default behavior is that we copy all the images into the same into the same.

B

Repository right, I'm trying to think like how would the default case look like right, because we don't want. We don't want to keep the namespace nor the image nor the repository. So we wouldn't have this. We wouldn't want to dash anything.

B

E

B

Does even the relative.

F

Make sense, I don't know, wouldn't wouldn't default, just be keeping the repository relative to the registry.

F

Isn't that, oh, I guess you're keeping the repository of the original image. Ref nod.

B

No, the default, is you copy everything into the bundle repository right? That's.

F

B

E

B

Think the way you would have to be like this right like this would be the default.

B

There is no really other way to do it.

F

Does it mean anything to just say like relative, to bundle like to have the relative key in isolation.

F

So like that, would that then preserve the original name and just put it under the bundle.

B

In theory, no because we do not, we do not say in order for us to keep the name. We'd have to do something like this right. Keep image right. So this would be. I want you to copy all the images into the same namespace. The bundle exists in, and I want you to keep the names of those images.

F

So it doesn't really mean anything to have relative without keep.

B

Yeah, that was what I was thinking like. I think that this key here requires the one of these two to be present, because it means that we want to keep something from the original image.

B

So but at the same time we do have so, for example, like a configuration like this, where, let's assume that we have- I don't yeah, that's it like bundle, we have no keep. Would this make any sense?

B

Something like that.

B

Or even a repository.

B

So maybe these two like so like if we had something like this.

B

What should happen.

F

Right, it doesn't make any sense.

B

B

And to be fair, like having just namespace to be kept so like, even if we say instead of this, if we say if we say keep here,.

B

If we say keep namespace, what would be the name that we give to the image.

H

Yeah, you wouldn't have.

D

One, its name would become whatever the last path in your name. Space would be right, so, like you'd have my team, one and image was the name.

H

This one copy it too.

D

Yeah in paths of the bundle or whatever.

D

If it's relative to bundle- wouldn't it wouldn't its name, space begin bundle right to write was also.

B

Right, uh okay, so we're assuming that the bundle is in some bundle right. So it would be something like here.

D

That would be confusing- I don't know like if you were copying, multiple images from.

D

Like multiple shas from that same image repository, it would be copied into the same place, but with different shots just under a different image name.

B

Yeah, so what you're saying is that something like image? One.

H

B

And this would be a one right.

G

Yeah, that's not awful.

B

Yeah so like I'm looking at this, I'm tempted to maybe assume that if you have like namespace.

B

That you can have image or repository. I don't think it makes like to be fair. Like this thing, I'm not sure if it is very helpful for the problems that we're trying to solve.

B

E

B

The problems that we're trying to solve is to allow people to more easily understand what are the images that they are running in their clusters, for example, and having them like this or having everything inside the bundle repository. I don't know if it's helpful, so I would be tempted to on the keep side just allow you to keep the image name or the full repository, not the.

D

D

So the name space in the image together make the repository yeah.

B

Okay, so basically like this is the namespace here, the part that I have selected and then this one part is the name. The image image and all this is a.

B

B

Okay, cool I'd like to move on because, like I'd like to try to see, if, if anyone is opposed to not doing overwrites,.

B

To start off, and then maybe you can try to try to come up with, like some scenarios and stuff like that, to see how this, like these configurations, would look like for like different options and see if they make sense to have like to have the the strategies open like that. Instead of being just a name, sounds good.

B

Cool, so about this part, what we're talking about is in.

B

I should be, let's, let's feel this as a full document, so the the proposal that I'm doing there is, since we are going to have much more specific strategies or strategies that are like knobs like this is no this one can we get rid of the overrides so instead of having like the possibility of you um having like one off, I want just. Is this one image to be copied to that one place? You can set a strategy and have all the images copied in the same way to the destination.

B

Or do you all think there there are like use cases where overrides are something that we want to.

F

F

Does the behavior of overrides in any way affect the behavior strategies like is, is override week, something we can just wait and see if we get feedback from people about and then just do strategies initially or does scoping strategies somehow.

F

Is scoping strategies somehow affected by rights.

B

I don't think so like. I think it is like a wise first step for us to just give people strategies in some way and then see if people you want to have overrides and there's we. I think we talked the last time that eventually, maybe the the only override that we really need is this one. Here the mapping function, ytt uh starlark, where you would just say: okay, you create a function that would do the overrides for you and that, instead of having to have like this override section at all.

F

Yeah I mean, I think that makes sense to just wait and see. If overrides are something folks.

F

D

Yeah one question I have is like as an image package user.

D

Would someone who is just learning image package want to use these strategies for copying like? Is this a beginner level feature, or is this something that we see more advanced users taking advantage of.

B

I think this is for more advanced users and for more specific use cases.

B

I don't see this as like something that you'd have to do so. This is going to be a file that is going to be optional, that if you do not provide an image package, will still copy it. It's still copied the same way it does today. So you don't need to have this, but if you, if you want to do something special on when you're copying and you have to want to have more control, you have like this advanced advanced option that you can do things with.

D

Okay, as well as I think that, like a a new user, wanted a huge, more human, readable uh copy output, this would be a great way to provide it for them.

D

um So I think, like a simple way without overrides might actually be.

D

Helpful to a new user who doesn't want to get confused with shaw's and wants to see. Oh, I copied this image. Well, there's the image name. I just have to do a visual scan.

D

Yeah, I agree with what you guys were discussing earlier.

B

Cool all right, so we have consensus, looks like so. I will update the proposal to highlight the fact that we are at least for now not gonna do overrides. I do believe that let me just check if we split the overrides into a different section or not so the first yeah, the first mvp would not have a strategy, so it was already thought like that, and the second mvp would include strategies. Maybe we can hold off on this second mvp, and then we have the third and final mvp.

B

That would be the starlark portion that we can maybe switch around if you want to or decide later in a later stage, if you want phase two and phase three or just phase three, all right, we are at time uh nancy.

B

Thank you all for helping me out with this uh proposal nancy. Do you want to close this off.

A

Sure I think uh so thank you for joining today's office hours and uh sharondis if you're, if you're, watching this from home. Thank you for your question regarding cap and techton, please reach out to us in the kubernetes workspace in the carville channel, so we can continue the discussion and get more details to work further on that issue. As we're you know really interested in and get getting that all ironed out.

A

The next time we'll meet for office hours is thursday may 27th at 11 30 a.m. Pacific time, so please feel free to join us then or join us next monday, as we meet every monday at 11. 30 am pacific time for our community meetings and yeah thanks again enjoy the rest of your day.