Cloud Native Buildpacks Working Group, 5 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-08-05

Description

* Exec.d: https://github.com/buildpacks/rfcs/pull/104
* Any Stack: https://github.com/buildpacks/rfcs/pull/97
* Opt-In Layer Caching: https://github.com/buildpacks/rfcs/pull/99
* RFC for RFC
* Image Signing

A

A

A

A

A

A

A

Oh running late,.

A

Wow uh many people here today.

A

Let's see what we got uh everybody signed into the document, I don't see any new faces, uh javier. You want to talk about any release, planning.

B

Yeah, I could speak for uh emily who's, not here as well um from what I recall. There is a release for life cycle that is planned for the end of this week. I think the hope is to try to get it out tomorrow, but if not uh friday, other than that um there is a scheduled uh ccb or code freeze, feature complete for pac on tuesday.

B

So again, if there are any issues or pr's you want to get in before that point in time. Please do so now. I don't know natalie or yael. If you have more insight into the release uh for life cycle and what all it entails.

B

um Yeah emily gave us a bit of a rundown yesterday or the day before I there's a handful of issues.

C

That we'd like to.

B

You know do work on uh before the next release. I believe.

C

She's targeting this week for that.

B

And then, if I remember correctly, I think uh the latest build pack. Api version is what's going to be supported, which is, I believe, is uh buildpack04 um so yeah. I think that might impact some build pack authors at least they could take advantage of newer functionality that way, but it should still be backwards compatible with build pack api 03.

A

Great have anything else.

A

No okay, let us begin the great rfc rundown.

A

Which one do I want? It's this one sorry pull requests that sounds right: uh rfs to drafts offline, build packages, rfc, I'm guessing! This is who's in control of this now.

B

uh This would be dan uh last I heard uh there are still conversations being done. I don't know if there's been any real updates to the rfc itself, but progress is being made, at least through conversation.

A

Sounds good uh applications joe's unlikely to be here to talk for that, uh terence, you have any input on application mixins and whether it's moving.

D

uh I know he's working on the stack packs stuff uh with emily, uh just working on kind of poc implementation of it, okay and then cursing go. A lot is what I've heard in the leadership room, yeah.

A

Yeah, that's that's a pretty common from java developers who, like having you know functionality in their languages. uh Okay, um experimental features.

A

uh Same from him, this one last time this was touched was six days ago, but it sounds like joe's gonna have to answer for that.

A

A

B

I don't think I've seen a lot of movement here as far as questions or anything else. I've updated it. So my hope is to get people to review it. If not, I guess I could start poking people.

D

B

D

The only thing that's contentious is like space.

D

I don't think that right, javier.

B

I don't even think that that was very contagi uh like there was a lot of argument there um based on our last working group meeting. If we feel like that is still something that we need to discuss, I guess we could bring it up when there are more people available.

D

Well, I'm just trying to I remember from the last working group like there was a set of things that were talked about, but I feel like.

B

Yeah and I think.

D

I addressed all of them.

B

Yeah the resolution was ultimately to go with the lowest uh level of effort, which is to keep the space uh denotation um but yeah again. If anybody feels strongly, then we should definitely be having those conversations.

A

uh Yeah, so it seems like was that eight days ago, uh so I'm not sure if dale's on the call, but you and uh you should vote along with uh you- terrence joe I'll bang on stephen a little bit to make sure he does his as well.

D

Yes, also paying travis to vote on this yeah, just because it's a pac thing for platform.

A

Great, he has now been notified that his presence is requested.

B

And stephen is here: hey steven.

A

Hey experiment: oh nope nope we already passed experimental features. uh Pac sub commands uh would like a vote from you. Do you have any outstanding questions about it.

C

uh Nope, I will I'll go add that.

A

Okay uh layer, origin metadata is drafted project descriptor flexibility uh is this joe again? No! No, this is you uh terence.

D

Yeah, I think, there's just there's. I heard there's some discussion that I wasn't here for last week in relation to josh's rc from the schema stuff.

D

A little bit for a few minutes: okay,.

A

Okay sounds good, just want to make sure it's moving along in a way that you are happy with or if you would like to demand people review at this time.

A

uh Any stack build packs. This is you stephen right.

C

uh Yep it's this. This just needs approvals from people right yeah. I think.

A

D

A

Think I opened.

D

Or I had uh just a question around kinda default.

D

um Well I made that comment earlier today, but yeah.

A

Yeah, that seems like it just needs a response: more we're good to go there. uh Almost everything else has made it into fcp uh show free profile d.

C

Yep this one needs more discussion.

C

uh The someone I forget who it was someone in there pointed out that the n format that we were going to use doesn't support new lines at all works for everything, except for new lines, no, no special character problems or anything else, except except new lines, because that's the one separator they used to find the thing. um So I I listed some options at the bottom and I put, but I I put it on the agenda, so we could talk about it. Okay,.

