Cloud Native Buildpacks Working Group, 29 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-10-29

Description

* Stack Buildpacks: https://github.com/buildpacks/rfcs/pull/111

A

A

Thanks um is that, okay, as a format, this time yeah, um do you want to edit it or I'm happy to do that.

B

Also, either way yeah, you just mean like in github, yeah and github directly.

A

And is this you integrated the changes that we made on top of yours.

B

Yes, I didn't merge it, but I went through and copied them one by one.

A

Awesome so let's um can you make the window a little bit taller, so you can see more.

B

And that was a little bit taller.

B

Is that better? I didn't want to make it too tall perfect.

A

Okay, so um let's just start at the top and go down with this group here and um as soon as somebody gets to something or well I'll, I'll speak aloud. What's there and then make sure everybody has agrees that it's the thing we want and if any questions come up, we can talk about them. um If anybody has any reservations about anything at all, speak up immediately, it'd be very forceful about it.

A

If that makes sense, so we can make sure that we're all you'll have consensus um so starting on 14 proposal for a new type of build pack that runs against the stack in order to extend it with in ways that are only possible by running privileged commands. Good.

A

uh Normally, build packs do not run as root intentional design decision ensures that operations rebase or except day, two. That makes sense. However, applications require modification to the stack they run on adding system packages ca certs. This is mechanism stack authors, build pack, authors build pack, users leverage to extend their stacks. That seem accurate.

A

um Be helpful everybody get thumbs up, so I can see just so all on the same page uh root build pack. um Do we want to keep the concept of rebuild pack in here? I am okay with it, I'm not opposed to it. It's come up a few times um javier thumbs down. What's up you made it, you muted, your headset's, also down.

B

Too many buttons um all.

A

Right uh yeah, I don't know if it just adds to the complication of.

B

This particular rfc, if there's no real other mention or value to it, um but again not strongly against it. It just feels like it's clutter.

A

um I think for this, if you're, not if you're, okay with something going into it, and you wouldn't like to propose an old alternative that adds something you know just we should we should keep going through it.

B

uh It's not yeah, I can remove it. It's not used.

A

Yeah, because we we talk.

B

About it as an alternative- and I think that's what makes it confusing right.

A

It seems like everybody would approve it if it has root, build pack or if it doesn't have root. Build pack. Is that correct.

C

Definitely not going to stop me from improving it might as well. Take it out to keep things simple, all right.

B

Yeah, I'm fine with that makes sense cool and then I.

A

B

To edit that wording, yeah type of bill pack perfect.

A

Okay stack, build pegs type of build peg that runs against the stack image. Instead of an app stack, build packs may make changes to build and run images that either violate compatibility guarantees or violate the contract determined by the stack author. A user space build pack has a traditional build pack must run as root launch images. Final image, good.

C

Stack build pack a type of build pack that runs as root against the stack image. Now that we've taken that type of root build back.

B

With privileges, maybe.

C

B

Oh god is that right.

C

But then e that's right. I think.

B

That's with an e literally the hardest part of this rfc.

A

A

The word launch image there that refers to the final application image is that right.

B

Yeah, I think um I had to introduce that here because, uh because words are hard, I think that's probably something we should promote into the spec as a.

C

Spec is a competing term.

B

Image- oh that's probably. I was probably trying to avoid that at some point. I can switch launch image to have the image here. If we want.

C

Let's go that benchmarks in the spec, not the kind of thing I would have pointed out, but since we're going through word by word,.

A

I've heard I've heard people use, launch image to mean run image also, which is yeah.

B

That's very similar.

A

um But I agree: app image is too specific, but I think just to match the terminology. We should change it later in the spec. If that makes sense,.

B

Is app image official in the spec of what it's called.

C

B

I got them all.

A

Cool, so I think we're a little further up. I'm sorry good.

D

I'm just waiting for us to rename launch equals true to app equals true at some point just to make it really consistent and also.

B

I thought we didn't like the name app. Wasn't that a thing.

C

B

C

It, but I don't I haven't heard any other word- that we like better.

D

I really don't watch image either like launch.

A

In for clarity, app image is very clear what you're talking about in the end. For now, we can change it in the spec later um for okay, a new type of build pack called a stack pack, uh maybe running into stack in order to extend in ways that are only possible earning privilege commands, unlike user space, build packs a stack, build that can modify any path in the file system user space. Build packs can can only create modified disk joint layers, which makes possible features like individual areas as independent or ordering um is any path.

