Cloud Native Buildpacks Implementation Sync, 27 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Implementation Sync: 2021-05-27

Description

Meeting notes: https://bit.ly/38pal2Z

A

Thanks for that, all right, let's see standing items, status, updates.

B

Just before this, do we want to that anyone will subscribe today.

A

Oh yes, great I'll, try.

B

A

While we run it, there's only three of us.

B

Great. Thank you.

A

Do you want to kick us off with what's what's going on with you status, update.

B

Sure I can, I can start so. I'm working on the issue to stop writing um the layer shop files.

B

um I just realized yesterday, as we just chat on slack, that there are some tests that are passing or though I mean the current, like configuration they're supposed to fail. So I'm just going over all of the tests, and I hope that by the end of today or anyway, sometime soon I'll I'll create a pr for this thanks yeah.

A

uh You haven't done anything this this week with life cycle. I don't think, but I do hope to have more time in the next like month or two, um I'm going to divert more of my time to kind of getting stack packs pushed through. So I have no uh yeah. I don't think I have any current updates. I think I've got a pr or two outstanding for review.

A

uh One has comments from natalie, so when she gets back, she can kind of take a look at that and see if I uh resolve those to her liking, um yeah and then otherwise, I guess we'll be ready to cut a release once these last few sort of issues get taken care of.

A

uh Anthony you get any updates for us.

B

I'm sorry no updates for.

B

C

I don't really have anything, nothing.

A

New, oh uh daniel, just joined as well daniel. Do you have any.

B

A

Updates before we move on to the next standing item, uh I'm not really.

B

A

uh The next thing is: release planning. Natalie normally. Does these, I think we're just sort of where we were before. We've got an upcoming like milestone that we're trying to hit anyway, I think all the items have been assigned or and are either in review or in flight. So I don't think, there's really anything else to uh to add there.

A

I know there was a new new contributor picking up one of the ones around registry authentication and authorization like making sure there's enough uh permissions to do the things that we need to do up front in analyzer. So uh I think they tagged it was it in github or slack or both. So there may be if you've got any guidance for for that contributor. It'd be great to uh give them any uh any hints to how you would expect it to be done. uh Yeah.

B

Juan is on our team, and I talked to him, and I told him you can reach out to me or in our slack or maybe tomorrow have some time to pair with them on this excellent awesome.

A

I don't think I realized they were on the.

B

A

All right, I guess let me share my screen for the.

A

uh Each discussion.

B

You shared both of your screens or just a huge screen. I don't know.

A

But I always I swear it told me. I was just gonna do like one, but let's see okay, there we go. That looks great all.

B

Right uh anything.

A

Here that needs discussion. It looks like this was open 21 days ago, but just eight days ago, natalie added the needs discussion to this.

B

I think that we said last week that we'll wait for her okay. I.

A

Wasn't here last week, so that makes.

B

Sense and the other items relates to phase two and three and me okay. We said we will wait, but I'm not sure no.

A

It sounds good. It sounds good to uh to wait on these things until uh until nato is here. So I think that makes sense. Yeah we're still finishing phase one. So we can just wait on these phase two items until we're closer completion.

A

uh It may be a similar story with rfcs, but let me reshare.

B

The again all right.

A

These are the rfcs that have implementation tagged on them. uh This one could be interesting to talk about here.

B

A

Make build layers read only for subsequent build packs, this one, let's open up sam. This is really emily. You talked about this needing an rfc um like the actual change to the spec. I.

B

A

Said would probably need to come out of this. Is that right, because we don't.

B

A

We say that they shouldn't do this, but we you said there was something that maybe has to change in the platform spec or something.

C

Right yeah sam had originally suggested that, since we already say that this is true in the spec that we could do this without an rfc, we would just be enforcing the spec. But I think if you look at the um suggested implementation of how we would actually enforce that these are read-only layers. It involves sort of turning the layer directory into a layer tar after each build pack, runs so kind of similar to how we're making pack player tars in the builder phase and then just exporting them in the exporter phase.

C

So I think this changes the contract between builder and exporter in a way that isn't just we can't just say we're going to enforce. What's in the spec, because now the exporter isn't reading these uh layered directories anymore, it should be taking the tars that were outputted by the builder.

A

Do you think there's any way that we uh is there a strategy we could do to implement this and not break spec today, in your mind, is there.

B

Like, instead of outputting,.

A

Tars is there like another way to block access to that like if we moved stuff uh or something and then moved it? I don't know or is it not worth it.

C

um I think, without changing our uh user permissions, because right now, all the build packs around us, the same user, there's no way to artificially stop build packs from changing each other's layers. If you wanted to do it without breaking the spec, you'd probably make a tar and then, at the end of builder, like the layers and.

A

Then re-expand.

C

Them but that's like really slow and there's no good reason to do that. Yeah.

A