A

Talk about that in the agenda, then that is it.

A

uh Next item in the agenda: exec d: go ahead: stephen! Let's talk about that.

C

A

C

Seemed pretty good uh and then at the last minute um I think it wasn't someone from gitlab was: maybe someone from google chimed in and said, hey wait a second. I know this actually works, uh then whatever that is uh the so I listed five options down there. uh One is we could just not support new lines. I don't think that's a good idea.

C

uh One is we could come up with a different way of encoding new lines, because it really is just this one problem: it's not it's not like a general special character problem. It's like new lines are the problem. um That seems pretty weird, though I don't want that new format. um You know the we could use tomml and maybe maybe, instead of using our key value, key equals value, equals format, because it's all supposed to be machine readable.

C

You just use tomml as the way to specify keys and values, would look just like environment variables, but with you know, tamil doing you know managing escaping and you use tama libraries disadvantage there is that you're using the tamil parser during launch right. So, if you're using like burnt sushi and does a lot of weird reflection, uh you know it may add a couple extra milliseconds to launch time. I don't think it's really a big concern, especially because it's flat list right, there's not a lot of deep nested structure in there.

C

You know we could benchmark it. I'm not actually worried about it. I just thought I'd call it out.

D

Can we define a schema to disallow basically inline tables or something.

C

Well, this is going to be a flat list of environment variables to go straight to another process, so so any anything that is not literally key equals string value is invalid. So, like yes, very simple, okay,.

C

um The we can make sure the launcher doesn't like refuses to parse anything. That's not literally. You know, string string.

C

The next two options are maybe slightly more standard, but also kind of more exotic, like the weak bash, actually has a format and there's even a posix standard format, sort of for listing environment variables like this kind of um that's, uh you can use export-p and it'll output, something in bash five plus usually doesn't have any problems before bash. Like 4-4, though there are a bunch of issues with it and it doesn't actually work um with some characters.

C

uh So I gave some options there in four and five. I wouldn't really recommend either of them. That's pretty weird, especially because we don't bash here and can't really parse. That anyways, like you'd, have to write a manual parser for this stuff for the use cases we care about it. For so I'm not very partial to those. So I think I think tomml is pretty good. There's one option that uh someone, because the guy from get lab uh mentioned, uh I forget where he mentioned. This might have been over slack.

C

We could chain them together, so we could have each exec responsible, like you could pass each exact, the next exec and the chain and hope that they correctly exec, meaning the syscall exec like exec v or whatever the next process uh with the right arguments. It would be especially difficult for the last one, but then you'd have the inherited environment going all the way through that's kind of tempting, because I could see the perfect behavior for preserving environment variables.

C

But it's also like putting a lot of trust that each author of each exec script is really going to execute the next process perfectly. And so I'm it's a good idea, but I'm pretty skeptical. I I feel like it's a little risky.

C

I've been here.

A

I had a well-written comment that basically said: hey like this is a giant pain in the ass, because imagine, you've got a bash bash, build pack and you're um trying to generate tommel as output, and I'm like oh yeah. He can't execute that kind of build back here. So I guess that doesn't matter like I'm surprised, you don't like four right, like the life cycle should be able to parse that relatively easily. It's intuitive like to be bluntly, honest with you.

A

I am surprised to hear that four just doesn't work right like it's exactly what you'd expect it to be um so like that feels like something we have the ability to write or to to parse nicely and reflects what I think the instinct of contributors uh of contributors of environment variables would do. In fact, I believe this is like sort of all the places we do. This kind of thing we literally write out that kind of output.

A

It is all single line, admittedly, um which then just gets wedged into an eval statement in a lot of places. So we don't have a shell to eval. This sure agreed, but, like you writing a parser for that, like it's, not the most complex thing, I've ever seen.

C

The I don't know how well this format's defined, I think the stuff between the quotes there's a bunch of weird escapee things. You have to do for special characters. That aren't like this example is a simple example, but it's it's not yeah. It didn't feel like it was enough of a standard. I was really hopeful about it for the same reasons like even if you're not going to shell parse, that, even if export and declare are literally meaningless, commands you're going to stick in front of each line.

C

For no reason like I even thought: can we strip out the export or the declare dash x and declare the format to be like thing equals thing, but then that middle format, it just varies, how you escape the middle thing varies between versions of bash tremendously for three they're totally different escapes, and it doesn't work completely for four plus it works, but it's very complicated it just it started to seem like it wasn't worth it. Is it not worthwhile.

A

Like yeah, okay, and so the tomal representation of the same kind of thing basically looks exactly like that, except without the word export in front of it. Doesn't it yep.