A

Okay. There is everybody comfortable that, given that we mention exceptions to that path below.

B

Almost outside of the workspace directory.

C

The whole list of exceptions you see any path and parentheses, excluding the exceptions below.

B

uh Can you just say most pass or something uh with acceptance? Yeah, that's.

A

Fine uh user space build pack can only create modified disjoint layers. A stack pack may also define a list of mix-ins that it can provide to the stack or indicate that it could provide any mix-ins. In this way, a stack that is missing and mixed and required by a build pack may have that mix-in provided by a stack, build pack. Does that seem accurate to everybody? The mix-ins come are specified in buildpectomel statically and we'll get to that below.

A

A stack provider may choose to include stack packs with the stack they distribute. If the stack includes that file and associated stack packs, then the following will occur.

A

Platform may compare the list of mixes that are statically required by all build packs in the stack section that build techno file with the static list of mixins provided by the stack packs in the stack section, but they're build pectomell and fail. If the build chooses to do so. So this means that.

A

This first thing is the current thing we have in build pack tommle that specifies the mix-ins that you need on the stack in order to run, and the second thing is a new list of uh mix-ins in a separate part of buildpack tunnel. That's static that specifies what those stack packs can provide. Is that right?

A

Everybody have that understanding, it's statically provided and then that one that one can have a asterisk and be any cool during the detect phase, lifecycle will compare the list of required mix since the list of mixins provided by the stack and stack build packs in accordance with state specific mixing rules.

A

um If any mixings are not provided, the bulk will fail to accomplish this list of runtime people to make sense already present run image and build image must be provided by the detector.

A

So what does this mean?.

A

D

Yeah, this is the part that isn't yet implemented, so it's probably still a bit fuzzy to to most but yeah. I think the detector now has to take in. We didn't really specify the format here, but it's going to take in run time and build time makes sense. I guess build time mix. Ins are already present, so maybe that's written kind of kind of wealthy, but.

C

They aren't to the detector right because they're on a label on the image for the detectors inside the image, this was.

D

C

The stack tunnel is in there, but we haven't specified unless it's been added to this pr. um How make sense would be described in the stack tunnel yet.

D

Yeah- and I don't even think we went as far as saying how the mix ends are going to be given to detector. So at this point that's kind of.

C

One point I was feeling like this: it could be an entirely sometimes it's a totally standalone thing that I think could be an rfc on its own, because, right now the life cycle doesn't validate to make sense for the build operation right, but it very well could.

B

Yeah, it's all done by pack right.

C

Yeah, which is kind of bad, I feel like pac, should do it up front, but the life cycle should do it again. You know client-side and server-side validation,.

A

um Would you change? Do you believe anything in that phrase is wrong and do we need the extra detail of how those lower-level interactions happen.

C

I think eventually we need the detail that detail is going to need to be in the spec right.

A

Maybe not in the rfc.

C

It'd be helpful to have in the rfc, but I believe that we can sort it out and I'm okay emitting it.

A

That's good, so the next thing is the life cycle will run the detect phase for all stack packs defined in order tunnel and the stack order tunnel and then for all user space, build packs defined in order tunnels that makes sense to everybody. Stack packs run first, have a separate order definition and then the order definition for normal, build packs runs.

C

We need to talk about how, because I think it's not just two separate orders right. It's like the stack order is inserted into the beginning of every yeah.

D

I think that's regular group a little bit lower.

B

I don't think that means he hasn't said that that feels wrong here. That's more.

A

Implementation- maybe this needs to be a little more vague, actually because it suggests an implementation that is maybe not accurate. It's like the life cycle will run the detect phase, which we're all still it's terrible effects to find in order tomml and.

A

Such that you know as if they were one order, tumble together or whatever.

C

Yeah, an order will be synthesized from the two ordered tunnels.

A

Yeah, that's even better.

B

Merge and run, or do you want to do the synthesized thing perfect? That's looks.

A

Great right now, um during the build phase, potentially in parallel to the extent phase, uh the life cycle will execute the stack, build pack build phase for all passing stack packs as root life cycle, will drop privileges and continue to run the build phase as normal running users table packs and then separately in the extend phase. In parallel to that, this is for the run image. The runtime stack packs run in a separate container against the run images.

A

This all makes sense to everybody. Detect, happens, forks off two containers running in build running and run.

A