Okay, gotcha, that makes sense to me: okay,.

A

This one is in fcp the minimum standard for docs ordership. So thanks for that.

B

Everybody commented, I don't.

A

Think, there's anything else to go over there. um This one is marcus block, so I don't know if anyone has any desire to discuss it.

C

No, this is still that related to this plaque on a draft that I'm halfway done and probably will not have up, uh because right after this I'm sort of going on vacation until I'll be back wednesday. So uh uh don't expect any progress on this until wednesday.

A

B

Well, deserved.

C

A

The last rfc was to disambiguate layered metadata. I guess I'm taking ownership of this one. So I'm going to uh sorry I volunteered yeah, it's fine.

B

A

Fine um yeah so I'll I'll work on this. Probably later this week to uh or tomorrow I guess um to try to get what we talked about documented in the rfc and uh yeah and just take over from from sam here, because.

B

It's really turned.

A

Into reorganize the file system, um which is fine, but um it probably needs some more detail instead of just like a snapshot of like what we think might work so that we can actually have a proper discussion about the cons. I know specifically and you're concerned about changing kind of the purpose of the cnb uh directory.

B

A

Sort of implicit contract that may already exist or something.

C

I think the reason I'm worried about it is because I think we would like um we'd like someone to be able to upgrade the platform api without invalidating all old, build packs right, but the way we're packaging old, build packs. The build package itself has like cnb, build packs in the layer tar. So if the platform then mounted a volume at cmb, there wouldn't be any buildbacks in there anymore.

C

When you tried to run um so, I think the ways to handle that is, you could put a lot of work onto the platform you could be like when you create a builder from these build packs. You gotta open up and reorganize everything.

C

I don't know. If I I think that's too much to ask platforms to do um so. I think that means we just.

C

We can't have our perfect directory structure and we should come up with something we can live with like we could go back to cnb workspace and then the for our workspace volume and then the work that needs to be done. There is just the work of convincing stephen to suck it up. Yeah.

A

C

A

C

With a different name for this, that's not cnb. uh I don't think we can use c and b without putting a huge burden on platforms.

A

Yeah, okay, that makes sense you'll have to give this a thought as well like just as far as like upgradeability. That's one thing like to understand like if a platform is expecting to run builders from uh multiple sources, is it going to be a problem that, like you know, is it going to have to know that the bill packs live and build or build packs or cmb build packs, or you know whatever like? I need to give this some thoughts.

C

Yeah, I guess my suggestion would be. Our lives are easier if we don't change the buildback directory.

A

C

B

A

Your purpose there made sense, say your reasoning: cnb slash, buildbacks is already there.

C

I think other things like cmb lifecycle or order the location of order and stack. I think we could change those fine, because those things were get decided at builder creation, which makes them a bit more flexible or if a platform found an older builder, it could still pass whatever flags it needs to make that succeed. So long as you haven't mounted over the locations in the image.

B

It's just built.

A

Is it the platform that has to go like find the bill packs directory? In that case, right like if you found an old builder like you know, uh would you or not buildback sorry uh lifecycle like right now, cmd lifecycle?

A

If tomorrow it's builder lifecycle is it does the platform have to like go look for both locations.

C

A

Or is there like, or is there an invar or something set on the builder like.

C

uh One of the things that we haven't done yet, what was probably a motivation around trying to get the build respect is so that the builder could have a api version. So then the platform could check that and then know what location to find things in in the builder.

A

That's that's what I was yeah. Okay yeah! I knew the builder api spec was uh yeah. Okay. That makes sense. It may be that we can't really change some of these things until we have that version, because I don't, I don't think it would be very fun as a platform implementer to have to guess where life cycle is, since that's like your whole purpose of existing as a platform is to run lifecycle. I don't really want to have to like look for lifecycle um in a container.

C

A

So until we have a version like we can assume, the current version is one or something right, but until we have the the next version like I feel like it would be unwise to probably move like the things that are assumed to be in those directories.

C

Yeah, I think, that's probably right, because platforms need something to make that logic switch on and we need to define what the new locations that can be expected in the builder are.

A

Exactly and it needs to ideally be a label or something or an infrared, something that's unlike the image like manifest, not cracking over the image.

C

I will say in the new um builder spec. I believe I can double check this in the pr that's open for that. We are requiring the builder to set the m vars, so it might actually make things easier for the platform, and we could do something like requiring that the life cycle is on the path like we can introduce builder requirements that make it so that the life cycle doesn't have to do logic. If it's a new enough builder.

A

That's a good point as well. Okay, that makes sense. um I think that's all for the rfcs. I know I said I was going to describe earlier, but I didn't describe it all during that discussion. So sorry for that.

A

There is nothing else on the agenda. Does anyone want to discuss anything? Are we just going to get back the time.

A

All right sounds like we're good thanks.

A