C

And the inside of the quotes has very standard, well-defined. You know ways of escaping characters, because tommel has a spec um unlike bash inside of thing, and so it basically gets you that that's kind of the thing.

A

Yeah, you know it's interesting. um The spring boot team recently had to describe the syntax of a file that they needed internally.

A

That was going to be a list of things and they described a syntax that was effectively a subset of yaml so that they could use a yaml parser if they had one available to them and so like I'm, not sure we should particularly define it as this is a subset of tamil, but you know we can describe a syntax here that is, in effect a subset of tamil, so that you do have some convenience.

A

If you want to use it, that's.

C

Pretty good, I don't think you need a tamil parser in order to output it or to read it. If you really didn't want to use one yeah agree, tom will allow quoted keys. That's the only thing, but again if this is a subset, if we say you're not allowed to use quoted keys when you output it, then you know.

A

Yeah and I think that's why the the boutin did that particular thing rather than say this file should be a yaml array. They said file needs to start with a dash, have a space and then blah blah blah.

A

You know whatever it is, and I think, even if we sort of think of it as a subset of tunnel, we should define it the same way right, like uh whatever the character set and then an equal sign, potentially with white space on either side and then the rest potentially quoted right like and then, and then that gives us the ability to to be a bit more specific and then use tooling. That happens to understand. That's that's upset.

C

That sounds great, so subset of tunnels such that the key names are unquoted, valid environment variables and the values are double quoted. uh You know values that you know they can't be single coordinated or used, tomel's other notation or literal strings. Yeah.

C

Well, I don't know about multi-line tommle to think about what multi-line tomml looks like. I.

A

C

It's okay, um cool! So that's that's exactly.

C

uh Were there any questions, the other? I know I opened a ton of rfcs the beginning of the week. Everything is in fcp, but terence. I wanted to make sure you got a chance to review everything because I know you're out last week.

C

D

Think I read most of the stuff um that you've basically dropped in the last week, like seven rfcs or something.

A

And you, I believe, five out of all that you responded to two of them, uh so stephen keep an eye out for those notifications.

D

Yeah, uh I guess my probably the one I had the strongest opinion on was the annie stackville pack one, and so I wanted to talk about that. uh That was, uh I think I definitely want this functionality, um but I'm curious if we want default to not be uh assuming it is any stack if it's empty.

C

I'm I'm very torn on this. Also, it's like.

D

Yeah, I guess like I I don't know like I there's a lot of use cases I can think of wanting this feature, um so I'm nothing for it, uh but I wonder like ben, I think ben was one that made the comment about kind of having to opt into it um and I'm wondering if what brainstorming from last week there was on.

D

Is there like a middle ground here that makes sense for opting into it versus just turning this on by default for everyone.

A

Yeah, like one of the questions I actually have for you steven, and I don't have a good grip on this- is like how realistic do we think it is that a build pack in any build sorry in any stack build pack truly is any stack could run both on a linux and a windows stack.

C

I think there are two questions in there um in in reverse order, because I think the answer to your question. It helps answer terrance's question um the a statically compiled go binary right that includes lib muscle in it is going to run on any linux like that, you know um a build pack, that's bash script that only uses bash built-ins right, yeah, um probably gonna, you know, comply as posix compliant. It's probably gonna run on a very.

A

C

Number of stack images right yeah, especially because shells are almost always in the build images yeah so, but.

A

Now, it's not that's, not any stack.

C

Yeah, but it's close enough that if you have a build time failure because it doesn't run then.

A

C

A

Sorry, no! No, by that I mean that's, not windows, stacks right, you just express any linux right, not any any.

C

Yeah, so, okay, so that's a different problem. That's that that's! Actually. I was very worried about that and thought we need to introduce another key for operating system, but you can't actually start that build because the build pack is is going to be in the build package format for windows not to build package format for linux, so you wouldn't be able to get the build pack onto the image anyways. So that's it.

A

Was very worried about that sorry is the build package format for windows specified anywhere like in a distribution spec or anything.

C

uh Great question for.

B

I don't, I don't believe it is okay,.

A

Just this was the first I heard the statement. It is not the same build package and I'm like oh okay, I'd like to read about that. Then.

C

That makes sense it can't be. It can't be the same, build package, because the pads are all unique style pads and it's it's a linux layer right. uh It wasn't like a explicit decision not to to be non-standard. It was a needs driven.

A

You know yeah yeah, I'm just I'm interested to know what that is like. If I wanted to start creating windows build packs today, I'm interested in it, but anyway continue along. So there you go.

C

So, given that we're not it's not operating system constrained, you know we're just talking about linux, build packs being able to float between different stacks right.

C