uh You know the same: build packs presumably have to be present on the run image as the build image, because the detect is going to only run in the build image versions of those things.

A

Good to move on cool uh how it works. Stackpack is a special case that build packs has applied properties. We agree that they run as root that uh you use the privileged true flag in order to mark a build pack as a stack, build pack.

D

We need that. I question that at some point I kind of wonder like if we have our own order tomml for stack, build packs that is kind of set by the stack. Do we need to have this flag.

D

B

D

Yeah, it sort of implies, you can have an unprivileged stack, build pack as well, which is the part I don't really like.

C

And at one point we talked about changing this from privilege, true to like mode stack or stack true or something that's less about whether it was privileged and more about whether it was a stack back.

B

I think this is an artifact, because this was split off from root. Ball packs right. It is it's not because of the the stack order tunnel, the one that's described here. We do not need it. However, I feel it is easier to remove it later and ignore it than it is to add it in later and require it which would potentially break existing stack packs.

A

Stack packs have different behavior than normal, build packs, and so to me, this serves as a validation that the build pack you're talking about is, in fact a stack pack, because otherwise the interface is so similar and there's no other way to change it. I have no opinions on what the name of that validation is, but does anybody think a we should not have a validation like this and build tech table for the rfc.

A

Does anybody think that this this key needs to be different in order to allow the rfc to pass.

A

Then I think we're good um next thing is: uh can only create one layer per image, both the layer for build packs to build on top of and a layer for the app image everybody agrees. Backpacks generate one layer that can go into the final image. You can exclude cuts of that right, but they're they're, cached and recovered only during the build process, and so uh we're talking, maybe one layer per app image would clarify that a little bit so there's.

B

No such feature as like uh the app slices right right: okay, yeah.

C

I will say per app image helps the pedantic part of my brain, because we call cached layers layers and therefore it technically can make two layers.

A

um It does have in parenthesis where it's both the build, both the layer for the build packs to build on top of and a layer for the app image. Maybe that's not clarifying enough actually.

C

Both a layer for the.

A

Because, in the build case, it actually does build a layer.

C

Then I think it has three layers right or four, because you have two cache layers for each of those cases as well.

D

We change it to one snapshot layer or something like that.

A

So in my head this on the build image we generate one layer or we're not going to support building on top of the previous layer. So in the build case, do we actually generate a layer off of that at all anymore? Maybe we don't.

B

C

We we're supporting excludes, which creates a entry in the cache right. We all historically have always referred to such things in the cache as cached layers. So it's not an exported layer or a build layer, but we would call it a cache layer in the spec.

A

In your head is that that actually just one layer for all the excludes together in my head, it was actually a separate layer for each.

C

Exclude I don't either one of those like we can make it one cache layer per excludes or a single cache layer. I don't care about that, but in it's it's this is saying it isn't a layer, but that has always confused me, but.

B

I think this is actually not a layer, that's just stuff, on the file system.

A

So maybe we say.

D

uh At some point we talked about, after all, stack packs are run, we have to clean up stuff, and so part of that might come into this, like if you're going to have to define what what needs to get cleaned up before you run normal user bill packs.

C

Yeah, I think that part is analogous to if a regular, build pack created a build, true launch false cache, false layer. We call that a build layer, even though it's just stuff on a file system that never gets packaged up.

A

Maybe this, instead of worrying about all the details of the different layers, which are probably covered later, we say, can only create one get rid of the thing in parentheses and say: can only create one layer that ends up in the app image and that's that's what that's intended to communicate.

B

That is exported in the x into the app image.

A

A

And then kill the thing in parenthesis afterwards, because that seems to be confusing. Everybody like that and agree with that phrasing awesome uh may include in the created layer modifications to any part of the file system, excluding app layers platform and cmd directories. What about temp? What about the other.

B

Yeah, this is incomplete.

D

I have the complete.

B

One somewhere, I think, oh.

D

And it changes based on os as well right like some of these, you know a specific you know, white out layers or directories or something yeah.

A

Perfect, um did you maybe just link it to the.

B

Completed list so that there's no ambiguity.

D

I think there'll always be a bit of ambiguity, just because, like the way canico works is based on whatever you're running on. I think it's sort of figures out which directories to exclude um so, but I don't know, maybe maybe we can be more strict than that.

B

But how about I have this spelled out somewhere explicitly.

A

We say excluding app layers platform and cmb directories as well, as other directories mentioned below, and then we can go back later and add a.

