Cloud Native Buildpacks Platform Sync, 19 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Platform Sync: 2020-08-19

Description

* KubeCon updates
* Status Updates
* Release Planning
* pack release candidates
* Docs milestones for pack releases
* Pack plugin RFC

A

A

Okay, as a reminder, there is a document associated with this. If you don't mind adding your name to the attendee list,.

A

I will share the document on the chat as.

A

A

A

All righty see I put a couple things in the agenda. We could start running through those uh feel free to add more things to the agenda. If uh you want something or you think there there's something that we should discuss, um the first thing is uh kubecon updates.

A

uh So I don't know we'll probably uh hash this out in the working group meeting, but I wanted to see if anybody had any updates or cool stuff that they saw at uh kubecon.

A

I know jesse, you were there uh travis. Did you hop in as well.

B

I'm hopping in today, after this meeting so yeah.

A

B

Pretty quiet so far from the booth's perspective.

A

Yeah the booth's been quiet. uh One of the things I saw was uh slack, especially when ben and tr uh ben and terence gave their presentation. There were a lot of activity in the slack associated to that, so that was that was pretty cool to see.

B

Yeah look like the talk went well, they had a bunch of questions towards the end, so that looks good.

A

Except for the video quality, apparently.

B

C

A

Yeah, but it wasn't just their talk like I, I attended a couple talks and just the overall video quality uh was subpar that made any term demos like very hard to comprehend.

C

This was the case for the cloud foundry summit recently as well. um Any screens that went up were not not happening.

A

Hopefully learnings for the next one.

A

Cool, I did post uh something I don't know exactly if it'll be related to platform um or honestly, like uh I think the there was a question. I brought up in governance about uh what was it: the build packs registry and the potential of another sub team, which would be like the distribution sub team that takes ownership of that. But there was a star gs, which is basically tar gonzip with a seekable tar concept, format uh which was really cool. It's like lazy loading images, and I think that would be like from a performance aspect.

A

I think that would be awesome to at least investigate to see whether or not that value would be there, especially for for things where we only use a small bit of you know run time dependencies uh for like the build process. We don't really care to download all the build packs in a builder. If we could just uh run like download the detect script right or the detect binary, then we don't have to download everything else, uh anyways that that was something that I'll probably investigate in the future.

A

But I I added to our slack channel as well.

A

Cool anything else on that one.

A

You know what I just recall: we didn't really go through a status update and release planning.

A

I could give mine on behalf of the uh vmware side, for the pack release we did have a pack release go out, uh uh haven't seen any issues reported yet so crossing our fingers, so that was just yesterday.

A

We are updating a lot of documentation uh in regards to that new release and making sure that some of the call outs or changes are are properly documented.

A

um That's it from for us or for me at least any other updates salesforce.

B

Side, I think joe's pushing forward on the stack back stuff, that's kind of the most of the activity. I think right now, um travis, if you have anything to add, but it's kind of kind of where his focus is.

C

B

Yeah, that's it.

B

I was gonna say nothing to add just uh the uh buildback register stuff, making good progress with that as well. I could be all updated, though,.

A

Yeah on that part, the build pack registry, I want to make sure I'm accurate in saying that the current repo that we just published is like a production, ready, repo and not meant for testing. Is that accurate.

B

The one with the pr that you're currently reviewing you and david. Yes, uh I wouldn't point anybody to it yet until we've tested a few times just with integrating it to the new repo, because I've been testing it on my own repo. Prior to this, uh my my thought was once it's reviewed and as far as we know, everything looks good.

B

Then, let's, let's start, you know, kicking the tires and pointing our config file to use it and see how things go and just iron out any last minute wrinkles before we do like a pr campaign to introduce it to the broader world.

B

Cool, oh yeah, we'll I'll continue to collaborate on that and keep you informed of kind of where things are going.

B

I think in the I think joe had some ideas or thoughts on blog posts, or you know, twitter, all the uh all the social medias to get the word out once we're ready to start having people use it. I know internally here at heroku we have, I believe, the java build pack and the node bill pack, authors on our ends, who are going to try and have them become early adopters. So we should have some pretty quick feedback on that as well.

B

A

That's good to hear.

A

Any other status updates.

A

