Cloud Native Buildpacks Working Group, 1 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-0701

Description

* Inline Buildpacks: https://github.com/buildpacks/rfcs/pull/86
* Application Mixins: https://github.com/buildpacks/rfcs/pull/87

A

A

As a reminder, please sign in on the attendees list, I'm going to remove the 7-2 meeting, because it's still the first, unless anybody had a reason they wanted to capture something for that.

A

A

Give people two more minutes to show.

A

And feel free to add any agenda items that you want to talk about today. Also to the end of the agenda.

A

A

All right all right does anybody know if we're gonna get ben today banner emily? Should we just get started without him.

B

uh Emily, I think, is still working through internet uh right from what she said in the leadership room.

A

Let's kick things off then so first thing on the list is uh standing item, uh introductions and new faces. um Do we have anybody? I think I see uh josh lewis. Do you want to introduce yourself? I don't think I can see you in a past meetings.

B

um Yeah I work on the same team as a lot of the other heroku folks here with joe and terence and jessie. uh It's just been a few weeks. I've been here a couple times, but it's really been quite a while um anyway made time for today.

B

A

A

uh All right, I don't think we have any other new faces. So next thing on the list is release planning and updates, that's usually emily and javier javier. You want to take it.

C

uh Yes, so for pack we just went into feature complete and that's releasing.

C

Next tuesday is kind of the the goal and um yeah. I think that should be out there uh willing to take anybody that could test it through their systems. But uh hopefully everything goes well.

A

Awesome any updates on life cycle.

C

Trying to see if there's any contributors here that have been working with it closely, I don't think there's anything slated until after pac releases at least.

A

Sounds good, so the next thing in the list is uh reviewing outstanding rfcs, uh so I'm gonna share my screen and we'll just go through them really quickly. I'm gonna skip anything. It's a draft or uh that is already on the list for today.

A

So give me a second to figure out zoom here everybody see that cool, um so cache types and application mixes are both giraffes and we're talking about application mixes today, uh inline build taxes on the list for today. Also uh so next thing is read: write platform volume out. Is there any progress on this?

A

What's your approval look like looks like it just needs review from terence.

D

C

Ben reached out kind of looking for some feedback. I did post some feedback on there. I don't think I've gotten any reply to it. um There is a separate rfc that I proposed and still in draft, which is cash types, that kind of answers to some of the primary goals of this one.

C

But I do understand that this one is, you know, maybe more encompassing, so I'm not entirely sure where to take it but yeah at least if, if it is approved, we could take it in, but otherwise I think there's a conversation still being had.

B

C

B

Last thursday, right where we talked a bunch about that.

A

So it seems like still a lot of active discussion here. um Maybe it's worth putting on the list for some week to keep talking about it. Yeah.

E

Like I at this point, I think there are philosophical differences in it, I'm half tempted just to call for a final vote and for a close with some disposition. Next.

B

Week um I I can't more strongly you know sort of describe my belief that we should have a very, very flexible thing here, and alternatives are coming up.

E

And this is just dragging on for weeks and weeks, so we'll just need to have an up down vote on it.

A

um Got it, uh let's uh maybe be worth scheduling a you know, impromptu seg, meeting uh to for people who still have concerns to get one last chance to realize that we have conflicting opinions or whatever.

A

I can I can organize that if I think it's a good idea all right uh next thing: offline, build packages, dan is planning to present this next wednesday and he apologizes he had got pulled on to working on something else for an extra week or two, but I should be able to pick it back up soon. I've been I've been talking about them. I know that's a one that we want to get through soon, uh image, pull policy, javier.

C

Any updates on this one- I don't know what the status is to be honest,.

A

You updated the rfc and, I guess are waiting for.

A

Reapprovals yep don't need to take people, I mean unapproved for some people- I'm not even on here.

E

So this uh I'm sorry, I missed that that had happened. um So you were going to split out the default change and just make this about the flag. Is that basically, what happened.

C

Yes and adding a new uh pull policy, which is, if not present, yeah.

E

Okay, I can probably approve this right after the meeting. I just didn't realize that was waiting.

A

Cool uh this is a platform specific one where only platform containers are going to approve or do a uh other people need to approve as well or is it do we need a core team vote.

B

uh Are we doing sub team style rc stuff today.

