Cloud Native Buildpacks Implementation Sync, 10 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Implementations Sync: 2020-09-10

Description

* Release Planning
* Image name defaults

A

Hey everybody how's.

B

C

You're good how's it going.

B

B

Good happy thursday.

B

Yeah for sure a week.

C

This still feels pretty long.

C

B

A

uh Are we expecting anyone else we're ready to get started? I know of the people usually come. Natalie is out today.

B

Yeah, we are sad that he'll join, but I don't see him and I'm not next to my computer, because I got an update. It's been running for so long. So sorry about that.

A

Eventually, you gotta give in to this complaining and just update it.

B

I didn't expect it to happen, but yeah whatever.

A

All right, let's get started, then uh is everyone mostly signed in no new faces uh status updates?

A

I can go first because it'll be very short, because I really haven't done much on the life cycle since the last time I talked to you all, because I was uh spring one last week, um I'm also going to be mostly busy with non-direct cnb project work this week, just to give everyone a heads up.

C

I guess I can go next, I'm working with joe on kind of getting a rough implementation of stack, build packs, so moving that along fixing some windows, things here and there and so continue pushing forward on that really. At this point, I think we're going to try to do the build plan, stuff and kind of scope that out and see how that feels after the discussions yesterday.

B

A

Cool um anyone else.

B

uh I've been working with molly on moving the release, um I mean lifecycle, release to github actions. uh It's still in progress- and I hope we'll finish this um this week or the beginning of next.

A

That's a nice segue, I think, directly into release planning, because, thanks to everyone's hard work and our willingness to kick stuff out to future releases, I think we're ready to ship up patch as soon as we uh finish up moving over the release, automation that yeah I was just talking about- so I haven't gotten a lot of um no one's really clamoring for this one, but I think we should ship it as soon as the new automation is.

A

Ready um into future topics, I've copied down this lifecycle topic, so I was assuming this was intended for the implementation meeting rather than the platform meeting, but I didn't necessarily put it here. Does anyone in this meeting want to talk to this.

D

Yeah, I I put it there um and you are correct that it is for implementation. um This came up uh today within our vmware stand up in regards to the pr that is linked there and it talks about how the user and pack have like this kind of you know preconceived notion of assumptions of defaults. That should be there and uh in part of that discussion, I think one of the things that came up to light was the fact that these defaults um there's no like real contract around them.

D

As far as the spec is concerned.

D

So when we send out, uh you know, like a very simplified image name uh like my app, there are a couple things that uh ggcr is doing for us, which is adding the default domain, a library I believe in some cases, and then the latest tag, but I do know that there's other tooling in the ecosystem, like container d and uh some other platforms that do not do this automated defaulting to docker hub specific stuff.

D

So again I just ultimately, I think the question is like one of two ways is: do we want to move away from this default?

D

On the lifecycle side of things as one of the long-term solutions, or do we want to like codify this uh default, behavior that we're inheriting from ggcr in a spec, because I think, when I think about like you, know this uh interface between the platform and the lifecycle.

D

I want to always keep thinking about what, if we used another implementation of the life cycle right- and I feel like this- is a missing piece in this kind of interface for exchange.

A

It's an interesting question. I feel like the reason 2gcr does. It is because docker demon does it right. um So if you're building, if like one of our build targets, is a docker demon.

A

And then you docker pull or push those images. Those defaults are getting applied, so in some ways it makes sense to treat. I think either treat remote images the same way the demon will. So it's consistent or I guess the other option is make people be completely explicit, all the time and always include a registry, but that might throw some docker users off right.

D

Right- and I think that's where the the question comes in of maybe the difference between the life cycle as like an internal component, that platforms talk to and then platforms that then provide a you know nicer experience in a way right. I guess very similar to you know how the docker for mac or the dr daemon would create some sort of assumptions, but container d, which is used underneath it doesn't have those assumptions right um and then to speak to gtcr.

D

I also linked it on there. uh The there is a setting when we do the parse reference, where right now we're using the weak.

D

I forget what the term is but we're using the weak setting, which then creates these defaults, and they do have a strict setting which does not provide these defaults.

D

So I think ggcr enables both you know to be supported, so I don't know speaking to like why they did it. You know, but, uh but there is, that option there as well.

A

So I guess what is the what's the ask like concretely.

D

So I think, to reiterate, the ask is one of two things uh that we'd like to see uh the contract between platform and lifecycle, to explicitly say that these defaults are going to be taken into effect.

A

Or put it in the spec like when you pass a tag or digest reference, the life cycle must interpret it or should interpret these defaults when they're missing, correct.

D

Yes or b remove that right, since it's not there right now, don't do those defaults.

A

That makes sense to me.

A

From a cleanliness perspective, I, like the latter, I don't love these docker hub, specific defaults, but I do wonder if it's you know, for the sake of intellectual consistency, we'll be um abusing our users if we got rid of them, because most people are used to being able to say their docker hub like I'll, say, ekc my run image and expect it to work, and if we force people to put index that docker io in there when they don't have to do that in kubernetes.

A

Even though kubernetes uses container d a lot of times under the hood or in other tools, I feel like it would really confuse people.