A

Link and you can kill the button I'll limit it too. That way javier is pointing to that, but we'll we don't have to go figure out how to make a link in the market. Yep.

B

I have the canonical list in the spec changes down at the bottom.

A

um Must not access the application source during the build phase? Does everybody agree that, during the detect phases, read-only access to the application source during the build phase on the build image, there is no access during the build phase on the run image, the application is not there. Everybody aligned on that idea.

C

They should because nothing we can do to stop them on the build image.

A

This is a requirement for the build pack must not to the build pack author.

A

B

A

The build the build pack, it's not a should for the bill. Peck author: it's a must for the build pack author, if that makes sense, um but but you can put that in there more explicitly. Build packs must not access the application source code or it says the stack build pack is a special case. So no, actually I think it's okay cool it is.

A

It is run before all regular build packs. Do we agree that that's true? It is run against both the build and the run images. I'll agree, that's true! It is distributed with the stack run or and or build image.

C

Do we run it against both images always or do we use the results of the detected, decide.

D

It may run, I think,.

A

uh How about we say it must um must run before all regular, plex or whatever, um if, if it passes, detection.

B

Should we use the same terminology uh user space build packs instead of regular yep? Thank you perfect.

A

um Must run against both the build and the run image if it passes, detection, etc.

D

And it's it's even more than if it passes detection for that image type right, because you can have a stack back. That only is built right and it would not run against the run. The app image.

A

There's only one detect, though.

D

Right but it, but it can still produce a plan for both the build and the run right.

C

If the extra mixing that's required is like build coal in my package that we wouldn't want to run against the run image.

A

uh If so, in that case, if it oh yeah but passes, detection includes the provisioning, and so that that makes sense cool must okay is distributed. Was check, uh may not create layers.

D

So it could be maybe distributed with the stack. I think we have a section on how these get distributed later on so like just not to enforce that.

B

And a stack can have zero built-in stack packs so.

A

It's gonna be missing off of the run image or build image, or must it be in both.

B

Wait from back on this one, actually, you can't distribute them any other way. So maybe it should not be me.

A

You could distribute.

D

Them in like kpac or something right that doesn't really have the concept of.

B

No because it'd have to be put into the stack before.

A

I agree if, if k-pac injects stack packs, it will inject them in the context of building a new stack image, as opposed to creating a builder uh must be distributed to this type. It now must be in both images, or could it be missing from one of them.

B

Yeah, it could be build only or something like that. I've.

C

Had a static list of provided mixins that all started with build colon.

A

uh This is, this is just the distribution yeah like good sorry,.

C

I think you should be allowed to only have it on the build or run image if the set of things mixings it provides, are all phase specific.

A

Detection happens on build, so it has to be on the build image right. Yeah.

C

But in that case optionally.

D

On the run yeah, I.

C

Have to be on the run image, I mean it's a bit of an edge case.

A

Well, let's say it must be distributed with the stack, build image and may be distributed with the stack run, image.

A

Try not to make arguments just get because it consensus, and then we can write.

D

A

It later or if it seems like I'm supporting a perspective, I'm not.

C

If it seems like I care about each of these details, I would approve it without a lot of these changes but you're asking about each line so that.

A

Makes sense, but definitely again as a reminder, focus focus on things that would cause you not to approve the rfc to go through, um or you know, if you're not at least say that it's non-blocking. If that makes sense, let me call it out, um may not create layers.

B

So good we have a long way to go so.

A

Yeah, how far are we.

B

A

Okay, we'll pick it up um where we, the stackpack interface at the top yeah okay, how about everybody read to the order to line 84 and then thumbs up when you're finished and then I'll briefly describe what I think it says. Maybe this will be.

A

A

A

Everybody read to the thumbs up here, cool. So, um to summarize, this stack packs look exactly like real build packs. The only difference is slash instead of app directory, um we use snapshotting, which is using konico to generate a layer and the build image. The run image.

A

All the changes will be captured in one layer that ends up in the app image and um here's again where we have a problem. Maybe all the one layer that ends up in the build image is maybe not exactly correct. Due to the item, potency change on 74.

B

One for second for the build say during the build base.

A

What's that snapshot that's stored in the layers directory developers.

D

Because now there is no snapshot for the build phase right currently.

A

Because we're not applying build time cache to that layer, yet.

A

In that case, do we need a separate directory.

B

I think we should future proof that, because we know it's going to come.