You know it doesn't worry me too much to just allow build packs to say whatever just try to run me if it fails during build. That's okay and the best ux for that in my head, given what we have is like leave the list empty right. The list is a list of restrictions.

C

If you don't have any restrictions, it runs on everything that feels like it's, a very good design, sort of what it looks like as opposed to introducing a random bull. That says, if this list is empty, don't fail. You know that seems like a weird thing to do. At the same time, you could totally see people just saying: build pack build pack tamil, oh, I need. Oh, it doesn't work if the file is empty. Here's an id uh doesn't work if the version's empty here's the version. Oh my build pack works.

C

Now I'm going to ship it and then it doesn't work on everything. But at that point like didn't you kind of make this thing with the idea that you know you kind of wanted it to just work on things and if it fails during build, then you know that's kind of your fault. It's like as a build tech, author, you've kind of shot yourself in the foot there. You know you're not going to do a good job of making sure your build pack is perfectly compliant with whatever stacks you've selected anyways, like I'm.

A

Sure yeah not totally convinced.

C

That it's you know.

A

Yeah, like we all, we all claim to be compliant with bionic, but, like I don't know like I don't know what heroku's bionic stack actually looks like and whether it works until somebody actually goes off and runs it and opens a bug and says hey. This doesn't actually work right like we're doing the best we can.

B

I mean I do wonder, go ahead out here.

B

Yeah I was gonna say like I do wonder if the the need for id is really there right like, if you think about make sense like you would think about labels and any sort of like resource driven uh system like the mix in or the label would help you better narrow down what the compatibility is for said resource so like, ultimately, what I'm thinking is I'd like to be able to specify you know stacks without having to specify a very specific id, but still be able to provide labels or mix-ins. That say, you know windows.

B

You know for the lack of better example right or linux or some other arbitrary. You know convention that the community comes up with that, then signifies the same thing that it would as operating system right, but without being specific to that nomenclature.

C

I think that's what we were trying to do with there was a an rfc a while back about making stack, ids, not specific right, instead of there being a stack id for the heroic version of bionic or the cf version of bionic. There's an rfc where we said the project will define. I o build pack stacks play on it, because anybody who's going to use a bionic-based stack, that's derived from ubuntu column.

C

Bionic should use the same stack id, and so it doesn't create fragmentation in the ecosystem and the reason why I think it's important to at least differentiate very clearly at bionic versus focal versus whatever is they all have different abi?

C

So, if you ask, for you know lib anything, you know image magic, any library the abi is going to change between bionic and focal and change potentially drastically between those- and you know, however, it's built for for ubi, and so you know being able to say you know the binaries I'm going to install are linked against.

C

You know this level of compatible library right or being able to specify a mix-in. That's you know, libsy, plus, plus, or image magic or whatever, that code will actually link to. When you install it seems like really important so that things aren't just horribly broken. You try to run them.

A

Yeah, and so because the mix in syntax is like semantically, like as we discussed in previous meetings, is semantically adjacent to the actual stack id itself right. We've designed designed bionics mix-ins to be packaged names, but not all stacks would design mix-ins the same way like, I think it sort of acts as a first level selector right similar to your you know, linux or windows, and then underneath it. You can describe actually what you need to run. Given that sort of core screen selector.

B

Right, so what if you know, I hear a couple concerns like if we were to leave stacks completely gone right, um which it means that people might not add it and inadvertently create something that now assumes can be run on any system. What, if we actually left the key and then for id, did something like an asterisk right like a special character or a special token. That signifies I explicitly say that this could run on any stack right and then you can still leverage uh mixins for whatever they may mean.

B

For the specific stacks that you have in mind, you know to be able to actually run this with. Would you be.

A

B

To what does that mean.

A

What does that mean? What was that magic character mean when combined with another stack id? What does star comma the bionic id in the same stack array mean at that point: does it mean star minus this star plus this, which is star again, doesn't matter what order they're in maybe.

C

It means when you use this other stack id. These are the mix-ins you need to have with it, but if you don't you're, not using that stack id and you uh you know uh yeah, if you're not using that stack id, that's specified, then it'll still try to run it. Just won't, do any validation and then mix-ins is not allowed, probably with star, because then you get this problem like the mix and names mean different things in the different stacks.

A

So it's a find gr, fine, graining, a specifying of for a particular stack. This has this adjacent, this additional behavior, maybe a personal requirement.

C

Yeah, but maybe a clear way to do it is a boolean. Instead of is like any stack. The boolean is like skip validation like skip validation when the stack id isn't present. Try to run this anyways, you know if, if the unknown stack id is there, you know don't.

A

The the advantage, the advantage of javier's star suggestion or whoever came up with sort of an opt-in, but the star one specifically, is appealing, because my memory of stack declarations in build packs is as an allow list right. Like you put in the things you want to run against so an empty one in the old way of thinking about it means I run against nothing versus having a wild card.

