VMware Carvel Community Meetings, 8 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Carvel Community Meeting - March 8, 2021

Description

Carvel Community Meeting - March 8, 2021

Details here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw

A

All right, hi, everyone welcome to today's edition of the carville community meeting, I'm nancy lancaster, I'm a senior open source community manager at vmware, and I focus on the cargill tool suite as well as some other projects here at vmware.

A

Just a reminder when you're engaging in these meetings, please adhere to the code of contact, it is being recorded and we do post these to youtube afterwards on our playlist, uh I'm just gonna go through the agenda.

A

If we have anything at the end of the meeting today that doesn't get discussed or if there's anyone that has any questions. In particular after after today's meeting, I invite you to attend our car roll office hours, which we're starting for the first time this week, they're going to be held every second and fourth thursday of the month at 11, 30 a.m.

A

Pacific time and that's also listed here in the agenda now I will kick it off to aaron hurley, I'm going to stop sharing my screen so that he can share his and get us going with the status upstate updates in the rest of the agenda.

B

B

um So, as nancy mentioned, if you have any topics that you want to talk about today, please add them to this discussion. Topic section here at the bottom: uh we'll try to carve out time to cover those um yeah, starting with status, updates, uh not planning to go deep into any of these just kind of wanted to provide a way to click into these. um If you want to learn a bit more, but you can kind of see, we have a handful of things that are in progress.

B

um Primary plan for today was just to really use this as like an iteration planning meeting so discuss. uh What's top of the backlog for us um discuss it as a team. Do some pointing then there's also this section on triage help. So these are, I think, community issues that um kind of need discussion to to further what our plans are for these so we'll see if we have time, but it would be, would be nice if we could start at least one of those.

B

But let's get started with the backlog, then.

B

So we'll start with the image package recursive bundles track. um I think we'll plan to review a couple of these stories, uh just at least so. We have enough runway for the week.

B

So, starting with this first one joao. Would you like to present these.

B

uh Yourself, muted,.

C

Yeah, I said uh thanks for uh for the reminder cool, um so this is uh we're. Gonna talk a little bit about our recursive bundles, our nested bundle track just so we start to give you more or less like an idea where we are before we. We start doing this story, so we already have. The initial story is already in our code base that allows you to push a bundle that contains other bundles in pr. We currently have two other stories, one that is when you pull a bundle that contains other bundles.

C

It pulls them into a particular folder in your machine and the other story. That's already that's also in pr is the ability to copy an image to a tar and then pick up that tar and push it into a registry. So this is what the world will look like in terms of functionality when we arrive to this story- and this story is giving image package the ability to copy these bundles from registry to registry.

C

C

So if we go through more or less the acceptance criteria, we'll be able to see that a user when it copies a recursive bundle between repositories using the using this flag, we are hiding like all this functionality behind the flag, minus minus uh experimental, recursive, bundles and all the commands will provide this one except pool pool will not need this, this flag, we we discussed it a little bit and we thought it was not needed.

C

It didn't bring anything but for all the copy commands in the push you need to use this in order to copy um to copy and to push recursive bundles.

C

So if we look at what the story says is basically, if you have a bundle, if you create a bundle that points and that incorporates two other bundles, when you push it, this bundle to a registry, it succeeds, but then, if you try to do an image copy from that from that repo to a different one, you should be able to see uh like the following output. This is a little bit.

C

This is more or less the same, that of the in terms of like output that we had before uh it will show you all the images now, instead of only the images from that we for images from images, but the output in itself is going, it's not going to change from the current version and that's it. So this is our first scenario. So if anyone has any questions, just feel free to jump in so the other scenario is we need to ensure that we.

D

Issue out, I did have a quick question um when we use the dash dash experimental recursive bundle. Does that then imply that the bundle is recursive.

C

Is it doesn't like we, we decided that it doesn't make sense for you to be able to copy just a bundle, so when you copy a bundle being it recursive or not, being it nested or not. The behavior that we expect is to copy all the images in from all the bundles that you're trying to move. So there will be no uh recursive minus r or minus minus recursive flag, as we have on the pool.

D

C

Thank you cool, so the second scenario is just to uh ensure that if you're copying an image, if you're copying a bundle that doesn't contain uh nested bundles on it, it just works. So it's just like make sure when you're implementing this make sure it did not break functionality.