All right, moving on to release planning, I think I kind of spoke to this already the release went out so we're good there. We don't have anything slated for uh six weeks, unpack signed uh one. A notable mention, maybe is uh the windows related work, we're not really promoting that either. Just quite yet, as emily made mention, there are still some issues on the life cycle that need to be addressed before we really want to.

A

You know, I guess, put a lot of fanfare behind it, um so that's something that for now it's still experimental people could play with it. There's a known issue um mentioned in the release, notes and then uh hopefully, by the you know in the next six weeks, we'll have everything else addressed and be able to really put some some fanfare behind it.

C

I think six weeks might be an optimistically long period of time. I understand that we're intending to to have at least a little fanfare around spring one, although it may not talk too, uh and you can do this immediately- it will at least be some uh some more eyes on it, which I think is just a couple of weeks.

A

Yeah, I was to say, when is spring one happening.

C

That is a good question. I get this information second hand from folks working on the windows side, so uh it is just a couple of weeks out. That's september, 2nd and 3rd. Okay,.

A

Yeah, I know that they have a talk where they're gonna tell right. Yeah windows support, yeah, okay, interesting that would be uh well. I guess we'll see how that goes, will probably require some coordination.

C

It's not unheard of for conferences to announce big features that aren't quite ready for prime time. So I have no huge concerns about the expectation management.

B

A

All right anything else on release planning.

A

Okay, moving on so pac release and release candidates uh bouncing ideas around, I think uh one of the the big pain points of the life cycle and the latest release of pac was that essentially we needed a patch of the life cycle and we didn't really have anything any way to test the life cycle while pac was still being you know developed.

A

So it's like a chicken and egg problem, so maybe not to solve that directly, but one of the things that we've thought about- and I think this isn't the first time we've brought this up- is the possibility of producing release candidates.

A

Now that we have a lot of automation in place, I think that should be a lot more feasible where once we go into at least unpack, we have a feature complete area of a week. At that point, we can have a release candidate.

A

I know some of the other contributors to the life cycle have been talking about potentially trying to add that there as well having like a week where they go, they provide an rc that then pack could start integrating with and testing in that way, uh maybe alleviate some of the neces unnecessary patches afterwards.

A

So keep an ear for that. um If there's no pushback on that, uh I think pack could start doing that immediately, essentially on our next release.

A

Cool all right uh next thing, I feel, like I'm hogging the floor over here, but uh docs so docs milestones, so in our last sink we talked about uh moving from backlog over using milestones for pack. I think the docks have needed a little bit more. uh You know love, I guess, and in providing new pack releases uh we also typically want to update the docs associated to it.

A

So one of the things I've started personally doing um is creating milestones that are then associated to pack releases, so at least that way we could assume you know aggregate all the changes necessary for any given pack release, and then I've started to use uh mustangs as well for things like kubecon. So, like any feedback that comes out of cubecon, um we could aggregate those issues so that we could put a little bit more focus on those as well. So this is all in lieu of the backlog.

B

Is that something that could be automated, potentially at least pulling from milestone, information and coalescing it into some sort of documentary.

A

Yeah, I think uh david mentioned something similar like I think he from his perspective. I don't know if this is exactly what you're speaking to, but he wanted still like a single view, right of all the different ongoing milestones, so that you could go to one area and then just be able to click on on all the different uh sections. I guess or areas where you you to look at. Is that similar to what you're thinking of.

B

I I have a to be honest, a disconnect with how the docs and all that are managed, but I was just wondering in like my head, if, like, if docs first off, are they like manually written? Are they auto generated and if so like, is there an opportunity, maybe to auto, generate new documentation around milestone, details like through github actions or anything like that.

A

I see uh we, we have certain things that are automated. Like recently, we added godox to or sorry I shouldn't say that we're adding godox but that's slightly different.

A

We've we've enabled a function of cobra that generates markdown files for all the pac commands, and so that documentation is auto-generated in that regard and then published onto our website. um So there is that at least right. There are other parts that are a little bit more manual, and these are things like tutorials right having to update tutorials as build pack or platform. Api changes occur, and I don't know that there's a real way to automate that, but I'm sure we can improve it long term.

B

A

All right, someone added something packed plug-in rfc.