A

All of a sudden says I do run against something, and you could imagine something like io.buildpax.ubuntu.star right, because I actually want to like all of the ubuntu related ones, actually describe stack uh mixins and the exact same syntax like this might be enough.

D

Yeah, that was the ben hit kind of the comment I was gonna make. uh I guess when I interrupted javier was yeah, I mean it is an allow list, and so this changes it. This change is kind of, I guess the original definition, uh which was also why I was thinking about that, but.

A

I didn't think.

D

About the ubuntu star thing: that's pretty interesting.

A

Like maybe maybe this this actually and instead of saying any stack, build packs, what we should actually be saying is wild carded stack, ids.

C

So that that starts to scare me, because then then you can do things like say. I want image magic right. I want some c library and I, but I'm okay, with any abi like like with different apis right of that same library and on the hope that you're, like you're kind of hoping for something to happen. But the result you get is pretty bad, which is that whatever you install probably only works with one of them right, because you've built a binary against.

A

But so I don't think this change is sort of like rebase behavior. Once an image has been created right, um you can only rebase that image off of the concrete stack id you'd originally chosen.

C

Sure but but during the build process, you know how your your build pack is still going to have this problem, where it needs to select the right binary. That was built against the right version of image magic for the stack id.

A

Oh, I don't, I don't think, that's necessarily true right like as long as you, you could imagine like compiling against it locally right like as part of your build phase. It just needs to link against it once um and then you're ab you're guaranteed abi compatible against the thing you just linked against right and if you care more, you can say here is exactly the concrete version of a particular version of ubuntu that I want.

D

I guess to me like it: if you're, if you really want to do that, you would just in kind of the current rfc proposal. You just leave the list empty versus, like what ben is saying right, and so you still run to the exact same problem. You're talking about right, stephen.

C

Yeah, but I'm I'm worried about an interface, I'm worried about creating an interface where people can do something that looks like it should work right. That looks like they're, adding just the right level of validation and then when they actually try to use it, it has unexpected gotchas. If that makes sense, um I'm I'm fine with adding star as an option and then for this rfc and then expanding on it in the future to allow for wild card matching.

C

If the wild card matching or something like you know, you could match, you could guarantee that this will only run on ubuntu based stacks right. You know where that are part of the io build tax, bionic project where all of the um you know, mix-ins are defined in this very particular way right. If there were a way to constrain it. To that, I think I'd be okay with it like, because it is talking about build time validation.

C

But, as you point out, it makes me nervous, but it doesn't make me nervous enough to push back on it. um So so generally. Okay- with that, I I just I would want more constraints than just arbitrary wild card matching on stack id. I think it need to be like I o build packs stacks star.

C

A

Of like yeah that may that may want to make us want to, for example, repurpose I I was, I totally blanked on what it's called. Currently, it's called I o build pack stacks, bionic right and so, like anything, you'd wild card would be. I o build pack stacks right, and so it may mean that we actually need it to be. I o build pack stacks and then two bionic company focal, and then I o build pack stacks rel, whatever the hell rel calls their releases kind of thing to help with that or introduce.

C

A class another bool or sorry, another string field that represents the you know, type of distribution or something like that. But.

D

We could just define a class, I mean based on the spec, can't we just define a stack that we can define a stack that is like ubuntu, that is, that star or something in theory.

C

It is that, oh, like you, could define literally define I o build pack stacks ubuntu.

D

A

Want to make that a bill right like I.

D

Think the benefit of potentially not having to change your current rpc, a ton. It's like as a project. We can define what these stack like what log cards we want.

C

I o build pack stacks. Ubuntu would be a stack id that you would want to put on both ioble pack on a run image that has iobill pack stacks bionic on it too, so it still validates that that would require a lot more changes like you'd. Have you have this concept of multiple stack ids on an image that are compatible and then you have to match certain ones up in certain cases and other ones up in other cases, but I think the general you know we're talking about ux for the next generation version of it.

C

I feel like maybe it's good enough now to say, like okay, we'll allow star as a value yeah and then you know nothing else for now no mix in specified a star, and then uh we can. I wanted.

B

To make an argument for that last piece like, I think there is value to be able to have mix-ins with a star and I'm thinking more specifically for a scenario where you know you can think about a enterprise and they're controlling both the builders, the stacks and the build packs themselves, and they have different people that are in charge of the different aspects of it, where they're just creating the stacks themselves and then another set of people that are creating build packs. Or even you know, as part of project tamil.

B

You could import local build packs, and at that point you know that there's a certain convention to the mixins, as you know, kind of going back to what labels are, and ultimately I wanted to apply to any build pack or sorry any builder or any stack, because these are the ones that I'm allowed to use, and I don't want to have to keep updating this list of available stack. Ids right like I, don't want to have to coordinate that effort between two individual teams and I feel like it goes back to that philosophy.