C

And the third scenario is a scenario that is going to be temporary right now and it it is going to be. If you try to copy uh a bundle, an asset bundle from one registry from one repo to another repo, and you do not provide the minus minus experimental, recursive uh bundle flag. It will fail so just make sure that if this this functionality didn't will never got out of this flag that it we would, we would fail right and we'll have like a error messages there.

C

So this is just like a temporary thing that will be removed when we get to the last story of the set of stories cool. So I think that's more or less it.

E

What about localizing, the images lock file is that part of this story should we get that working is.

C

No, this story is.

E

C

So like there's this, this story is of copy, do not really care about the pool, yet the there's, a a specific story that will take care of the pull output.

C

Not only the output but also those files, but yeah, so does anyone have any more questions about this story.

E

From a technical implementation perspective, are there going to be any changes, except from just adding this flag and an error message like I feel, like scenario, one and two just might come for free, I don't know, is that your intuition.

C

uh It's not gonna come for free, because the way we have structured, the retrieval of the images uh we'll have to you copy a little bit of code that currently only exists in one place and put it into another.

E

Okay, so when we build the image set, it's not recursing and building the entire.

C

What do you think about it? It might well, we might get it for free, but maybe yes.

E

I was just wondering what your intuition was in.

C

In theory, like I think, it's going like so this, the current the this story in the next two stories that we have in the pipeline are stories that finish the copy, the copy behavior for all our options and the implementation needed for them. It's gonna be very small right because, like the bulk of the work of copying is already built in is already built in.

B

B

Any other questions are, are folks ready to point.

B

Cool: let's point three: two one shoot.

B

Some mostly ones and a two uh steven, do you wanna, speak to the two.

F

Yeah, I'm content to come down. This is just from my own lack of knowledge about the way things currently work.

B

Okay, there aren't any further questions. Then we'll put this as a one.

B

C

Move to the second before you open the next story, can you go back to the zen hub cool so like this is what it looks like the the next set of stories that I was talking about this initial one. This is also a copy story. This is also a copy story here and then in this story we will start thinking about what happens when you pull a bundle that contains other bundles and what it looks like and what are the impacts on the inner bundles and what should we do on those inner bundles?

C

So that's what we have in terms of stories there's like another story that is going to be just. We need to add documentation on image on the image package website for all this work and then the last story of it all is going to be. We will remove this experimental flag and make this available to everybody. So this this story is going to be the last story of the set that will allow us to by default, provide this functionality.

C

um Sorry, karen.

B

No thank you. Thank you for that overview, that's helpful cool, so we'll dive into the second copy story.

C

So, as we talked before, we now are able to copy a bundle from the repo to atar and from atar to the repo again.

C

The second story of this set allows us to copy a uh a bundle from a repo to another repo. Now we have another story that allows us to copy from a repo to another repo, but instead of us providing the minus b flag, we're gonna provide a bundle lock file.

C

Okay, so uh it is, it is gonna, be more or less the same thing, but the way we're inputting things and we're giving things to image package is going to be a little bit different right. So, oh I'm not sure. If I, if I said this the last time, the pre-requirements for all these stories are the same, and when I wrote them, I try to make sure that they are. They make sense uh throughout all the stories so that it is easier when you're trying to implement.

C

You know that our bundle one will always contain one image in bundle. Two, for example, in that bundle two is only going to contain an image, and then there are two other images there right like some. Some parts do not need all these setup, but I decided to carry it over so that we have like a common thread on our pre-requirements, um so this is also again a. um I think it's a three scenario um story.

C

Where our first scenario is, we create our recursive bundle and when we create our recursive bundle, we add our little flag minus o there. That will create a bundle log file for us, so instead of us now just providing a minus b flag that contains the other registry that you want to copy from. What we want to do is we want to copy from the lock file that basically contains this nice string here with a little bit more information.

C

It will copy from this log file into this new repo. Here the output is going to be the same for copy, so this is exactly the same.

C

So the second scenario here is to make sure that we didn't break the prior behavior. So when you create a log file, uh when you create a log file, it just works so like we created previously, the the this model number two. This is what a log file looks like uh when the log file looks like we create this bundle. Log file we already created previously.

C

This bundle two on our pre-requirements up there and then, when you try to copy it and do not provide any flag here, because this is not like a nest, but it's not a recursive bundle. It just keeps on working, and the last scenario again is: if you try to copy a um a bundle of bundles without using the the minus minus experimental flag, it will.