A

I don't know in the past we've talked about some some rfcs could go to sub teams. I don't know if practically that's happened.

A

I guess we'll assume it's.

E

Good, I think we should yeah. I think we should formalize that before we start running with it, that's but happy to try and formalize it yeah.

A

uh Next, on the list add rfc for stack metadata. I think this is. I thought this was approved a while ago or something changed again.

A

Okay looks like this needs more approvals,.

B

Yeah, I guess the only question I had on it was the open question that uh I think kevin put in the original rfc of just like. If you're putting stack stuff in the label in your rebase does rebase now update the labels for you or how does that work?.

A

um Rebase would rewrite the cool config blob to be whatever it's just rebasing the fs layers that matter and so changing labels on a rebase shouldn't be a problem or they don't there's no extra implication to that in terms of like having a consistent digest for some aspects of the image, because the config blob is going to change anyways.

B

So is the expectation like that pack rebase would update the labels if they're there, since they're kind of specked out.

A

I'd expect the stack labels to move with the replaced base, image.

D

Yeah, I believe the reason cache I put this on. There is just because to this point, rebase hasn't changed any labels. It's just been an update to the underlying layers and.

B

A

D

That made remix need to also change labels.

A

With calling out explicitly for sure um seems like action here is uh drive the rfc to call that out specifically and then ask for approvals again.

B

Yeah uh other than that, like, uh I think, it's a good open question and it seems good.

A

uh Root bill packs uh says: I think this is kind of on hold judge. Did you want to no just defer on that? Ca starts to draft uh exposing metadata any uh any word from. I guess we don't.

B

I talked to paul uh and he says he's looking at it uh now um he's coming back to it. Finally, um I think he may talk about it next time he's here next week.

A

Cool uh and then have image extensions is superseded by uh applications.

E

Of these other ones, yeah.

A

uh All right anything else on rcs.

A

I'm sharing my screen and moving back to doc. um Next thing in the list is rfc inline build packs uh joe. You want to take this.

E

Sure I think, there's just uh I know emily had fee.

E

uh The two things I think are outstanding on this are the use of the shell field. I don't know if maybe emily had another comment on there.

A

um I was gonna talk to emily at some point this week about why I think the shell field is important and that there are no other there's no good solution. That involves a shebang instead of the shell field,.

E

Cool and then the other one was terence's comment about an inline table or uh yeah, an inline table which, when I started playing around with got pretty gross so terence you're gonna, have to fight me on that one. If you still think that's important.

A

There's an inline table in tamil or.

E

No like inline as a table instead of a key like a string. Can you see what's on the screen.

A

Is there an example in the thing yes,.

A

In the readable section or it's in.

C

The screen share.

A

C

A

Oh, you don't have the screenshot open, sorry got.

B

B

I don't know if.

E

I don't know if you have any other thoughts on that. I get the value of it, but I don't like it.

B

B

Yeah I mean I, I also feel just like jamming a bunch of more things into build bill packs also feels pretty gross too.

E

Yeah, no, I mean I get it. I mean that's why I spent the time playing around with it, as I felt there was value, but like.

B

E

Is going to be 90 of them? I think it's.

B

Yeah, you can also do the, I guess, like dot, inline and then do equals and then kind of the curly braces as well.

E

um Yeah, how would that work with like the multi-line, the here dock? I don't know if that I have to play around with it.

B

Yeah, it may not work as well because of the multi-line. I think.

A

um I, like the word inline for the actual inline script definition and like script, seems generic. It could be online or it could refer to a file in the app directory. That's the inline build pack script right.

D

A

I wonder if a way to solve this is pick another word for that top level thing and let inline versus script either supply here's the inline definition or point to a script. But then you can have that structure and it might be less confusing.

E

Yeah, that makes sense, I think it's a structure. I don't like, though, like this is one of these things. In fact, I think it is the thing that I dislike about tamil is when you end up in this situation, where you have a table inside of an array, and it it's not. I think it's the thing that most people when they encounter tamil struggle with, so to make it this way for the sort of minimal case I just I don't know I I would need some convincing.

A

Is there a reason you couldn't do build.build packs and then inline versus script on the inside of that, and then you could have api inline and script as different options. Just like get rid of the top level thing there and then you don't need to replay it.