C

You need it because it's gonna run in parallel.

C

um Another thing is: go to the layers directory.

C

On line 67, I'd like to delete that bullet point because detect is never allowed to write to the app and calling it out feels confusing.

A

It does say about similar to the build pack interface.

A

B

Did I miss the part about the extend phase and how that's described.

D

Did describe it earlier, I don't know if the word extend was used. I was kind of thinking the same thing. Oh yeah. It is.

B

I think this is probably the first appearance of extend.

A

Extend is the phase where it's modifying the run image's root in parallel to modifying the build images root during the build phase.

D

A

Do think it's worth adding.

D

D

B

A

Oh good: let's go back down and keep going. um Okay! Oh sorry, up higher.

D

A

There yeah um the there's a problem here about the layers, still right, where we say on 74 uh all of the capture changes in each phase build or extend will be included in a single layer. One for run run for build is produced as output from the stack pack, but in the build case those those changes are just permeated through to the next to the next phase. Until we add that item potency constraint right, um so all the capture changes in each phase, all the capture changes in the build phase. Sorry god.

C

I feel like the current wording is okay, because in other cases we describe build layers, even though we're not generating tar balls from them.

B

Regardless of whether exported or not is what you're saying right, we call them layers whether they're, exported or not.

D

It's still a layer, but it's not really persistent.

C

File system diff.

A

I mean we're really just talking about changes to the file system, that you're making in a running container that then go away completely later. There's no tarring them up. There's no doing anything to indicate that they're any type of layer.

C

I guess the reason that feels okay to me is because, if a regular build pack makes a build true cache false launch, false layer that is not created any differently than this would be.

A

It's in a layers directory, it's a separate, dedicated directory that we call a layer, has a layer tommle file. Next to it, um you know, I think, in that context, you wouldn't argue that it was the image like could be just be really explicit here. Instead,.

B

Yeah, I think we should just cut any mention of build.

A

Okay, all the capture changes in red face will be included in a single layer. Produces the output side factoring the extend phase right during the extend phase of snapshot will be stored in the run layers directory. um Do we need, even in the case, that we're running these in parallel? If we put it in the layers directory in one image, we need to copy it across anyways. Could we just call that exported layer, something else in the layers directory instead of having two different names for the layers directory?

A

That was something I didn't understand from last time.

D

I was thinking if they run in parallel in a platform, you probably can't have multiple writers right.

A

D

I don't think it makes sense to be different directories and then the exporter would know about both of them.

C

I think, by the time it reaches the exporter, they have to have different names, but it can still be layers from the perspective of the two containers right.

D

Yeah, that's true yeah, it extend doesn't have to know that it's a different directory.

A

So in the export image we want to differentiate the run layer from potentially in the future of the build layer, but is there a reason we need a separate top level, slash, run layers directory.

C

In the export image- yes, yes, because the build container and the export container extend continuing running at the same time and they're each getting a volume and then both of those volumes need to be mounted into export. So they need different.

A

Volumes got it, so it's not right. Okay, can we be more explicit about that which will be um mounted into the run layers directory of the uh export container.

B

uh Let's say again mounted into the.

A

uh Into the run layers directory so delete in the next, oh.

B

A

uh Of the export container emily does that cover your okay good and then a separate sentence afterwards.

A

Any changes, any changes performed by the stack, build pack to the build image will persist through build packs executing on that image, um but not be captured in a layer.

C

Let's just say: non-excluded changes for both of these, or can we just leave that as a caveat later.

A

If there's a caveat here, I think.

A

They're not captured changes. Yes, uh the layer stir may not be used to execute to create arbitrary layers. I'd agree with that does.

D

That need to be layers and run layers now that we're.

A

B

D

Around it gets a little confusing anytime, we mention layers.

A

Run layers isn't a directory, that's accessible to the build pack um so.

B

I think it's just an implementation.

A

Detail of the exporter that we're calling out in the rfc, because it clarifies something that might be confusing to people.

B

I can do this abstract layers or thing.

A

Perfect, a stack can provide snack packs by including them in the build packs directory uh and by providing an order yup to define order of execution yep. We agree with this and we agree with how it's overwritten in the builder phase good.

A

So next next sentence after the blurb, a stack pack will execute if it passes detection. When the stack pack is executed, it's detect and build scripts. It's the same parameters as a regular build pack. I really hear that I'm at read to nixon's right now to save some time and then give me a thumbs.