C

Fail so there's a fourth scenario. Look at that.

C

Oh yeah, that's the fourth scenario: if you try to copy it using like an image, if you try to copy a bundle that contains bundles using the image log file, it should fail as well.

E

Looking at scenario 3, looking at the error message, it looks like we want to have the the entire command given, but with a hint saying, use the experimental flag in terms of like just making implementation a bit simpler. We could could we just just say instead of figuring out what the initial command was just say, you know, you know just use the experimental flag next time.

C

Yeah we can do that. Okay,.

G

I had a question about scenario four, um so in the previous story you could copy from registry to registry, and during that copy process we have listed um when a bundle is nested. The the reference to that bundle is in the images lock file, and here it seems like we're preventing from putting bundles into the images lock file.

G

So if I wouldn't there be bundles in the images lock file, if it was a nested bundle,.

C

Yes, but this is a different scenario, so, when you're providing a an image lock as your input to image package, you're, not providing a bundle of bundles you're, just providing a list of bundles and what we're trying to do here is try to differentiate between your you want to copy a group of images, for example, and that's when you would eventually use an image lock as your input to a copy command from a situation where you want to copy a bundle that contains other bundles on it.

C

So there's like there's, the distinction is just like. If you provide an image lock file as an input, we expect you to be copying images if you are providing uh bundle lock or um order repo to start with, we expect to be to have bundles on it or just splitting two bundles.

G

Yeah I feel like if I was distributing some parent bundle that had bundles in its images lock, and I provided a lock file to someone I was distributing it to. I would want them to be able to use that log file to relocate the dependencies.

G

um I don't know if I'm missing the point here, it's like yeah. They could use the original bundle to reference to grab everything but shouldn't they also be able to use the lock file to grab all the dependencies as well.

C

Eventually they could, but that's why we generate a bundle lock instead of an images lock. So when you do a push when you do a push like, for example, in this case here yeah, it will generate a bundle lock and not an image log file. It's just like more of a. If you want to transport the bundle in a particular way, you get. You get one particular input. If you want to transport a group of images, then you get a different input. You get like a just one phone.

G

Yeah, the the difference in scenarios makes sense to me now. I think it's just pretty. It was hard for me to see it.

G

C

Any other questions.

C

I do have a note there like this already exists scenario. Number four already exists, but it has like a a little bit of a different message and it's just like to make it more point pointing more like easier to understand. I think currently it says like you should use minus v or something like that for bundles, so like this is. This is just a little bit of a change of a text on scenario. Four.

H

H

One one small thing: if I remember correctly like for scenario three, for the push commands the way to output, a lock file is with the lock output flag, not the dash o flag.

H

I think that might be just a mistake.

H

D

If I remember quickly.

C

It is possible I'll check it out.

B

Cool shall we point.

B

All right, three, two one shoot.

B

Got ones and a two I can't see stevens it's okay, one um kerry. Do you want to speak to the two.

H

um Yeah, I pointed too because I felt like there were several cases here that need to be covered, um so that to me seemed like a lot of sort of different scenarios that need to be implemented as part of this, so that that increased, the complexity for me.

H

um But I'm willing to go down to a one as well.

B

Does anyone from the one side wanna share, why why they pointed at one.

E

Fair, um I pointed at one because the assuming the previous story has been implemented and done.

E

This story to me just really seems one like one changes: instead of getting a bundle name from a flag, you get a bundle name from a yaml file, which is something we already support, so that should almost just work and then like most of the changes, the bigger ones were just like the scenario three and scenario four, but it just seems like for scenario. Four we're just we're rewording, an existing error message and for scenario.

E

Three, you know we're just gonna fail and ask him to pass a recursive flag, so it didn't seem like a lot of changes or any risks.

G

B

Cool, let's uh maybe point once more, just see where folks are landing.

B

Sit. Three two one shoot one's cool.

B

See we'll go to the next copy story.

C

Yes, scary, you're right and I just updated the stories, let's catch all right so like this is the last story for the copy and from this point on like after we finish this story, you should be able to use all the current functionality that you have with a copy right now with the new recursive bundles. So this story is to allow you to copy to copy a bundle using a bundle log file into a tar, so, instead of being able to copy it from the repo to a tar.