E

uh I didn't I didn't follow that.

A

So um imagine you remove the second line of the snippet right. So now you have in the build.buildpax object, you have an api and a script and then could you have an inline definition there and then vary on.

E

Oh and then any any other extra stuff would go in that table. Is that what you're saying.

A

E

Line yeah that would terence address the concern of just you, know, jamming more stuff into build.build packs, but still make it pretty convenient for the base case.

A

Oh, I see you're worried about polluting the name space of built up bill panics that makes sense yeah.

B

A

B

Initial con, it's not like a hard concern like I'm, not gonna die as hell, but uh the I guess I was just pointing out like I feel like this goes down a path of kind of like a lot of things in programming. Well, if you just add one more option, eventually, you like two years from now, it ends up being this like thing that has like 20 options on it right.

E

Yeah well, I know I like the idea of just using the table for sort of enriching it, but putting you know the the script itself as just a top level thing.

B

Yeah, just like in the rc itself, it felt really gross when, like you had to basically like clarify like well, these things are optional. These things are required and in this particular case.

E

Yes agree, but we already do have a good bit of that with version uri like I think the difference now is that it says it's. You know not just version and uri and one other thing being mutually exclusive, but like a set of things being mutually exclusive from another set of things, or something like that.

B

It's like a collected set. I guess you.

A

Could just prefix you could do inline and then inline dash api and then inline dash shell.

A

It's a little gross.

B

E

Well I'll I'll play around with it, some more uh come up with some other options, maybe um yeah, but that's all there is for that one. Unless anybody else said something anything else talk about it.

D

I just threw a question on there specifically about the mechanics of how this will work in a build.

D

Is the expectation that platforms like pack would need to generate this generated like a temporary ephemeral, build pack and provide it to life cycle? Or would the life cycle have some project tamil awareness in it? So.

E

uh Right so this would not be in the spec. um This would be a platform feature of pac and the question about buildpak tommel, I think, is a bigger question and yeah. Eventually, I would like to have lifecycle have a another binary or something that sort of pre-processes a project tomml, and this again this doesn't have to be a spec thing. It could just be a tool that comes with life cycle, that processes a problem, project tamil and emits whatever the other phases of life of lifecycle need, so that might be machine, readable, json files.

E

It might be a build pack on the file system. um Does that answer your question.

D

E

I guess I'm just trying.

D

To think like, if I was a platformer legislator, either of pack or capec, I would actually implement this as spec today. It.

B

D

Without the existence of a lifecycle prepare, we would actually read the project tamil and then construct uh ephemeral book pack on the fly yeah. If you wanted to.

E

Support it, that's what you'd have to do. I think uh another thing that's kind of brewing because of uh at salesforce we are using project tamil is. What does it mean to support part of project? Tommel is: are we actually winning with project tommel? There's? I have a bunch of questions about that and I'm hoping I'm hoping to bring those to ahead. Sooner than later,.

E

Yeah I haven't, I don't actually have a good proposal yet, but I'm trying to come up with something that might lead to just better options for getting support into into platforms without having to uh now, I have to repeat everything that pack's doing.

A

I like the idea of introducing that optional life cycle binary, it's like pac, might not use it because a lot of project tumble is parsing. You know what not to upload into the container right, which can't be a life cycle concern, but there are other parts of it that need to get processed into data that the life cycle should parse too. It's a hard problem.

E

Yeah, potentially, that would could lead to splitting project tamil out into like its own library and pac uses it for that optional and binary and pac uses it or lifecycle. Is it for the optional binary and pack uses it for whatever it does? It might help with that.

A

Well, anything else on inline, build packs.

A

Once going twice, moving on to application, make sense.

E

Yeah, so I'm just about ready to open this as a real pr. It's in draft state right now, but I think I've wrapped up all the loose ends from the conversations we've had over the last couple weeks, so just to go over what I captured from last time.

E

uh One of the questions was how to specify this in the builder tunnel or an order, so I've introduced stack.buildpacks there's no order. They're just all run until you meet the project's mix-in requirements.

E

That's the proposal happy to go back and forth on it. I removed the mix-in type thing and just went with the the pattern that uh steven had proposed and.

E