B

Right of allowing it to be open and really only tightening it down when we feel like there's a real need for it, and this one doesn't feel like there's a real need to put in that restriction.

C

I think the the problem I have with that with with allowing the star to specify mix-ins afterwards, is that if you say your build pack supports star, and then you say it supports a mixer name. That makes the name can become something completely different on a stack, that's not related to the buildpacks. You know packs I o project so, like you could say image.

C

This supports star and image magic, and that makes perfect sense on all the ubuntu stacks, where image magic means the ubuntu package image magic, but that could mean something totally different on a stack, that's not defined by the project where we've said that we do package names mean or what pixels are defined as it seems like mix ends, are namespaced under each stack and it's it. It's like it. Lets you break out of that namespace, but keep the thing that's inside, of the namespace as a match and that that seems like it's.

C

It's weird yeah.

B

But I mean I'm I'm in the scenario or this environment, where that's the functionality that I want right like. I want to be able to use this mixin as an arbitrary label, not so much to mean anything specific to any uh stack outside of the ones that I have and use as part of the contract. For you know, my employment.

C

B

C

Another concept.

B

My domain right.

C

B

C

Concept, though, like.

C

It seems like that's, that's like you're, consuming, build packs and stacks and you you're trying to match them up. Maybe that's not how we want to use mixins, but I probably don't understand what you're proposing completely. I like the scenario you described.

B

Yeah I mean I I'm pretty sure we could refine it further um yeah. Obviously we could iterate on it and this would be a really good step forward. Nonetheless,.

A

Yeah, so my vote is for now basically to introduce the first wild card right star and then see how wild cards work out and then a subsequent rfc six months from now that says, oh, we should actually have wild cards in other ways as well, so that we can select all of them twos or all rel's or all whatever uh later on, but I don't think it's required like this is the first step in a concept and we can enlarge that concept in the future if it's appropriate.

D

uh What does star mean? We talked about windows containers, it just doesn't apply, or I felt like we were talking about that before right.

C

It applies but because you can't you can't package, you can't distribute a build pack that works on both linux and windows, it's kind of irrelevant, if that makes sense it's like in the windows context. It means any windows stack in the linux context. It means any linux stack.

B

So I have some concerns about that statement, because this, like we're talking about and time distribution to compatibility where I don't necessarily think that that's completely true. If we talk about like the case of local, build packs from project tamil right, you could then run that on a windows container builder or a linux container builder, and it doesn't know or care at that point because it's packaging it ad hoc at that point in time.

C

At that point, though, is it really that much different from like? Oh, my local build tag doesn't work? Let me just throw the stack id in the stacks list. It's like you're, talking about the build pack before it's, it's been processed into a an artifact for distribution, and so it doesn't like you can have problems like do all the files have the right line. Endings, you know, is everything actually executable in this environment. It seems like it's.

C

You know just because there's a shortcut that'll, let you build the build pack into something that it shouldn't be built into. That feels like it's. Maybe a different kind of problem. Yeah.

A

Is it a bash script or not, for example,.

B

Right and bash grips would work if you have bash installed right.

A

In your windows thing.

B

C

B

Again, I'm just I'm just throwing out like like uh depending on this, you know, facade of distribution, for the compatibility check doesn't necessarily seem like it's a very strong verification process, not saying that I have a strong stance, I'm just saying that we should use that with caution, because it is possible to fall into that scenario.

C

I think a way to solve that would be like your build pack has to declare what operating system. What what like general, I don't know how you describe that like types of operating systems, your build pack is, you know, defined for explicitly. Instead of relying on you know the line endings in your build pack tunnel, matching the right operating system or whatever right like we can make that a lot more explicit, and I think that makes sense. um I don't know if this rfc needs to do it, though right.

A

I don't think this rfc prevents.

C

Us from being able to do that in the future.

C

Not definitely not opposed to introducing that I just I don't unblock that.

C

Cool, I thought this would be the least controversial one and that'd be like sorry. I was really surprised well well,.

A

It's like, I think we all want it. It's just coming. Yeah.

D

It's not the context.

A

To get it there.

D

Yeah, it's not controversial. uh I feel like a lot of ideas, aren't necessarily super controversial. It's just like what the implications are with backwards and power to be able to your defaults, or things like that. That have to be thought through, probably a little bit more because we are so far along in the project and that's like the tricky stuff makes sense.

C

I I just want this so like I'm still working on pac file, and you know it doesn't. You have to explicitly specify all the stacks so we're just trying to get some text in there. Yeah um the that sounds good, um I'll, I'll update that to include the star. You said there terrance, there were two: is there another one? You want to do.

