Cloud Native Buildpacks Working Group, 2 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-09-02

Description

* Buildpack Default Process Types: https://github.com/buildpacks/rfcs/pull/110

A

B

Might have a little bit of a small group today due to spring one.

B

I bet as a reminder please sign in on the agenda.

B

B

And add any items you want to chat about today to the agenda as well.

B

Give people two more minutes to show.

B

B

All right, let's uh kick things off, uh so definitely don't see any new faces today. uh Any um release planning updates. We don't have emily here, but javier kevin obtained the platform side.

A

Yeah, there's nothing really immediately in you know being worked on other than the stuff for pack 0140, which isn't until later this month. So not much to say there.

B

Sounds good uh for posterity's sake, I'll do the rfc review, even though we don't have a you know, quite enough people here to to make uh decisions on things. um Give me one. Second, two.

C

Is everyone just at spring one.

B

Yeah yeah we've got a bunch of people, let's bring one.

B

uh That makes sense any updates.

C

Yeah, so this is a new uh pr. I split uh app mixins into two pr's wow, that's a lot of commits, um but uh I take a look at it. I I felt pretty good about how I split it out uh like into the two different concepts of sort of the interface in the project, tamil for specifying mixins and then the implementation of stack packs, and I actually feel a lot more comfortable, adding more detail than I had before for stack packs into the other rfc.

C

So for the most part, the content's the same, but give it a scan- and I put the other the old one into draft and once we're comfortable with this I'll close. That.

B

Supposed to be one parenthesis there or one bracket there, probably yeah yeah, looks good any any questions about at maxim's encourage everybody to dig in deep. I think it's a really important feature and then stack build packs. That's that's the other half that anything about that. One in particular,.

B

uh Nope, just good luck, cool buildpack should be able to provide the default process for an app. um This is one that natalie opened yesterday. um Should we wait to see if she could make today? Should we wait until she can make it to dig into that? A little bit is that the plan.

A

Yeah, I think she just.

C

Go ahead, sorry, I was going to say.

A

She just asked me to relay that, since this is fairly fresh, she just wanted to kind of ask that people take a look at it. If we want to have conversation, I'm sure this is all recorded, so she should be able to catch up if we needed to.

B

um I have some I'm I'm skeptical that the process type selection should come from the build pack uh and definitely want to chat about that. um So when I'm out until next wednesday, um so I may hold you up a little bit there. Sorry.

C

Do you want to talk about that today? Should we put that on.

A

Yeah, I think we should talk about it. I have some insight as to why we're wanting this change so it'd be nice to have ping pong. Some ideas.

B

Sounds good, you want to add that to the agenda cool uh relax, mixing contract. This is just waiting on me to resolve we're going with one option and not another option here between the two things. um So it's just black on me uh label rfcs with spec for us today.

C

I think that's an fcp, but I think ben put it in the emmett last week, so I think we still have two days ago yeah, so we we can do it on next next wednesday.

B

Sounds good uh author creates repo issues still some controversy here or something is that.

C

Yeah, I think it's just there's controversy around the onus of who should do the work. um I think people are excited about the work being done uh and then we're waiting for the author to, I think, come back from pto. What's that right.

B

Yeah that sounds right.

B

uh Project descriptor flexibility.

C

uh I think we need to come back with uh ben's ask was come back with concrete example, cool.

B

uh Pack, sub commands.

A

uh I I'd like to know what the status of that is. If there's any hangups there.

B

Any any thoughts.

C

I think it has enough to go on absolute gain. I meant to.

B

I meant to add my approval to this one.

B

B

Get up slow, okay,.

B

Next, one is experimental.

B

Features joe, I think you just want to call vote on this. One right.

C

B

C

Take a look, oh, I think yeah there might have been. I think I asked I had a comment yet yeah there's one. I think there's one that I will address and then.

B

C

B

It next week sounds good uh offline build packages. Dan is this one you wanted to talk about today. Any updates here, uh there's just like three proposals for the last little bit of how we want to actually.

C

C