C

Now we want to copy using the bundle lock to atar. So this is again like the more or less the same scenarios here. So our first scenario is going to be. We are going to uh um to generate to push a lot push a bundle that points to other bundles and we're going to generate our bundle, lock, file right there and then we're going to try to copy it into a tar and we're going to see that everything gets copied.

C

So, like all the images, as you can see like there's just a little bit of a difference of ui between what we had before when we're copying to repo and what we're copying to a tire right now, this is already there so that there's nothing that needs to happen extra. um So this is our first scenario. Our second scenario is to ensure that the prior behavior that existed, it's still here, it's still working.

C

And then we have a third scenario: that's the failure! If you try to copy to atar a bundle that contains other bundles, so it fails in the same way. So we can also did what danny suggests and change. This message to just say, like oh just put the minus minus recursive flag on it.

C

Instead of adding the full command and our fourth scenario same thing, with image lock and same error with the image slot so very similar to the previous one. But instead of our target being a repository, it's going to be a tar.

C

H

Anyone have any questions.

C

I'm sorry if this feels repetitive and the stories look pretty much similar, but in the end it's just like to make sure that we have all the features that currently image package implements. But there's like a lot of knobs that you can turn here and there.

D

This feels more thorough than it does repetitive to me so appreciate the attention to detail.

B

All right: well, if there aren't any questions, how about we throw points? Three, two one shoot ones and a zero john doing to speak to the zero.

D

Yeah, I'm like teetering between a zero and a one. It's just. uh I think the one would be useful uh to do exploratory testing um and if there's nips and tucks, it's also not an invitation to like come back after a little bit of calendar time to um maybe there's little refactorings. That can happen or something like that, but intrinsically it didn't seem like there was. There was any additional complexity to digest so one's fine for me, but that's just kind of my thinking.

B

Does anyone else want to share thoughts.

F

I felt similarly and that it's just about a zero to me, but I think it's worth having that one point to ensure that all of these scenarios laid out work as they're supposed to, and we take some time to come back and review that it. It now does do all the things that coffee is supposed to do.

B

Cool seems to create a pretty rough consensus of one. So let's keep moving. um Do a quick check. I don't see any topics yet so if anyone has a topic, we'll maybe check once back once more. um Let's see should we do one more on the recursive bundles.

D

Track yeah, given our velocity probably makes sense the right you get three yeah.

B

Yeah, so if we have three there- and I think there's already a couple- a couple are in review, so maybe we're okay to cursor bundles cool, let's jump over to ytt schemas then, and we have this first story scheme supports voting types.

F

Stephen you want to take this one yeah. I can certainly talk to this one.

F

um Let's start going through the the big heading categories here, so the the motivation for this one is that currently our schemas allow you to define types for what are acceptable values and right now those are maps and scalars. You have booleans, but you can't actually define any number with a fractional, a non-zero fractional portion, so you can define integers but not 1.5, so this story is all about adding that setting it into your schema and accepting a reasonable data value.

F

uh So the first acceptance criteria there is, if you put in your schema, let me go grab the annotation tools.

F

If you put in your schema nope, it's not doing what I want. It is close enough. If you put in your schema some value here which has a fraction, then we parse it as a fraction. It has a floating point number, and so we accept floating point numbers in your data values.

F

You can also in yaml, explicitly specify a type here as double exclamation mark float and that should pass okay.

F

So if you run this command given the above files, then they should be substituted properly and you get a reasonable data value replacement.

F

Integers are a strict subset of floating point numbers, so therefore, you should also be allowed to use just a regular 13 as a 4.2.

F

I'm going to assume that made sense. However, that doesn't mean that you can put whatever you want in.

F

uh If we move down to that next criteria here there is still type checking going on, so you really do need to provide a valid number if you specify, in your schema a x dot y number, so a string or an array. These should both lead to error messages which are hopefully pretty similar to the ones we've seen before.

F

It's just another value is not what the scheme expected found a thing expected a float, I'm not positive on the wording of this one. I've been considering number, but I think that's fine to leave to the implementing pair.

F

This should also include some documentation, so you need to be able to search and navigate to ytt docs, to find that, oh, I actually can't specify more than just an integer for a number type.

F

One last implementation note here is that when we output- that's not a great arrow, but when we output we're going to lose some type data, if you don't provide a a non-zero fraction.