D

A

Yep, that's the one that I just did a giant paragraph worth of stuff back.

C

And and this one yeah, um so I think the way we have it right now is like really dangerous and that nobody, nobody like it's a big oversight in a way that, like we it's possible when you're writing, really simple, build packs to accidentally leave stuff around in the image at the end that your build pack has. No, you know information on and that just you know like a simple bill pack is gonna, not use the caching strategies and tend to rewrite stuff anyways right.

C

um So I was, I wasn't sure, like I know, terence, if you wanted to talk about your.

D

Sure I I guess just from seeing third party bill, packs uh kind of on the heroku side, like uh I definitely see like for sure what you're saying like the there's build packs that don't do caching and that's definitely the first iteration of it and then people it becomes probably a little more popular than they thought. And then people complain that it's slow, so they introduced some type of caching right to basically speed up, uh maybe downloading or compiling something like.

D

I definitely seen build packs that early as part of the thing literally compiled the package in the uh didn't compile. uh So I guess, like the names appropriate there um in the old pack api uh and then like oh yeah, so then they like basic cache, protect they they do the compile still because, like they don't have a place to store the assets like. We don't provide that as roku, for instance.

D

Right um so they'll do the compile and then they'll, basically just like store it in the cache right, the kind of compiling, and then you can copy over at least on second and every other, build after it's at least faster, um and I also understand the dangers, uh and I don't necessarily I don't like for a lot of these things. I don't disagree with the changes like. I think they are better, um I'm just thinking about like uh for the default or- um and it doesn't mean like my comment- isn't like a blocking comment.

D

Just like a comment I think for discussion of like. I think we should think about this uh and it's more of okay. Like do. We expect a bunch of people coming in using this thing to expect it to function this way, um and maybe we do uh I mean it's just like this- is the right way to do it and they should learn how to do this um and also made me think like.

D

If that's the case, for some of these rfc changes, we probably want to maybe even explicitly call out like documentation or other updates. We have to make, um even though, like that's kind of assumed with andy things, but this for sure feels like one of those like. We need to be very explicit about this kind of change. Coming in um yeah I mean I, I think it is like a probably like if you are a bill pack author, who is probably not as well-versed, you just thought about like.

D

Why is this thing dangerous, like we've all like, I feel like this change comes in because we have been doing build packs for a while and they and you you do think about some of these things, but I think for like a more casual, build pack author who doesn't do this whole time, it's just like trying to get a thing done to like move on with their life and solve the need and they're just trying to get some optimization. It is like more complexity that you have to think about.

C

That makes sense yeah that definitely makes sense. I I definitely agree that we should be very loud about making the change and document it. um The you know I was wondering if there was an interface you thought would be more obvious.

C

The first version of this I proposed was like rename all the directories to dot something and then force people to renew it back ben had a good idea that I I think, is just strictly an improvement over that in terms of usability, and I was hoping that would be like a good good way to not make it too much of a breaking change right. um The the thing that the like just to talk about the reason why I feel like it's worth it.

C

um There are a lot of scenarios where it's easy to build up a cache like like in the old build pack interface. You could build up the cache too big right, like you, could just keep putting stuff in it as old versions of build packs. That happened a lot in our previous build pack implementations, but it's also like that feels like it's the build tax responsibility. The dangerous thing here is: this is like a a weird kind of cash.

C

That's a cache that also ends up in the image which wasn't like how buildpacks used to work um and and can affect. You know, directly affect the environment that the image executes it um and that like, because it's this kind of hybrid cache realizing that made me go like whoa this. Could this could lead to something really bad and unexpected or a security vulnerability. You know, um and so so that's why I kind of felt strongly like it.

C

It was worth it even though it is kind of a big change if it's kind of helpful context for like.

D

C

Only true when the.

D

Launch is true right that ends up in the image for the cache.

C

It's true and launches true, but when builds true and cache is true, it also affects the build time environment, unlike in the previous, build pet caches. Just like here's, an empty directory, you could throw as much stuff in here yeah it could get really big, but as long as you're, not using the stuff that you know you conglomerate in there, it's it's not so bad, but in this case it actually affects path and led library path, and you could set an ld preload right. You could do some really nasty stuff.

C

You know a million versions ago that suddenly apply in the future when you upgrade your build pack to a much newer version and that that made me worry about it enough that I thought you know this is this is kind of widow blocking.

C

Not not like pushing back in your comment just wanted to help explain why why I thought it was worth worth bringing up and and getting through and or coming up with an interface to be liked for.

D

B

uh uh This is an unrelated question. I wasn't sure if there were still if there were more open questions on the opt-in, caching, but an unrelated question that kind of came up in a early discussion today. um If I would want to, let's say, have a change to the rfc process um where, as part of let's say, merging in an rfc, um it would also um incorporate opening issues in the fought in the re, like the relevant repos. um Would that how? What would be the best way of doing that?