Layers that are unzipped that we then retar and artifacts that we kind of double archive or double compress and just hoping, I think, ben felt pretty strongly about some of this stuff. So I figured this will need to go through.

B

um Maybe defer more conversation until next week because spring one's over cool and then the rest of drafts, so we are done the review process and next thing on the list is default process type. Let's talk about that.

B

Do you want me to talk about why I'm skeptical first or do you want to somebody want to try to pitch it? I'm.

A

Going to try to sell you first.

C

Yeah, should we just explain what it is. First, that's probably a good idea.

A

What do you think it is steven.

B

I think we're saying we want build packs to be able to express what the default process type should be for an application. So, like you, build an app and it maybe outputs web and worker and something else and maybe generously like uh the you know- application may only really be a worker application or it may only really be a you know whatever right web process, and so would it make sense for a build pack. Maybe one build package last build pack, some build pack to be able to say hey this.

B

This is the process type we should stop by default. Does that seem right.

A

Yeah and if I recall correctly, the last one would win right if there is some contention um yeah, so I think that's pretty much the gist uh the last I understood it, but you know to be fair. I haven't read through this rfc, but maybe we could talk about some of the reasons why that would be a bad idea.

B

So I have things that all kind of different levels for that I'm worried about with introducing um uh build text, selecting the process types. One is at any time where we have a behavior where a build a later build pack, like the order of the build packs, affects the outcome.

B

I I like, I feel like you- should have a strong reason for having that behavior, because it's it's it can be confusing when there's not when the order isn't necessary, it creates extra rules. You have to think about when you're.

B

Creating these configurations, like, I think, a really nice thing we've done compared to like you know, cloud foundry did a multi-pack thing that looked a little bit like you know, cloud into build packs like with different directories, for each build pack and a big problem there we had is the last build pack was very special right, and so one thing I really like we've done with cloud data build packs is all the build packs are generally pretty equal and when there's uh an ordering it's because there's a hard dependency, you need node to run npm right.

B

Something like that. That's that's obvious. To the end user uh or or you know, process types overwrite, each other like this there's I don't. I don't really like that. But, like you know, uh it's it's a thing that has to be resolved right and to me like this is a place where we're introducing an arbitrary selection by a build pack that can drastically change the behavior of the application, depending on orderings that aren't as relevant. That's like a high-level philosophical one, a little more concretely about process types to me.

B

Process types are like highly conventional they're like web or worker right they're, not like my rails, app or your rails app or something like that right. um The so like I feel like when you're running them. You have a lot of like it's. It's highly tied into the platform you're building them on. It feels like it's a little more closely integrated to the user and the platform if that makes sense, but yes we're going to use this. You know you know.

B

Yes, the system builds web applications or, yes, I have a web application and that's the thing I want to run on this image right or a worker application than it does to the build pack author who's, trying to implement some unit of functionality that you know is responsible for building into the image. um Does that make sense.

A

It does I guess that the latter part of of the conversation is kind of what worries me a little bit, because I don't I'm not sure that I completely agree or I think that maybe that attachment of you know these very specific conventions and and how they relate to any specific platform.

A

Maybe I just don't see that on a day-to-day, but from a more practical standpoint, I guess I could speak to where this came from, and it was the idea that we wanted to remove uh the default right of web, so removing that convention that you know and most build packs, are going to likely create a web process type, and so the life cycle at some point was opinionated and said: hey uh that's going to be the default one right, and so we took that away and then it was up to the platforms and in this case we're talking about pac to then say: hey, uh you know you specify what default uh process type it should be, but the problem then becomes that pack during the build process or even before the build process.

A

Sorry doesn't necessarily know what the process types are going to be, that the build packs provide right. So I feel like we have that. Maybe this chicken and egg problem, where we're trying to the pack is trying to kind of imply.

A

This is what the default should be, but we have no idea what it actually can be, and so it's hard for us to rely on conventions, because, although they their conventions, they're not guaranteed right, and I think that that's, where it kind of puts the user uh in a very potential like bad spot, where their application is no longer runnable right. It seems.

B

Like great things are.

A

B

I was just going to say I'm trying.