F

So if we say we expect a 1.2 that is of type float, if a data value is exactly one, then our parsing output is going to also be exactly one.

F

So if you really cared you're technically losing that information that you started with a schema, that was a float and you got an integer, but because integers are strict uh subsets of floating points. I don't think that's a concern for us.

B

Any questions from.

E

Folks, my my head went to like like float overflow concerns like, should this be a float 64-bit like what, if we put more than 32 million or and then and are there any things about the number of decimal points that we should allow or not allow? I don't know, but it's just like not things we don't even have to concern. We just let star luck, figure it out.

F

The one piece of information I have about this is the json spec does not define any bounds for upper or lower limits of numbers, including the fractional parts, and I think, because we're able to load json, we should be able to support all of those numbers as well. So I guess arbitrarily large or small.

D

I can, I can add a little context to that that at the the go implementation of starlark, uh I think it emits a float 64..

D

um So there there is a practical limit to what um what starlark will handle, um but we didn't think that when we were talking about it, we didn't think that that was going to be any practical limit for the uses that we see ytt in.

C

Can you go back to the implementation.

C

C

What does it mean to be output with type, and does it mean that we don't want to have any dot zeros in our representation? What does that mean.

F

I think that would be completely fine. I know that yaml in general would try to get rid of it. So if you just run as a data value, I don't know 1.0 and then use that in a template of data.values.

F

foo, the output would be just one, and so this was mostly just to say it's, okay, if that happens for us, but if we end up preserving it, probably a bonus.

C

C

So, like generally more like in terms of like implementation, wise, is there anything from this already implemented, or are there like prior art on how to uh manage these cases?.

F

We're currently doing type inferencing on many other types, so this would be adding another case check to all the places where we, um where we get a document map or array item.

F

And then just comparing the I guess, the float64 type with whether the value can be cast to it.

C

Currently, they are just interfaces right so, like we have like that case, that has, it is a string. It is a uh whatever. So we just need to add two more cases, one for intent, one for float64, okay,.

F

It should already exist, so it'll just be making sure that.

B

Cool, how about a round of pointing.

B

All right, three, two one shoot.

B

Got some twos got a one. Let me start with the two side.

B

Anyone want to share.

D

G

D

G

Ahead, garrett, sorry, um all good! I saw the documentation as a reason to bump it up from a high two to I mean a high one to a two see john nodding, so that that's about it.

B

Cool anyone want to share thoughts from the one side.

H

I pointed as a one sense there's already prior art from other types that we can kind of grasp onto. um So I think that lowers the complexity. For me, I think it. It is like a lot of points in the code that need to change, but the fact that we have prior art.

B

Cool, uh let's try pointing once more to see if anyone's shifted.

B

So three two one shoot.

B

All right, we still have mostly.

B

Twos see check in once more okay, no discussion topics were added, um let's see so we have a three-pointer in flight. We just pointed a two-pointer. Does that sound sufficient for this week for schemas yeah? I.

D

Would think it is.

B

um So in that case, I think we'll jump over to what is this issues not in an epic.

F

um The repo filter might also be preventing you from finding something.

B

Okay, I yeah I have it limited to. I guess, like the life cycle tools right now, so the so. These are a number of the I guess kind of like issues that maybe don't have like a an epic, that's tied to it, but a collection of you know enhancements or bug fixes that we still want to prioritize and address.

B

um We've discussed a few of these, but this one moved its way up a little bit.

B

So I think this would be helpful to chat with. Oh, we just lost ben, um so this is retain executable flag on files in bundle. Does anyone want to present this.

C

I can give it a shot. Nobody else wants to talk about it.

C

Okay, so um so like there there's a there's, some information on that slack thread, but basically, when you're, um when we are creating the files in disk, we, when you're pulling something when you're pulling like an image, we change the permissions for all the folders to 0700 and all the files to 1600.

C

So what this story is about is that sometimes you want to have uh executables and you don't want those executables to change permissions right. They don't want. Do you want to lose that, so what this story is asking for is a way not a way. It's asking for image package to preserve.

C

If a file has executable flag, we should keep that flag. So this is uh more or less what this is all about.

C

Oh by the way, this is like very specific for.

C

B

Any thoughts or questions.

F

See we have a comment there about only adding that execution permission if it had that same permission previously, should we be doing that same thing for all permissions.