I did keep a type in the plan for provides and requires again happy to go back and forth on this, but something about the implicit like a regular build pack always requires, and a stack pack always provides just didn't sit super well with me. So I was trying to think of alternatives for that um yeah. We can discuss that. uh I know we weren't happy with privileged as a key that as a way of indicating or distinguishing a build pack from a stack pack, but I didn't come up with anything better.

E

So would love suggestions there.

E

I added somewhere in here that stackpacks must ensure abi compatibility and that rebase yeah will continue to work. So there's no like pack upgrade or anything like that.

E

The caching I borrowed from one of the earlier rfcs, so I've introduced excludes into the launch tamil. You can define a bunch of paths as being excluded from the image, but still cached or not cached.

E

I had a little discomfort with a stack pack that executes on the build image. Writing a launch tomml, but I I can still think of a case for process types from a stack pack. So it's kind of interesting uh yeah happy to discuss that and then the last one was oh ben detect.

E

I think it should have access to the application source code read only which would make bin detect dynamic, which means I don't think we should have a like static, detect result.

A

Doesn't that break rebase, though.

E

No because you don't run detect on rebase.

E

Or I mean like you, wouldn't like what I'm not sure what how that would break rebase. I guess.

A

um You'd assume that the initial invocation of the text, output against you'd have just like store the initial output of detect from the build somewhere and then replay that on rebase, making the assumption that the application directory didn't change. I think.

E

No, it works. No, I don't think we I'm not sure I follow that like. Why would you run?

E

I think we I thought we established that you don't need to run the stack packs on on rebase, because they'll they'll ensure api compatibility unless.

A

You start to run build on rebase right in order to replay the changes on top of it. The api compatibility isn't isn't. Okay,.

E

A

E

Yeah, no, I misunderstood that. I thought we were saying that you as a stackpack author, must ensure that a rebase will still work and if that's not the case, then that changes this a little bit. That's fine.

A

So api compatibility just means that dynamic libraries aren't going to get swapped and changed. It doesn't mean that a file.

E

Yeah yeah, I'm.

A

In a file, which is a different thing,.

E

A

E

You're right, I'm I'm sort of abusing the term, but um no yeah. I thought we were saying that uh that the file system, whatever changes that that stack pack made, would accommodate or you're just accepting that you're not going to get get it to rerun. But if that's not the case, that's fine because I actually had it that way. Originally.

E

um So, if so, and if that's the case, I think we should like you, were sort of starting to describe store the output of been detect and just pass it into build or do what you need to do. So you don't run detect.

A

Got it that sounds good. There was an issue that, without a fur, for a stack image that has a stack pack that can dynamically provide mix-ins and build, it becomes impossible to select, uh build packs.

A

Statically, I think, knew you brought this up, that might be usable on the base image or not or there's there's no way of predicting that unless we like expose some metadata that says hey. This has a stack pack that can provide mix-ins you're not allowed to do static, validation,.

E

Well, I didn't follow that just update again.

A

Yeah so right now you can make a build package that has metadata on it. That says this build package can only be used on base images with these mix-ups and we use this a lot on the.

D

Vmware side.

A

If stack packs can dynamically say what what mixes they provide at build time? You can no longer do that static validation to match build packages with the correct stack images um you have to try a build and see if it fails, so you need a in the case that the stack has stack. Packs you'd need to put some metadata on it. That says hey this has a stack pack and all bets are off with mix and validation.

A

You should be allowed to. You know, put kind of get the problem.

E

Yeah, I do know.

E

Does that mean it's limited like? Can it provide?

E

This is the subset of mixins I provide, but it could potentially provide more than that.

A

That could be a solution or well if it can provide more than that. If a stack pack, if there's like a static list initially, then it can add to the static list, then you still couldn't do static validation because you wouldn't allow any.

A

You know the package. That's set up front. These are the mixins I need you. You'd have to allow that to be used with the the stack, but you could provide less you could have it say these are all the things. This is the range of things I can provide, and then it provides more specific lists during the text that would be okay,.

D

I think we had a conversation about providing what some form of wild card support.

C

Yeah, just post it in the chat, a link to what I think is like a gherkin form of the expectation that I think the platforms would be.

C

E

Oh in the uh where's that.

C

So it's in slack. Ultimately, I could just copy and paste the whole thing.

A