A

To work out if this is the best of both worlds or the worst of both worlds, if we were to say each of the build packs could contribute its impression.

B

Of what the default process should be, and we could leave it up to the platform to then decide.

A

Like how to interpret each of the build packs.

A

So I think there is no platform when you're just doing a docker run of this image right- and I think maybe that's the use case that I'm looking at to solve, because the default process for a platform that executes an oci image would be drastically different than one that a user executes right. So maybe there are different use cases that we should think about or talk about.

B

Along the lines of what simon is saying, I wonder if we're taking the a technical problem right, it's hard to end up with a correct process type and trying to solve that by putting responsibility on the build pack author, because it's it's convenient to do to achieve that outcome of having a valid image at the end, when really it's not the build pack author that needs to make the decision, I think it's basically what simon's saying I'm just thinking about it, a little more abstractly.

B

um I wonder if uh the having a mechanism for which, at the end of the build the life cycle, can look at the processes that were output and if there's no web process then default to you know something else right like is there a way we can solve this without changing the build pack api without without giving the build pack author a decision to make? Because I did, I didn't hear a need in there.

B

That's like a build pack needs to be able to instruct the image to have this particular process type, because it's something that bill peck author wants to control. I heard like it's hard to solve this technical problem and we want to change the build pack interface.

B

You know because it's we don't want to have to go back into the image at the end and write. You know like have this complicated interaction between the platform and the life cycle. I mean.

C

One of the things from what you said, though, is that isn't one of the goals to remove web at all? That lifecycle knows at all about something like web as a default.

A

Yeah, that was one of the previous conversations where we wanted to remove that. You know that notion or that insight or that opinion from the life cycle.

B

So could could pac default to web unless it can't find web, and then it defaults to the only thing and then, if there's more than one thing and neither are web, then it fails unless you specify dash dash. You know.

A

So I mean we talked about this at length right and there were different proposals brought up and if you like, I'm gonna go with the simplest one for creator right where we pass all the information beforehand.

A

There is no spot for the platform to then interact with that building process, to be able to then generate an image that has a built-in default. So even if we wanted to abstract out that logic for determining the default to the platform like pack, we have no injection point during the creator phase like in the individual phases, we could maybe do something, but for that creator workflow we wouldn't be able to.

B

You could have pack, you know, rewrite the digest at the end, with a different uh like look at the image afterwards and like there's there's there are technical solutions right they're, just not very nice technical solutions.

A

I think, as soon as we say, pat could do this. I feel like we're failing in some degree, because then we have to replicate this or it behaves differently across different platforms and it just becomes a pretty gnarly mass, but.

B

Could you have the behavior of setting a d pre-provided default process type to the default process unless there's only one process and then select that one unless there's no processes and then could you implement that in the life cycle, but then at the beginning pack passes web to the life cycle as that special designated process type? I I I don't like having that logic in the life cycle, but if it's the only solution.

A

That's what we currently have that's what we do right like that and this all works, because we still have that logic in the life cycle. That says, if there's only one, I want to choose that one yeah there's.

C

A spec pr, I think in that natalie open that we put back to giraffe because of this rfc, if I'm not mistaken javier, that is really changing these spec, so life cycle does not need to have that logic. Right.

A

Yeah, I think it's linked in the uh summary for this rfc.

B

I think my my resistance to having that logic in the life cycle may not be as strong as my resistance to changing the direction.

A

B

Exactly it feels like it's not the direction, I thought it would move.

A

I think the people that matter- I I believe, ben and emily both have strong opinions in how this should work. I think they were in favor of this solution only because it's, if I remember correctly it solved some other problems that they would had then better control over. um You know in in uh that meta, build pack scenario.

B

It gets worth waiting until the uh get them here if they have strong opinions on it, because I'm not I'm not like gonna, say like I'm, I'm very happy to be the one outstanding. No and then it goes through anyways. That wouldn't bother me that much if other people feel strongly that we should do it.

C

I I guess in your ideal world steven, I'm just trying to figure it out, because I think you bring up good points. I think there's good points on both sides uh and it probably comes back to what maybe simon was saying just like at.