C

So six gives you read and write on a file. The only permission that we're really lacking is uh is.

H

C

In the end, we could try to prevent people from having right if they didn't had it before, but nobody asked for that. So I'm not sure, but that's something that we can add to the story as well.

D

Yes, it incorrectly to presume that the the the deeper ask is whatever bits are set are the bits we keep that we would like l-stat the file as it comes in and copy over those permission bits. Is there a reason to there may be? This is not a rhetorical question is: is there potentially reason here for filtering those bits.

C

In the end, the right flag doesn't cause you a lot of problems. If you do not preserve it, while they execute one it'll cause you a lot of problems because you'll not be able to execute a file right so from like the ask that ben had and the problem that ben was having was specifically with the the execute flag. That's what the ask there is for in the end, we can expand that and say like. Oh, if you didn't had right, we just give you five. Four four. I don't remember what it is.

C

What's the number for that, but it's like one of the two right, um so I don't see any reason not to preserve the lack of uh right flag.

E

I have another question: it's really about around. I don't know if it's a concern we should care about, but it's about the reproducibility of this. So now we have the same input process with two different versions of image package and they're gonna produce different digests. Essentially I don't know if that's a concern and I think they're gonna produce different digest because we're you know modifying the metadata ever so slightly. Adding you know seven set of six potentially.

E

Is that a concern.

D

Where does this affect the image contents?.

E

When we write the tar entry, the layer digest would change, because now inside the the layer the file is going to have a different. You know permission associated to it. So now.

H

E

Digest changed and now the entire image, because that layer changes everything else slightly different. It's not reproducibly going to produce the same output, even though the input's not.

C

Changed this affects the pull right like when you're copying things with a tar and so on, you're copying the tar so you're not changing the tar at all the tar like guitar layers. Nothing will change because that information, the production of the tar layers is not done by us and we do not touch it.

C

This is on the flip side, on a pool when you pull an image and you pull it to disk. That's when we change the permissions and we are code, the permissions to all 700 and 0600, depending on folder file,.

E

Okay, so maybe I've read it wrong. I thought it was like when we push and copy it make sure to like change the files but I'll make make sure that the flags stay the same. This is like keep pushing and copying the way we're doing things today, but on a pool when you pull it down. How would you know what the original permission was when you pull it down.

C

We use we, we just tie it up so like the permissions will go with it, we'll go with the.

E

C

When you tire it up.

E

But I might be misunderstanding it. I would have thought if you, the tire entry, has the permission. Like each tire. Entry has a header and it's you know the layer of the entry would change like the layer being there's like a there's, a zip file inside the tar file, and that has a digest, which is the contents of everything in that.

C

C

D

Yeah, I guess the good news. The good news is, it is a different bundle or a different package, so I think that's behavior by design, but I don't mean to dismiss your point about the fact that I think that I'm going to get exactly the same thing back.

D

I guess we'd have to unpack that scenario. A little bit more to see whether or not a need has just popped up, but I wouldn't want it. The other way wouldn't wouldn't want it so that you could change permissions on a file and that not affect the.

D

D

Do do we know why we originally hard coded those permission, bits.

B

I think the slack thread that's linked here was about reproducibility.

B

But here's a pretty brief explanation.

D

As a rationale, so it should yeah. I see oh and it's not caught in your uh screen, share oops sorry jump to your slack app.

B

Right, oh: let's try that again.

B

Not the right link.

B

So this could be something like folks could follow up dimitri to dig deeper as to what just another level as to.

B

B

Okay, so I'm trying to think of do we want to include this type of discovery, work within the story itself, or do we want to capture like an exploration outside of the story.

D

I'm thinking in this one in particular, it might shift the implementation.

D

C

Would it shift the implementation, or would it so like it feels like that there are this? Will so okay, so you have one version of image package and another version of image package that contains this fix right. The second one is going to produce if you using the same folder, it's going to produce two different digests correct.

C

So what we're talking here is more like it's should we do this or not not the implementation is going to be the same. It's going to be we're going to look at that number we're going to change it. I don't think, there's much else that we can do in terms of implementation for this uh story.

C

I think it's more like is this something that we are okay with having two different versions of image package that generate from the same folder to different uh digests or not.

B

Yeah, I think we at a minimum just clearly communicate its breaking change for the release.