B

Would that require an rfc to I've? Seen okay,.

C

D

It should be a pretty hopefully simple and clear-cut, rfc.

B

Exactly I don't want to put extra work on on management and, like you know, like the the core team, it's just. I sometimes want to make sure that things actually are are implemented and sometimes otherwise things can fall through the cracks. Emily has.

D

Shares those same thoughts and has been pushing us for doing some of those things so having codified, is definitely in the direction that cortain wants it to be in.

A

I I'd really like to vote as a a pre-vote on that rfc coming through. It says if you are the owner of that rfc when it gets merged, it is your responsibility to open issues.

A

If you care about this, if you care about this rfc's content, you need to make sure that someone knows that it has to be implemented. Now, that's fair.

C

um I had actually one totally unrelated thing that I forgot to put on the schedule this time so on another list ahead. um Does anybody have thoughts on sorry? Was there anything else on the agenda? That's appeared. Am I talking over somebody else's thing? No, okay, um the uh has anybody had thoughts on image signing recently or looked into. We need to have it had.

A

B

There's an open issue and pack about it right: yeah yeah, it's been open.

A

For a while, though, and absolutely no one wants it to be notary.

C

But I think it's kind of gotta be notary. That's the problem.

B

Yeah, I was gonna say I think this notary is the only.

A

B

A

So that's that's an interesting statement like uh speaking internally inside of our company.

A

The vibe I get is if it's notary we're not doing it right, like we'll, invent our own thing, which is like not a very healthy situation to be in but like if we added notary support, it's unclear to me that the broader community would use that notary support at this time. That's.

C

Again, with the same internal head on I'm getting the opposite signal, so we should we should oh we're going to talk talk about, but I think from from different perspectives, we have a lot of people asking for image signing for um things they want to build with them yep. I agree um the uh I think the big thing we're blocked on is making a decision about can't. Should we use notary and then figuring out. Who wants to to do that work?

C

um The I think it has to be in the life cycle. That's the main. The the hardest part is it's not something that someone could go out and build on their own, because we need to do the signing unless we're going to pull down the image again, which kind of defeats the purpose right exactly. We need that we need to do the signing as we generate the manifest in life cycles. Exporter phase.

A

Yeah and I'm also uh like, if we, when we eventually do an rfc around, that I'd like to see an rfc written with an abstraction in place of which notary is a single instance of it so like flag to pass not like a flag that says, I want to sign this image but a flag that says to sign this image. I would like to use notary yeah right.

A

I thought it was almost.

C

A

Notary can't survive. I just can't believe it, so many people hate it so much.

C

Docker docker container trust docker trusted. Something is like a.

A

C

As a subset of notary or like a easier amount of notary to use for images- or I don't know, if you read the docker content, trust website, it seemed like you know. Maybe it was something that we implement just that that workflow and I don't know enough about it to say, uh didn't natalie did you do, uh or I thought somebody here did a like an investigation into container signing at some point. Maybe I'm confused, though.

B

I think we gave it, you know a glance. I don't know that we ever went deep into it. Why do people.

A

Hate notary so much.

B

Because it requires a central server that that's at least one aspect of it.

C

I mean notary is in the update framework, or you know two projects together, that are another cncf project, right uh that we should. You know, look deeply at and consider whether you know they make sense for this use case the I.

A

C

A

Also, a problem with how, like notary signs, the wrong stuff and like makes things more brittle than it really needs to be things like that, is that right.

C

Some things like that, you know it's definitely.

A

B

I don't wanna introduce any. I mean I just seemed like the there was. There were clear, negative vibes. I was. uh I totally knew.

A

I was like the only positive, the only positive thing I've ever heard said about notary is. It currently exists.

C

We are, we are on youtube.

A

I got no problem saying that.

B

But but there doesn't, there isn't a another popular.

A

Remember yeah it.

B

A

It is a very, very difficult problem is part of the is part of the issue right like they did the legwork. You have something and that something is better than nothing. But apparently it's also not bad enough that anyone is willing to forge ahead and try and have a competing thing.

C

It's very complex and intended to solve some larger problems, and then signing looks like oh. This would be a great use case for this much. You know more complex way of sort of collecting metadata about things or whatever the goals of tough are, but the you know didn't end up. Looking like a really simple put a signature on an image, go validate it when you pull it type thing.

B

I feel, like I remember, seeing something about. Oh, maybe google is going to do something about it, but john.

C

Johnson was like propose something I think a while back sorry, you're right that that is a thing I haven't heard anything about it.

A

Okay, one o'clock.

C

Four o'clock: thanks see ya.

B