My browser is not authenticated with slack right now, so you can't see it.

D

Zoom chat, if you have it open.

C

There you go zoom chat, I just posted the whole wording.

C

It looks nicer in.

C

A

What's the use case for the stack pack being able to express the requirements during or sorry the stack back being able to see the app directory during detect.

E

um I don't have a specific use case. I thought it would be a capability that would be valuable, um I'm happy to think through it a little bit more to see. If it really is, I think part of it is also if we do eventually have a real root, build pack kind of concept. That is a little bit more.

E

You know powerful and maybe forces you to give up some things. uh I would like it to work the same way. um You know where, like a root, build pack is just a build pack that runs on your app code, and you would expect then detect to have access to your app code.

E

I think, but I think the question here like that, like having access to the app code, I don't think is terribly controversial. It's the whether the bin detect the mix, it's not even been detected, it's really the mixins it provides.

E

Do they need to be dynamic or not and if like, if, if it's just static, mixins like maybe bin detect, isn't even the right place for that like maybe we should just get mix-ins out of the build plan and put it into the build pack tomorrow, like I know, has been suggested.

A

I mean, I think it is. It is dynamic without the stack pack having been detected because the requesting build packs can dynamically decide what build packs they need right and then those those get sent to it without needing the bin detect of the stack pack to be dynamic, because the the list of mixins that gets installed is actually the app built back case is actually coming from the other build packs that do get to dynamically decide what they need.

A

It's just the constraint the like. What are all the things that I could provide that gets output during bend, attack to the stack pack and that's whether that needs to be dynamic or not that I'm curious about. I don't see it all right.

A

I don't have a strong opinion of whether it is, I think we can handle it one way or the other, but I'm trying to understand what the motivations would be for making it dynamic, given that it's just outputting the range of things and you still have the other build packs dynamically saying what mixes they need.

A

Does that make sense yeah, I'm not like trying to pull it. One way or the other I'm just trying to understand what what makes the most sense for the problem we have.

B

So, are you suggesting that the bill packs list them statically ahead of time or.

A

uh I think I could see two implementations, one where, like in build pack toml of the stack pack, it says this is what I can contribute in terms of mix-ins right that, like what the app build pack, there would be with that right, jax right and then the other build packs. The tax scripts can output. um You know, mix and re requirements, then get fed to that build pack and are passed through that filter right automatically and that filter being a static thing. Would let you do pre-validation like oh yeah.

A

This can supply anything I can put whatever build packages on. If I want or or not it has, that that benefit. If it's static, if it's not static and bin detect can output it, then it seems like the app build pack would always output the same thing, anyways right. Yes, I can provide whatever um and or like. I can't think of a situation where you'd make a stack pack that dynamically determines the filter.

A

Does that make sense, but there could be- and I think that's a good reason to figure out another solution to the static problem. If we have that problem. But that's the part that I'm like curious about.

E

Is that strictly a performance thing where you don't want to have to go through every stack and run the the text, so you can match a build pack like that, would just be too that'd be terrible. Is that kind of what you're thinking.

A

D

I don't know if it's probably performance, because I imagine the detects would happen very quickly. It just seems, like stack packs, are trying to solve a very thin use case um and it might actually simplify the creation of them if they're just statically defined uh what they can provide.

D

um Additionally, it helps with that problem. I think we talked about a little bit ago, which is a stack back statically describe what they can provide. We can figure out ahead of time is ever a chance. A build would ever successfully execute with the build pack to like give the user some heads up before exceeding the build, so.

C

A good example could be in pack if you create a builder right. If I'm not mistaken, we would go through the create builder process and you could potentially create a builder that doesn't work together. The way that you expect it to, because you don't know that the basically there's there would be no way to know that the stack pack doesn't necessarily actually work with any or this build pack right. That you're also bundling in this builder yeah yeah. That makes.

E

E

Yeah, that's actually that feels pretty important that you can create a builder that is basically broken.

D

And you wouldn't find out until the every single build of it always fails.

E

Yeah well, okay, so I'm I'm. I think, I'm pretty convinced that, like we need the static mixins, uh probably in buildback tommel. The question then, is: if we need been detected all um like, I almost feel like. We should do nothing with it so that we could potentially reserve it for in the future if we decide. Oh, there is this case where you want to dynamically, just provide a regular provides or we do want to introduce and to provide mix-ins into uh the build plan.