B

Some point someone.

C

Needs to decide what the default is like like to some degree like if we could have cleaned slate like where would you want that to live, and how would you want that to work right like, and I think that's ultimately like what we're trying to decide for like a 100 api like do you think the responsibility like if I'm the ruby bill pack, language owner at heroku, like uh it's, the impetus on me to tell you that uh web is the default?

C

um Is the impetus on heroku as the platform to say web is default, even if uh there may be build packs that may not specify a web process type? um Do we want?

C

I feel like there was a conversation we had last week about, like these smaller build packs that could just like define process types, um uh and there was the whole like process, type uh plus m bars kind of conversation. That's all the bill pack did. uh I remember talking about that last week, like if that's loyal does like, would it be the one who is that an api we want to provide to buildpak author? uh I think the I think it being the user, especially for the docker example.

C

Javier talks about right, like I think being the user, is probably not if the user knew what they wanted to do like they would just specify it when they ran it right. um So I think it's probably not the user is the person who's deciding what the default is. I mean they could input into the platform to maybe do that when they're building an image or whatever right. um So I think that's always an option, but I think that's probably not the like.

C

I think it's default for a reason right um and so like in your mind, steven like. Where do you feel like that fits, and how do you want? How would you want that to work.

B

um I I feel like.

B

Again, I don't have a terribly strong opinion and this isn't like someone could easily change my mind, because I think there are drawbacks to this too, but I feel like a platform should have a default and the user should be able to easily configure what that default is if that makes sense. So when you use the pax cli cli defaults to you know making images for web.

B

If you want the pax cli to make worker images- and you know to if you, when you're building your app you're going to output a web and a worker process, you want it to do the worker by default. Instead, then the interface I'd like to see there is pac dash dash process dash type worker and that switches the image you build over so that it builds worker.

B

You know default worker images instead, but then, if you build it with, you know, if it just has a worker process type in the end, I think it's reasonable to set that default process type.

B

Similarly like on heroku, if you build a image, you know defaults to web. Unless the user selects something passes, some command line argument right same with kpac and the you know stuff on the vmr side,.

A

So I guess going with that a bit, so if the platform so I mean ultimately, the platform will not know ahead of time what process types would ultimately yield from the build process right so like it has no way of making that determination.

A

So there needs to be either a post process right or some sort of interaction in between like right before export. Essentially, that says, okay give me the process, types that you have and okay out of those. I can apply this logic of. If that's the only one then use that one.

B

So it's like very naively right if we, if we wanted to meet all the requirements and didn't care how technically gross this is right. The platform could inject a binary into the container right that the creator executes to learn about the logic or to be able to run the logic that selects the default process, type of parses and things right like there. There is a there are ways we could solve this technically. If we are, you know willing to make. Is that a billboard.

C

Textual sacrifice is that a platform bill pack process go pack process.

B

C

Just keep going down, is it a stackable pack, backpack processbook.

C

um And that's not a crazy idea. uh The binary is a little scary because it could be anything but a well-defined interface of like how that works is also not like. You can imagine that being part of the builder right, like a platform, builds a builder and maybe that's like maybe you just like piggyback on joe's stack pack or something.

B

There may be other places where the platform needs a hook into the build process right or needs to provide dynamic configuration and build time right very much in the same way a build pack does and like I don't know if we're there, yet I don't know if I'll ever get there, but I'm calling out that this is a we may run into the same. You know scenario in the future, where we need that you know type of functionality.

A

Yeah, I totally agree with that right. I think it'd be nice to have a solution that solves this in a very robust way. That is then also usable for other aspects that we might fall into.

B

B

I worry about adding too much complexity, though right already got a lot of hooks, and you know uh things like that. um You know complicated interactions or and we're injecting code different places. I'm worried that you know about that too.

C

If you set, can you just set cm being process type like as a built back author?

C

A

Think so, I think anything under cnb can't be said as an nbar. Is that what you're thinking yeah yeah.

B