C

Yeah, I felt bad you were talking, for they were all your your queries, all your points, um so the concept of of plug-ins in our in our binaries has come up a couple of times, um most recently joe's rfc around experimental features. um I think previously zander raised a similar rfc about the kind of experimental flag in impact which has been implemented and plug-ins have been sort of promoted as a as an alternative or um also just a complimentary system. It wouldn't even need to just be around experimental features.

C

It could just be tangential stuff that we actually don't want in the core cnb product, but uh certain use cases uh fit it pretty well um and yeah. So I've been, I personally, I've been doing a bunch of stuff around refactoring our acceptance tests to try and make them a little more inviting to folks and on the horizon. As I come towards the end of that period.

C

I'm I'm thinking is this my next big thing, and I guess I'm trying to get a feel for whether somebody else uh has that feeling um whether somebody else has already kind of started investigating this. um If there's room for collaboration I'd be happy to do that. If not, then um I guess the other question is this is this is not something that has featured in any of our road maps?

C

So it's a little bit kind of uh out there, potentially and and not being discussed at a broader level, and the rfc would be an opportunity to do that, but maybe there's a pre-rfc phase of like do. We think this is cool and we're not going to do it or do we think? Actually, this is worth pursuing.

B

Yeah I'd be curious. Has there been any customer community asks around this topic.

C

um As far as I've seen, it has just been the conversations related to our rfcs, so from vmware and from uh from salesforce.

B

A

There is, there is one related thing, because I mean when we say plug-in right like the idea sounds great, but this would be typically like an interface to a very specific set of functionality.

A

Right, and I think that's the the part where I'm I'm missing the use cases for where this plug-in, what that interface functionality actually is right. But if I were to associate it with anything that I've seen before there is an issue around providing a additional backend support right.

A

So right now we interface with the docker damen and with registries and that's kind of ultimately, the only way, but some of the requests that have come in are have to do with what is it podman as one of them right and then that would eliminate dr daemons and we can't really use their docker socket support because their docker socket support is broken right, so being able to create a plug-in in which we actually interface directly with a back-end right. A container back-end would be very beneficial for mac.

A

I've explored the idea of doing kind of like an alternative to docker for mac, where, instead, we would have our own container d and linux kit running and we would start up our own and like manage a lot of it internally, so that it would be a lot more like smaller and more performant in certain fashions, and that's where something like you know, star gz could come in um where the container uh yeah the container snapshotter and all that stuff would run a lot faster and there's one product, uh vmware fusion.

A

um I think it's still like alpha or something like that or beta, but they have a vctl which is allows you to do docker images and kubernetes management locally, and they also do not have a docker socket uh support right so being able to enable that back. End would also be beneficial.

C

So broadly, a kind of a container management infrastructure or repo management infrastructure would be would be one of the things um I could see room for that being like additional commands, potentially as well um so like. I think we don't have an inspect image right now. um So if we, if, if people wanted to do inspections in different ways or something like that, um different options, potentially like different um blocks of data into our inspections, uh could be entry points as well.

C

um I guess in a similar way, like wouldn't it be nice uh when we were looking sorry to exclude a few folks, we had an internal demonstration on a modified version of dive uh that allowed us to extract uh specific um cmb image information um and, while that isn't necessarily a particularly good use case for it, um wouldn't it be nice if dive had this uh this plug-in interface, so we could just publish a plug-in and say we know more about these images, so we're going to offer these options instead of the the default stuff that you're going to uh list so that so I can, I can see room for for that, possibly.

A

Yeah, I think the way that I would picture this, though, is maybe creating rfcs not so much for a holistic plug-in system, but very small subsections of plug-in functionality that we want to provide, and then I think eventually we would maybe circle back around to a central unified system, but I would hate to provide so much of an abstract idea that it doesn't become. You know something that we could actually implement in a reasonable time frame.

A

So I'd be looking forward to an rfc that rfc does not exist right.

C

No, no, this is the this. Is the pre-rfc chat like do we want it.

A

Yeah, I think it'd be awesome that, but that would be my my take on. That is maybe start it small instead of too abstract.

C

A

Anything else on that.

A

All right, nothing else on the agenda. I think we're free to go all right. Thank you.

A