C

Yeah see the way I thought I understood. This was like the pattern for the bullpec tamil works so that we know what build packs are compatible with the stack pack, but then the detect phase, the way it provides mix-ins is maybe not so much by patterns but very specific mix-ins. That then says: oh the app needed this one. So yes, I'm able to provide that one, and that would be essentially a subset of what the static uh pattern was.

E

Yeah yeah, that's actually the way I thought about it at first too, but I don't know if been to tech can do that without the like the processed build plan, or I guess I mean yeah like what's it gonna do, is it just gonna? It's like it's gonna, be like life cycle, be like here's, the mix-ins I need and it will be like okay, I will give you those mix-ins like I don't know if they'd ever be any different.

E

Just by the build plan, you would have to look at the app and that I, even though I just don't, have a use case for it. Yet I just just something I feel would be expected and potentially useful.

A

I mean it. The dynamic part is the other, build packs figuring out what accents they need right and then you could have nothing for the stack packs for detect, just not not implement, detect for stack packs and then always feed those mix-ins through and fail milliseconds later in the build during the build phase, when the stack pack says, oh, I can't provide those mix-ins right or you could have a static declaration up front on the part of the stack pack. That says this is the range of nixon's.

A

I have right that you could pre-validate, even even before detection, if it's truly static right or you could have something in the middle where during detect it outputs the nixon's. You know like filter with mix-ins that it's allowed to implement, so we could fail during the detect phase and the thing in the middle.

A

I like it's hard to understand the motivation for that versus one of the two other sides. If that makes sense,.

E

Yeah I mean: are you saying that detect would like look at the mix-ins that are required and then compare that to some package repository index and say: oh yep, I've got those I can't install those. Is that kind of what you're suggesting it would do.

A

um Detect is always in parallel right, like build packs, don't know what about each other during later attack phase, so they can't you can't get the mix-ins during detect and then read them and then.

E

Oh yeah, I guess I was thinking like the app makes sense.

A

That makes sense. Yes,.

D

A

Yeah, so the dynamic mexicans coming from the other packages that the base image doesn't provide right like if you're going to send it to it during the tech you might as well just send it to it during build, because at that point you know you've already you're, not you're, not running the detect.

E

A

Serial serialized thing.

D

Would it ever be useful for detect's only purpose just to fail if it's unable to actually do what it claims it? Can it's purely like a fail, non-fail case.

A

You can see that you can provide you just do both right. You could have static, mix, ends and build pack tunnel, for instance, and then detect could further constrain, that, based on the environment and app directory.

A

That would work too.

A

I'm curious for the need to output a dynamic filter, though that's what I don't understand as much.

A

I'm not opposed to it. I just want to understand it better.

E

um Yeah, no, I mean, I think, I'm saying I'm convinced of that too.

E

uh What about the so? I can work through that. What about the privileged thing, oh by the way uh non-item potent, is used in an http spec rfc, uh so deal with it, uh I'm happy to change that, but I've got nothing um the privileged. uh I can't remember your reasoning for not liking that I think it had to do with the fact that it doesn't do like what you would expect from docker like if you patched privileged or something like that.

E

So it might just be the wrong or misleading or something like that, but we need something to distinguish a stack pack or or potentially just a generic route build pack from a normal, build pack.

A

um Privilege sounds right for root, build packs like that. That seems like it's a really good way to describe that really technically accurate way to describe that and what other people use, but we have to distinguish a stack pack from a root, build pack also right.

E

Do we, I don't know if we do like you, could potentially use a root, build pack as a stack pack, and it might not do what you expected it to do like? Maybe it just doesn't provide any mix-ins, it doesn't mean you can't use it as a stack pack.

A

I think if you can provide more information about what that could look like, then I'd be more comfortable with it, because.

E

What what could look like.

A

About what it would look like for a root build pack to be used as a stack pack or it seems like it's, um it's like a confusing pre-optimization.

E

I mean the thing I mean the case that I was thinking of was like.

E

Well uh guess, you'd still, I don't know all the cases. All the cases that quickly came to mind. You'd still probably provide a mix-in, even if it was just like set equals or something.

E