Back violation, but even if you set it at build time in your build pack or you know like I don't think it would, I don't think the launcher would get it at the right time.

A

There is I mean when we talk about hooks right. The thing that comes to mind is uh s2i. They have a pre-commit and post commit hooks where you could run arbitrary executions, and only if they succeed then does your. uh Does your build actually succeed right, so they use it a lot for testing so injecting tests during before or after something has been compiled.

A

I don't know like that seems again in a very rudimentary way that seems like it would solve the problem if it could, in that step, that post hook or post commit uh be able to inspect the process types and also set additional information.

B

Does pac fail to produce an image if you pass it web and there is no web or does it produce one with whatever process type? Is there if it's only a single one.

A

It depends on the life cycle, so uh yeah the life cycle used to fail, but now I think we made it not fail.

A

A

B

Seems like this is pretty good discussion on it. I don't know if we're gonna get to a conclusion here, especially without a lot of people present, and I definitely don't wanna, I wanna make sure natalie has a chance to be part of the conversation a little more too, uh given that she opened up the pr.

B

um Do we want to any other thoughts.

C

B

A

Like pack platform pack.

B

Yeah too many 20 packs.

C

I don't know I I feel like the ideas you had stevens. Actually I just like. I don't know what that interface looks like, but it's actually a pretty good one of just like a well-defined interface that allows you to actually hook into kind of that build process as a platform. I don't know if we have a besides the kind of defined interfaces of like what you pass into a creator like javier saying, like you, basically don't have a way to inject to kind of solve this. The way you're describing today.

B

I wonder if this is like a stack pack, if, like a stack pack is, is like a a narrow version.

C

So there's too much control on the stack pack that you would actually want to provide to solve this particular use case right, like you, don't need that.

B

But if it's, if a stack pack isn't something that a user brings, if it's something that the platform brings right, then like does it matter how much control it has it's already like it's going to run as root, you know, but you know setting the default process type at the end, like I think, you're, probably right, I I'm not suggesting that stack pack is the right way to solve the problem.

B

I just I'm I'm sensing that, if you step back right, build pack is a way that the build pack author, persona right, somebody distributing build modules, says here's some functionality that can go into an application. A stack pack is kind of the way. Somebody at the platform level right provides functionality that goes into an application with a lot more control right, apt, build pack level, you can pull apt, build pack or you can allow app to build pack type things right.

B

um You know if we're talking about a hook between the platform, and you know the build process that runs the build time we have. That right is. Does that mean that that concept, you know is related to this? I don't know I'm just saying like before we create more, you know specific types of packs right are. We are we really dealing with like a more generic uh interface between those two concepts? Yeah.

C

I I guess uh the concern I had uh with stackpack, because that was definitely the first thought I had uh when you're talking about it is that do I actually need it's just like the principle of, like least privilege or whatever it's like do.

C

I I don't actually need root and like that much stuff, to probably do a lot of things that maybe you're suggesting um so one's default process type, potentially other things that, like once that, especially if it's running right before export like um we were suggesting, potentially I don't know when it would run um necessarily, but it has to be like after the image is kind of built, at least for this particular use. They're not built, but like once enough of the build artifacts are there for me to actually like do stuff. There stack.

B

Packs, don't even have access to layers today in the current implementation are stack, packs, the privileged realization of platform, build packs, or something like that. You know like a privileged pre-hook platform, build pack and then what we're talking about is a unprivileged, a privileged pre-built platform, build pack and we're talking about as an unprivileged post-build platform.

C

I feel like we make joe rewrite his rfc again. He'll, be very sad.

B

Yeah yeah, I'm not I'm not suggesting a change there, but just.

A

Rename it um so I'm still not happy to be honest with the idea that the onus would be on a platform to determine that logic, because, from a user's perspective me building this image. This application, with this builder on my computer versus me right, you know, building it on tecton versus me. Building it in jenkins should not yield a different uh application right or a different image, and I feel, like that's gonna, surprise a lot of people that I don't know that it's worth it.

B

I don't know if a builder a builder is inspect right. It.

A

Doesn't well, we do want inspect as an extension, spec right.