A

C

C

I have one sorry we're not ready to talk about it yet.

A

Thumbs ups, are we all good cool go ahead? Sorry.

C

uh We say: excluded paths are recovered when the image is exported. Do we mean.

B

B

I mean that was my assumption, but I'll let joe answer that thanks, certainly yeah not when the image is restored.

C

B

During the next during the next restore phase.

A

Before the build phase.

B

Before the next build phase,.

A

Build or extend phase.

C

Or rebase right.

A

Build an extender, both phases within rebase now.

C

Build and extend our both faces.

A

Or extend as a phase.

D

B

A

B

A

B

I mean oh okay,.

D

I was like okay.

C

It hurts my brain.

A

Gotta keep pushing through it uh exported exported for build time, build a given path, is excluded at user space, build particle time and recover the next time. The build image is extended, with build pack so exported for build time. Builders, you can chop off some layers in the build image and mark these as hey these, don't end up being seen by the build packs and that chunk can get restored next time. The stack pack runs.

A

Does that seem right to everybody and then same thing for the run image chop it off doesn't end up in the app image, but it can be restored during the next extend phase not seen by the build packs. Good and everybody's interpretation of that is correct and then rebase run is the same thing as build time run.

D

And the reason we need rebase run is because it's kind of redoing extend and you need to have that updated cache or something like the var kind of string. Okay,.

B

What it's worth just as feedback like this little area here is super confusing for me, and I don't know if there's anything that we could do to basically make it better, but not that I would not approve.

A

If that matters javier, can you propose um on this after we commit it? Can you propose clarifications now that you understand what it means um and since I think you have this, you have a sense for how you're confused or what you think is confusing about it. If that makes sense, can you propose that as a change awesome, um for example, uh this sorry, uh this last part here with our cash? As an example says we might want to market cash to have it restored during the build time during build time and rebates?

A

Does that mean? Should it be export, if you want to exclude it from the final app image? Is that export time right during the export phase, really is what you mean there to clarify because build time suggests during the build phase, but you're not talking about excluding it from the build packs in the sun in the first fragment of the sentence.

B

uh I'm sorry, I'm not following what you're saying it's this part, that is.

A

Yeah because I think, if you're saying that var cash is going to be excluded from the app image that doesn't have to do with during the build phase, excluding it from the build packs being able to see it so saying during build time, suggest the build phase which might confuse somebody who's reading. It.

B

And you're saying it should be export.

A

It should be just, I would say, have it restored during the export phase um period. No, no and rebase, because it exports doesn't happen based too cool. Moving on to make sense.

C

A

C

It's so much more confusing may want to mark it as cash to have it not restored to have it cached right. That's the opposite of.

B

Restored does that seem right, I'm like.

C

But it's not ex.

B

Export would you export to cash? Okay, maybe not.

A

To have it restored during the export phase right.

C

So that that phrase doesn't make any sense to me.

A

Sorry we're not the export phase, it was supposed to be the um extend phase. That's I was.

D

I was, I was waiting for this result because I was super confused.

A

Restored before the extent phase.

D

Is that actually, during the extended phase.

B

Yeah it is but it's okay. It's.

D

B

It depends what you define extend phase as, and I I I I define it- to include everything that the execution.

D

Gets restored by the restorer and then I'm targeting, I think.

C

It needs to be, I think, now, like a rebase operation, with stack packs, how I'm thinking about it now using some language you guys have mentioned, I think now, a rebase has three phases. It has restore, extend and rebase.

C

Right because you need to like take the restore, has to take the things out of the cache and put them in the layers directory extend applies, them runs the stack packs and then does its thing and then rebase exports it. So I think we can call it extend in both of those or we use, restore or extend.

A

So, okay, as is or restored before the extend phase.

D

I think we're good.

C

Okay, oh I was gonna, say before sorry.

D

C

Okay, either way.

B

D

B

It's fine for everyone, emily, okay, moving on whatever.

A

C

Sorry, I'm sorry.

A

Yeah tess terrence points out. We have 10 minutes left, we should. We should get a move on it. um A lot of these are templates down, so I'm hoping we can get quite a bit further out in the first um stackpack may define a set of mixins that provides statically and build pack tommle. Everybody agree on this format.

A

Stackpack has a stacks list. You can currently specify mixins in the stacks list that are required by the stackpack, or is that is that correct. Stackpack may require mixins statically as well from other stack packs that come before it.