um Yeah, I'm sorry uh finish your thought.

A

No, I I think I see what you're saying you're saying like you're trying to make it so that stackpack, the stackpack interface matches their buildpack interface and that the context for which the root build pack is used determines whether someone's making the commitment that it follows the api compatibility constraints and can be used in a rebasable way of the stack pack right and so privileged would be the way you indicated as root build pack and then deciding where you use. It is how you indicate it as a stack pack.

A

That makes sense, I'm just um if you could put that in the rfc uh and then like.

E

Actually, if we're doing the static, mixin thing, the combination of privileged and mixins would identify it as a stack pack more narrowly.

A

But that's not the mixing thing isn't determinable until detect. I think it depends on what we do at detect right if detect looks like different than rebuild max, then it's a different thing. If detect looks just like rebuild packs, then it's probably the same thing in contextual.

C

Can we maybe be more specific or explicit with the types uh I think we mentioned that earlier? We already have two different types, which is the standard concrete, build pack and the order build pack, and now we're going to introduce the stack build pack. So, instead of you know, assuming based on the information that you input, we could use something like a type field, that's very explicit to say what it should be and then could maybe potentially even give more guidance that way.

B

That was a suggestion from last week, right.

A

Maybe I think joe, maybe you're, trying to avoid too many types or you're trying to say like there's. We don't have two extra types, there's just really one extra type and there's a way you can use it. That applies more compatibility with that.

E

Yeah, I think yeah, that's exactly it like. I'm hoping and I could be wrong just in the way I'm seeing into the future, but like I was hoping that if we had a type field, it would not be type equals stack that it would be type equals root. You know what I mean and I I could be wrong about that goal, but.

A

Can we defer the decision about how we type it until we get the rest of stack pack developed? So we can see like? Does this look like a rebuild pack and then either make it look like a rebuild pack and use privilege true or decide, and it's actually needs some other field.

E

Yeah, it seems like we can do that. I mean I don't think we'd have like it's not like. We'd have to rewrite the whole guts of it. Just because that configuration thing changed.

A

Yeah, I think I'd be happy to go with privilege, true if what we end up with looks like it's applicable in there, but it seems like the other questions we talked about earlier matter too much for me to be able to make a decision on that. If that's helpful, yeah.

B

Is is there a case where item potential is true, but privilege is false.

E

Oh yeah, I was wondering about that too. um This reminds.

B

Me of like the when we did the uh kim khan one year when we talked about those like cash flags from back.

E

Yeah and we're we made the matrix I'm having like my parents, thinking.

B

About like these flags right now, I'm just like no.

E

B

E

So imagine there's no privileged. It's just defaults to false and then item potent non-item potent is true. um I think that's like.

E

I think that means don't give me my don't like don't give me my run image layers and and all that stuff. Maybe the cache too.

B

Yeah, I I guess part of it's just like I would ex. I would like to see it in this rc if we go down this path of like actually walking through that table of that matrix, because I feel like that's what we had to do for cache to some kind of like. What's this use case, what does that look like?

B

um If we can't enumerate those, then maybe these aren't the right flags.

A

Item potent equals false or equals true without privilege equals true. I don't even know if that has very much meaning right. It would be like don't recover cash layers, cash busting, build pack or something.

E

Yeah, which is like well, why did you cache stuff.

A

Yeah yeah yeah.

E

Well, I guess: no, because it could uh you could contribute something to the run image or the launch image that you don't want to get back right. But I guess you could just like blow it away. It would be like it'd be a way to like not put that rmrf line in your build pack or something.

A

I think that build packs explicitly turning on layers when they want to keep them right, that dot, tumble dot, cache thing that was proposed that interplays with that a lot or it would make a that item point flag, less, useful or less meaningful, because.

D

A

Is nothing gets recovered until the build pack explicitly opts into it? So that's that's an interplay. um I I gotta drop off a little bit early, but I had one question um around ca certs. So we said this model works really well for ca certs, um but we haven't talked about that in the context of mixins, because I feel like they're not mixing right. So you kind of stack pack that guarantees the base ability. Name.

A

Sorry, the guarantees, the ebi compatibility right um and would reapply like when the upstream ca starts change because one of them is removed because it's no longer trusted because you know they got hacked or whatever, and you don't want to lose that removal right. That seems like a really good use for stack, packs and ca certs. But if they're tied into the mixins api like is there a workflow where you have a stack pack specified, it says?