B

We're talking about having an rfc for whether it should be an extension spec. But I don't know if we've decided that.

A

You know uh it's in the spec thing. I think there was a consensus that it wanted to be one. I.

C

Do get the I I just feel like it's used so much throughout various things like we reference it in other rfcs like we talked about builders that it probably should be specked as an extension, even though, as a platform, you don't need to know about it, but.

A

Like every platform uses, it am I mistaken in that statement.

B

Well, for example, kpac can't consume pre-built builders, k-pac can only it can build its own builders using an internal abstraction called the builder, but but you can't input a pre-built builder into kpac and have it you know just use that you have to input, build packs and stack separately.

B

I agree with you I feel like this, should I feel, like creators, kind of the perfect use case like to enable your trusted builders, you kind of want, you know yeah, we could do it with a hook, but I don't know just taking in an input of defaultive. You know present. You know.

A

And life cycle.

B

Doing that doesn't seem, you know out of out of sorts or we could just not. I mean the warning from pack. Is the problem docker run? Do we have to? I mean we're producing valid images? It's just that you don't have the default command right in this case. So like is it is there a pack run, does pack run come back and then choose your uh choose your default? At that point,.

C

But I guess like, how would you choose it.

B

Well, if, if you did a pack, build that's right at the output right, the you know with the warning message: it's kind of like executing a binary without the right flags, it can just dump all the stuff and say well, there is no default.

B

These are the ones that are present kind of the result of pack inspect image or something right.

C

Yeah, I guess I'm against like putting the onus on the user to pick the default.

C

um I think that should be a flag that you you have as a user to set the default, but I don't know if the default should be solely determined only by the user.

B

Well, if you know what processes are going to be there, you can set it right. It's really just the first run situation that we're dealing with right, because if you build an image and you own all the build, you know, you know what processes are going to be there if you're trying to build like a default process. Like I don't know, we kind of kind of went away from really default process in general, and I think that's okay, like building images that have no default, like, I think, that's perfectly valid use case anyway.

B

Stepping back a little bit- I guess I'm I'm very conflicted about, like part of me, feels like process type, should be highly conventional. Almost everything is web right and that that gives me one view of the world right and part of me feels like well we're actually building a kind of generic way of building containers right, not just about web apps web shouldn't be special right.

B

Like there's, you know there is no such thing as highly conventional when you're talking about just building containers in general right um and so those those two philosophies are, I feel, very, very conflicted in between. If that makes sense, because the way process types are used, they are highly conventional, but then we're in a space. You know just building containers where that convention doesn't really exist. If that makes sense.

C

Yeah all right, I share that sentiment.

A

Default to runnable.

C

Runnable throwable throw throwable.

A

Just totally generic runnable one runnable one will always be the default.

B

I think I wonder if tackling the problem for that from that more basic perspective of like why, why do we have process types and what like? What's our real motivation, you know? How do we view them right looking at through that lens first might help figure out what we, what we should do with the ux.

C

I feel like this makes me think of uh how open a lot of stuff in in cmb is like whether it's like mix-ins or stacks, um and probably at the end of the day. I feel like it's great, that it's open, but probably users want guidance like I think, having. Even though we don't like we have that debate of like do. We produce the stack image for uh you know of this, like bionic thing.

C

Do we just need to name and but like if you don't provide, like the the one that we have for bionic right, like it'd, actually be really hard to talk about a lot of these other concepts right? um Maybe we wouldn't even have like that other mix in rfc right, that's like oh for bionic. We mean this for mixins right um and I feel like there's.

C

It's not quite the same for process types, but it's probably similar where, like you, want to leave room for people to define like whatever they want for process types, but I think there's like it's, probably not the 80, but there's like this, like non-true amount of people that are like okay, I just want to I'm building a spring boot app, I'm building whatever. Like just tell me. This is the way to do it and not make me think about well like what is default process type. How do I set this thing like?

C

I think people are coming here to have things be a little standardized to some degree if that makes sense at least that's like kind of my gut feeling on it.

A