D

So within the kate's ecosystem, um given that a lot of these tools don't default, uh do they actually default if you're trying to run an image.

A

Yeah kate's default to index docker io.

C

Yeah, I think defaulting it and documenting. It seems like that yeah. I, like the cleanliness of passing uh full reference all the time, but I feel like that's sort of a yeah. I don't know I stepped too far for folks who are getting used to it and used to kubernetes.

B

D

Yeah, I I really it leaves a bad taste in my mouth just because I dread.

D

You know the fact that it just always defaulting to drug, but uh but I see the the usefulness from my user's perspective, but I think that's why I would ultimately like a very small inclination, is to just rely on the platforms to create that default.

A

We could let pac create the default, but then I think we'll get a bunch of questions about tecton, right, yeah.

D

A

Other other platforms, like I know right now, pack actually does explicitly expand the reference ramp before passing it in I know kpec doesn't, um but the results are the same because, as you said, lifecycle has the defaults built in.

D

Yeah and that's ultimately, what we were trying to resolve here- and this is where we landed on this- you know preconceived notion or assumption that we're both making is that uh ggcr is doing this for us or being used in both places.

A

Is bigger than ggcr like I hate it too, but it's stalker and it's kate's and it's it's bigger than us. I don't know if we can change it just because we don't like it without antagonizing users.

D

Yep, okay, um that sounds good. I guess what are the next steps? um Are we just creating a pr to define the world that that exists right now uh without having to go through the rfc process?.

A

It seems like the kind of thing we could contribute directly to the spec, because it's a description of what exists. So I don't know if we need much people to vote on the fact that we should do it um in advance in an rfc.

D

Cool, maybe we could get the spec uh thing out there and then, if uh core team pushes back, we could go to the rfc.

A

um Do you want to handle creating a issue for that on the spec.

D

um Yeah, I could do that and then I'll see if anybody on the vmware side of things wants to pick it up. Take it on.

B

Cool cool, thank you.

B

A

Seems like that's all we got on the agenda for today. Does anyone else have any late breaking topics they want to discuss.

A

Anything any questions come up with the stack pack work. Jesse. Do you need any help from the rest of us to get that moving.

C

Yeah, I'm still trying to catch up with joe here a bit. I think he's going to kind of describe what he thinks he wants to do with the build plan. I think he was he was running into. I think his current path forward is to kind of pre-pin the stack packs into all the different groups before running it. Instead of sort of treating it like its own step, and then I guess remove those at the end, I think he might have been running some currency things and so I'm sure there'll be some.

C

There may be some questions around uh how to get this done in a uh easy to maintain manner, but we'll we'll see how it's going. It's a bit early, I think, to to call out for help make sense.

A

I want to read, through those updated rc's, um a very practical question sort of about the experimental work on stackpacks. What do we think is the plan for um seems like there's a desire to merge it. Let people use it experimentally, maybe even before we've defined it all in the spec.

A

um But I, when we're doing sort of the api versions.

A

Rfc we kicked out all the experimental parts they're a little controversial. Do we have a what is in your and joe's mind the plan for how and when we would merge or let users access this feature.

C

Yeah, I I don't know what joe's plan is, but I thought the assumption was we're just sort of getting a head start and kind of conforming to the rc's as they change um and if any of the rfcs kind of land, then we would merge that piece of it potentially right.

A

B

Now, there's no mix-in.

C

Stuff in in this current pr, so there's a chance that, like as long as the people are generally kind of happy with the mix and stuff, then maybe stack build packs as a feature without the mix in would be merged in um and and once the once the rfc for that is particularly improved.

C

So I think it's mostly joe kind of trying to understand whether this fits and actually produces what we wanted to do at this point and kind of to get it get a more solid ground on how to how to build this thing out.

A

So there's no desire to merge it before we merge grc's. I.

C

Don't think so because I think the main the main use case for using this is sort of the certificate stuff right now like we don't actually have an internal use for stack, build packs right now and so like our desire to get this through, is mostly just for like the project itself, and so I think, um obviously I know uh ben and others have.

C

You know, wanted the a better solution for the certificate stuff, and so I think I think, if we could get to a point that would solve those issues, then we won't emerge just as soon as everyone's ready.

A

People demand their ca search. That's.

C

A

I do wonder if I'm like worried about right now. We haven't made a lot of other large changes since this work started and worried about selling you guys with a really gnarly emerge conflict. If something larger came up, this could be an opportunity to like, even though we're not going to expose this to users, merge it in behind a feature flag. So no one can use it just to make your lives easier, but maybe we're not at that point yet because it's not.

C

A

C

A

C

Yeah emerging sounds like a huge pain uh just keeping up with it already is already sort of painful, and we haven't really tried to merge from from maine. I don't think, especially when you're messing with concurrency code, potentially yeah yeah, uh maybe I'll bring that up with joe today and see if he wants to. If we want to kind of gate gate all this work behind a feature flag and see where that gets us. Maybe.

A

Cool all right, all right sounds like that's it for today,.

C

See y'all next time.

B

A

B

C

B