B

B

Dispute label- oh, I can't add labels here. Can I.

D

You're not in tracker anymore, son,.

E

And it's just an executable flag: we're not gonna, try to figure out what the original read write or any other bits like the sticky bit or anything else associated to that file.

E

It's just if I had an execute bit put the execute bit in otherwise it's 600.

C

One thing that I know more or less for sure is that we don't want to add: we don't have permissions at group level or all level we want to cut those up.

C

That's that's something that I think we that's what we want to enforce and I think in terms of like the right, we can talk about it and see if that's something that we want to have there or not, and that could be part of the story just make sure that this is just specific to uh to um execution or if you know at the right, as well as part of the story.

B

So what would help here? Do people.

B

um Again want to, I guess, include some of this discovery work in here, or it could factor in the complexity of that when we point.

E

Whether you decided to.

B

E

With what I just said, which is, for the owner permission, make sure to retain the owner's permission on a file. I think it's right execute. Why not just throw and read as well.

C

I don't think you can have a file with read without having no, you cannot have a file without read and write it just right.

E

I can shmod plus one on a file and it just says, execute.

C

Is it the usable file, though so.

F

I don't think that's the question, though, could somebody have put it into a bundle.

E

Sure I mean in terms of implementation, we'll just make it simpler, like whatever this whatever's on the ownership permission flag, just use that, instead of like I only care about doing the math around the write and execute it. But maybe I'm just looking past something.

H

I'm cool with leaving it up to whoever picks up the story, to figure out what the the right ux.

I

Is is there a reason why we would not want to do the right like maintain the right ownership? Is there a risk to that.

I

Otherwise, I could, I could see dennis's point like you know, making sure it behaves the same like preserving that rights.

C

Throughout personally, I don't see like any problem in just keeping the ownership part. It was just we just talked about this because of execute, because that was the only scenario that we believed it was like.

H

C

Than like all the other scenarios, if you don't have rights, is that going to be like a major problem in theory? No, if you only have, if you, if you don't have read, then I think it's just like there's a problem with your bundle, because I'm not sure you can do anything about it with that file right, but the in the end, the the problem that you'll have is going to always be the the executable part, because you expect something to be executable when it's not or reverse. You expect to be executable, but it's not.

I

And if it's a writable, if it's, but then we revert the um axis, is that gonna be an issue or how often would that be a case, or would it yeah or actually more like? Would it be an issue if it's originally, it was intended to be writable, but we revoke that axis. Is that going to be an issue.

C

I think the question is reversed: if initially, it was not writable, we are making, it all is writable and if that's an issue- and the only case that I see that that might be an issue is right.

H

C

For ssh keys, the ssh keys cannot have right bit on them, but if you are pushing an ssh key in your bundle, that might be a different problem, but I can totally see like I think that, for this story, let's just add a comment there and say like discuss the possibility of keeping the ownership bits um when you pick up the story and then we'll go from there.

D

I think it would be important to know we don't want to. uh I don't think we want to propagate uh set uid bit and maybe that's part of what's being protected here. Don't want anything running in any elevated privilege.

D

So that might be a thing. Let's make sure we don't do that accidentally.

B

Well, we are at time but see if we can point this one quickly.

B

So three two one shoot we got ones and twos. uh Does anyone want to share anything in particular,.

B

All right, we can go to the majority, which was twos then.

B

And so we didn't make it to triage topics. um Apologies what to find well. Maybe we can try office hours for that, but yeah.

A

I can I can move those to office hours for later this week, cool thanks. I did see the the second one that was listed there. It looked like it was already closed. I don't know if the other two looked open. I don't know if.

A

I don't know I'll uh look into that anyways uh all right. Thank you for joining today. um As a reminder, we are going to meet for the first ever edition of the carnival office hours, which is later this week on thursday march 11th at 11 30 a.m. Pacific time, 2, 30, p.m.

A

Eastern time we're gonna use that time to go over some of the discussion or the other topics that we didn't get to today, um as well as any other discussion arms that might come up throughout the week and then also open up to any questions that folks from the community have, um if they're, also interested in becoming a maintainer contributing in some way. That's a really good time to participate in in that meeting.

A

So we look forward to seeing you then, if not, then we meet every monday for the cargo community meetings at 11 30 a.m, pacific time as well. All right we'll see you next time.