D

I don't love the mix match between plural and singular here, but I wish it was one all the way through like mix in like, but I would I won't block.

B

A

Is everybody? Okay? With these two sections again in stacks, there are two lists of mix-ins one's things. You provide one's things, you require all build, packs, stack, packs or not can require mix-ins only stack-packs can provide mix-ins, but you can only use the star in the mix-ins list on the provide side, cool user space, build packs can use the build plan like that to require mexicans from stack packs, all good.

A

These baseball packs may not provide mixins cool.

B

Is it worth moving just a knit like 121 when we talk about providing mixins to just move that up to that section, I actually had it. I had just recently moved it down here. I can just it's kind of cross cuts both yeah. I.

D

Think I removed it twice myself at some point.

B

C

The question is, which action are you describing which file? Are you describing right, yeah.

D

A

Move on uh resolving mix-ins after the typeface lifecycle emerge list of provided mixes from the following sources. Stack run, stack, build pack.

D

Yeah, this is where we have some questions. Probably this is the newest stuff. I think stack and run stack. I feel.

C

Like I don't exist as concepts.

D

Yet really I mean stack, does.

C

But I think everything should be in one stack, tumble file.

C

I don't think we need a second run stack tommle, because stack tunnel already has references to run images. I think it's totally fine for it to have references to run image.

D

Mixins, does that mean you can't have a dynamic sort of target run image for a single builder.

C

C

A

Oh sure I understand this is the file that, when does stack toml when these files get generated.

C

When you create a builder right now, and it contains references to run images, um so I think you could either say that the mix-ins on those don't change and you can end up having them as strings in stack pommel. The other way to do it, which I think I prefer is that right.

C

So we would need to well there's a phase ordering problem here, but you'd want to get the mixins from the run image. But we don't know what the run image is. Yet when we run detect sort of a problem.

A

Can we take the mix in lists as input into those life cycle phases and defer the decision for how we store them because it seems like there's, maybe a decision about? Should there be mix-ins on the should the run mix-ins be allowed to be in the build image statically? I think no, but other people might disagree with me.

A

um Should we just say: can we kind of defer not specify how the mixins or where the mixins come from and say after the detect phase the life cycle will emerge, let's provide a mix for the following sources. uh I think.

C

It's gonna be a problem because the first thing we're gonna want to like we're going to need this to implement it right like we can't it's not something we can put an extra feature. We could punch till later. It's sort of.

D

Cool you could punt the run stack, but not the stack like. I think I think it's okay to default to the stack tunnel if there is one present, but I think you should be able to override it as well, because I you know when you're on a builder, you probably already have that makes sense, but for the run stack. I think that being a flag into the life cycle makes a lot of sense for the platform to be able to determine the run target potentially.

C

It means the platform is going to have to read the config blob of the run image. You can't just pass through a reference right to do, build and then generate a file.

D

Yeah and it doesn't yeah, it's gonna have to generate some file or pass them in, and I guess a really long list somewhere.

C

And that's easy enough for a pack: it starts getting hard for other platforms, but.

A

Other platforms make a helper. You know you have to pass the images you're going to run to the helper. It reads those and passes those to subsequent stages.

A

Just saying can we can we get rid of these file references and just say we figured out the implementation and the spec later right. It's rfc say from the following sources and then the first one, the um build stack image, mix-in list and the second one run stack image mix and list. Are we okay with.

A

A

Okay, we agree that unmatched requires it provides cause the bill to fail right if a stackpack provides mixing is not required. Skype help help me pass detection.

A

Everybody, if you could read up to the caching and restoring section and we'll probably have to call it for a.

A

D

D

C

I feel like there's a distinction in here that doesn't make sense now that you can't dynamically provide mixins anymore, like if a stack build pack provides a mixing that is not required. It may pass detection.

A

Does that make sense, because you could have stack packs that statically say they're going to provide something and then no build pack could require them dynamically in user space.

C

It's a fail detection, then right, no one needs it.

A

No, no! That's! Okay, though yeah.

C

Well, I feel like it's an optional, build pack that opts out of detection. At that point right, you don't want to run that build pack.

A

What, if you're a stack pack- and you say I can provide 37 different kinds of versions of open ssl and then one of the build packs says I'll. Take this one.

C

Oh, that's what you mean we have to someone has to require at least one of them, though, right.

A

I don't know, do they is that a requirement.

C