A

No, I don't provide any mix ends, but it still runs every time right or or or should c asserts. Should we define this by saying the bionic stack defines a special news. You know thing like set equals. That's like cert equals right or something that means uh I provide some ca certs or I require some ca certs, but it doesn't.

B

Even might be dynamic.

A

Right it really.

B

A

A require so that's also confusing.

E

Yeah, I'm inclined to say you just want something that runs all the time.

A

um A way uh to think about that, maybe in this context is maybe this is the thing that drives out having separate, requires and provides for the stackpack uh as part of the build plan, because then the stackpack could require and provide a mix-in, and then that's how you achieve. Yes, it runs every time uh and then then that drives out the other change you mentioned, which is like, maybe, instead of mix-ins, what type requires and type provides.

A

It really is just fits into the normal build plan as a requires on the other end and there's a key under it. That's like mix and equal true right, then it looks a lot more, like the other build packs too, which seems like a.

A

Plus, I don't know that that would be one way to solve it. That kind of goes towards your goal of making it feel more like build packs.

E

Yeah, I guess that does mean you have to run the bin detects of all the stack packs every time, even if there's no missing mix-ins right, because they.

A

E

And require their own.

A

Sorry um they could still be static.

E

D

um If there's very.

B

D

If they're still static, would they just not run if they don't have a detect? Are you saying that build packs would just indicate they know how to handle ca, certs and we'd skip even their detect.

A

Not sure I understood sorry.

D

um A build pack that provided a cia cert, would it never run detect and just indicate that it knew how to handle cia certs, essentially.

A

A stack pack that provided a case would it no longer run detect it's like uh imagine, I'm not saying we should do this, but imagine that the build plan contributions from stack packs are static and defined in the pectomil right to do ca starts. You do something like require.

A

You know, mix and equals true. You know name equals.

A

We'd say: cert equals yes, as the mixer name using that set equals notation right and then you can also control like build and run to determine where you want them and then you'd also say provides mixing equals true name equals search equals yes, and then you know something like that. You do maybe not. Yes, there may be the name of the certificate that this you know ca cert.

A

Installing stack pack is going to provide right or my company ca certs, something like that um and then because they're they're matched up they're statically defined initially in the build plan format it doesn't need to be resolved by another build pack and always happens and fits into the thing. Does that answer your question.

D

I think so I was just trying to understand like how you know when to execute the ca search, stack pack, and if that was the case, the csu stack back, which is always execute. You ran build and in the case that no ca cert is actually provided. It's just a know. What.

A

D

That'd work, it might be expensive because cs certs are the stack. Packs are fundamentally running in a different.

D

Running as root executed by lifecycle, so some some platforms that might be its own container.

A

Stack packs are always run per build, though right.

D

Yeah, it's just. There is a cost there, probably more than just a regular build pack.

A

A

If a plug, if a platform wanted to implement it not per build, it should probably just extend the stack image, though right.

A

Yeah or use a different strategy for ca certs, like any containers.

D

Yeah, I I'm approaching this all of a pure build basis. I know we've discussed non-per build as well, but it seems like we at least need to support per build.

B

A

um Joe is this helpful feedback for you.

E

A

Cool I get to drop off a little early um thanks, so much uh someone else can pick up and they're more things.

E

C

I removed my item just based on the time allocated to it.

E

What was the item.

C

It was the cash types, so that's a draft pr, but I know that there were some discussions that probably wanted to be had in relation to the volumes, but we could do that tomorrow.

B

Sounds good uh ben won't be here tomorrow, right.

C

I wasn't aware of that, but I think nonetheless, some of the things that I want to add. Probably to the volume uh which is what he's proposing is at minimum and it's you know for it to be behind experimental, which I think has already been discussed.

C

And if that is the case, and I think that should be acceptable.

C

But I do agree with him that they are solving you know or speaking to two different personas.

B

Sure uh yeah, let's talk about tomorrow and then cool we can follow book. Then, if there's other.

B

Stuff well wow. It sounds like that's it uh for today so see everyone tomorrow, who's coming tomorrow, thanks everybody thanks. Everyone.