Makes sense yeah, I mean being honest when I first came to the project, the term web kind of didn't resonate well, just because to me in my mind, web is like more front. End related focus stuff where back-end stuff is very server, oriented, right and uh so yeah. So anyways.

A

There's that I do wonder this is totally like completely on the side, but if the term itself was just default right and then that by convention be the thing that obviously it kind of naturally flows and it doesn't matter what it is but process type of default is default and I believe that kind of maybe even comes from spring profiles.

A

Isn't this default spring profile default and you could have different profiles.

A

To me that seems a lot more natural than web as the default. To be honest,.

B

Do we have other prior art for process types in particular for them being things besides web? It's like web isn't even really default right, and this is another weird part of the question web is just like on platforms when you set your app to web. When those platforms run your app in a web context, they select the web process type.

B

There's no, there's no default really on heroku or cloud foundry for those things, it's just how it I mean it is a default, but only in the context that they're going to run as web applications right um or yeah.

B

The yeah, I don't know it, problems really darker run at the end. I think.

A

Let's just blame it up on them.

C

Yeah, what I think the the thing that's like the reason there's a lot of value in, but maybe it's not even the default like you're saying it's even it's just like it does special things based on the process. Typing called one at least that's how it works on heroku right like if a process type is web.

C

We actually like open up a port and allow you to connect to it, because that's not a guaranteed thing, you would necessarily want or need for like a worker right um or whatever random process name and so, like we special case web for heroku, uh and I know like the equivalent of like setting this up on like another platform. Potentially that doesn't do. That means that, like, oh, you gotta like deal with the firewall rules like set up your web and so like.

C

Basically taking that away from configuration for users is like a huge net benefit, I guess.

A

That is very interesting that there is more attached to a process, type name than just arbitrary text.

C

Well, because the alternative right is like, if you didn't treat web special and you just treated, treat it, and this goes back to like the port discussion we had from feels like forever ago, uh when we kind of put that aside of just um it means that, like as a user, uh I have to now know how like it's like. The docker run thing like we can always blame docker.

C

I guess, but not really, but it's like when you dock a run for web now, right like uh on heroku, you don't have to do this or a platform who treats web special but, like a doctor, is not treating anything special. It's just like the it'll. Do what you tell to do, and so, like you have to know to do the cork board in yourself.

C

You have to know to do all these things and pass that stuff in, um and I think that's like, potentially where some of the contention is as well, which is maybe a little unrelated to this rfc, but also related to some degree.

B

Yeah, it's definitely it's not a problem that exists in a vacuum, that's of where you're going to use the image right.

B

uh I wonder if project tommel is the right place to put this mention that earlier, because we kind of need it. We've talked about a pre-process for project tunnel, potentially right yeah. Doesn't that.

C

Put the onus back on the user to define what that is.

B

But maybe it's like you know in project humble, maybe maybe it's more like profiles right. It's like, like kind of um you, know, there's a proposal. Controversial proposal about you know the varying project, tamil's top level descriptor name, so it could be.

C

App or function or whatever I've suggested.

B

Right like like imagine that we do that right um if, if it were app and it selected web or if it were a function and it selected function or if it were worker and it selected like like, is there there's some kind of profiles or mandatory choice you have to make in project tamil? That indicates that some of these defaults that we'd set right like web versus worker right is there? Is there something at that level.

A

I don't know that that sounds a lot nicer to me. Just you know hearing it. I think kind of aligns with a lot of my thoughts of where process types should live right, they're, very independent, like isolated processes, and so therefore they should have their own configuration in a.

B

Sense again, um I might be able to wait till we have more more voices to chat about it. um I don't know if we're going to get to conclusion.

B

C

uh What's the feedback, we should write back denali.

B

C

Go watch youtube watch this video.

A

B

I was gonna yeah.

A

uh That would be interesting. I could add it as a comment to this uh pr. It's just like hey, there's a video here, a working group, video of the conversation here, cool.

B

Anything else in the agenda for this week.

B

I don't think so.

B

All right, I can't find the tab, I had it open and so I'm assuming there's not an item there, I'm ignoring thanks.

B