I don't want to run the stack pack every time for no reason, someone needs to require something.

D

Well, you could have a stack pack that doesn't do anything with mix-ins right. It could just be a stack pack that passes detection. It always runs, or is this.

B

In that case, it doesn't make.

D

B

That case it doesn't provide any either, though right, how about if it if it provides and none are required.

B

I don't know you could have an empty build plan for that build pack and then you just don't run build, but you do run. I don't know. I think that was a weird. I think it's sorry.

A

I think it's at least one has to pass right because there's no reason for it to execute if none of them pass, but if one of them passes it goes through joe. Does that meet your requirement.

D

I think this still gets a little weird like. Let's take an example of like uh lid pq right here and if it could provide for both build and run. But you know, but something only requires it for run. You're still going to get executed. With the word for the build.

A

D

um But it just wouldn't have any build plan entries for you.

A

At least one thing.

C

Next, oh sorry, go ahead soon,.

A

Sorry, maybe I'm wrong, I was just gonna say at least in order. It passes differently for the different phases right, so at least one for each phase, at least one mixin has to pass for each phase in order for that phase to pass and happen is that the understanding.

D

I think that's how I'd want it to work, but it does make buildback author a bit confusing, because if you kind of expect to always run and build like, even though they're only choosing to extend and run like, could you depend on something that you expected to do and build? That's not there. I guess not, but it is more confusing than normal, build packs with the double phase here.

A

I agree: do we want to change that model? I think this is the conclusion I would draw from what we've talked about so.

B

Far, I think it's confusing, but I don't know if there's a better way to do it if we want to have both the build and run stuff and plus the fact that uh you can provide like an asterisk right for either of them.

B

I think it's just a matter of the constraints of the problem, at least when jesse, and I were looking at that one time.

A

If you do an asterisk, that means in order to pass something for each of the phases there has to be at least one mix, and that would get installed by that build pack for that in that phase for that phase to pass right, so I agree it's confusing, but it does work or like it, it's a consistent model for there. So how about uh joe? If you want to touch this up to me, do you understand yeah.

B

A

B

Gonna split this out into cases like more than more than mixins are provided and none are required.

B

Mixins are not provided the pass and then mix-ins are require provided, but not all are required and we're saying maypass.

D

Somewhere yeah.

B

These are may pass, but yeah uh you've already passed.

D

At this point right or well, no, never mind.

A

You could fail with this. That's why it's a may pass right. um This is per phase all these things, the three three things are per phase right. Sorry,.

C

If mixins are not provided.

C

It I feel like all of these are may pass right, like I don't, but it's not going to, because you could always provide something else right provide and require something else.

C

It's just about whether it alone is sufficient for a pass.

A

Well, if, if a number of mixins are provided and none of them are required by anybody, it definitely fails in all cases right.

C

What, if you're, providing something else too or is that not, I don't think.

B

We have to say that passes.

A

Oh, I see because stack packs can require regular, build plan entries.

B

Oh yeah like what, if you provide ca, cert and you provide some mix-in for installing them.

C

Yeah, I feel like if.

A

Or other things, sorry.

C

It's actually kind of complicated.

A

Okay, but I think there's just there's still a consistent model here, it's like at least something has to be provided for it to execute. For that phase, right, nixon or not. um I think we agree on the underlying thing, so we are five minutes over and I'm late to think. um How about folks here want to stay and touch this up to meet that requirement. They can and then we'll pick back up on line 150 next time we can schedule either something.

A

Do we want to schedule something out of band of working groups or do we want to use the next working group for this.

B

I'm happy to do both I feel like. We have a ways to.

A

Go in this dock.

B

A

Who wants to own scheduling something out of band to go through stack, packs, okay, awesome so um get this touched up schedule something out of band, we'll try to get it and then maybe we target one of the working group meetings next week to present and say hey. We are ready for a vote on this. Please vote soon.

A

uh If we can, how far do we get? Do we get at least halfway.

B

I think we're more than halfway to your point. It's like there's a lot of these. The examples are really long, yeah and then the this stuff is kind of boilerplate nice. Okay, awesome, I'm gonna move my section: okay, I'll. Try to I'm gonna, try and uh commit up to here I'll reword this and commit up to here.

A

Awesome um again, I apologize for being uh very forceful with the uh changes I just, um I think, we're all all in consensus that we want to get cats.

C

Need to be heard.

A

Sounds good thanks everybody! I really like.

A