Propose the merge of static, tiny and base stacks and builders #313
Conversation
text/0000-core-builder.md
Outdated
| None. | ||
|
|
||
| ## Unresolved Questions and Bikeshedding | ||
|
|
There was a problem hiding this comment.
Q: What do we do about stack/target & builder metadata?
I think it would be nice if the proposal described the new metadata to use for the stack/target & builder. Or is the plan to continue on using the existing metadata? I don't have a strong opinion, but I think we should specify what that will be so it's clear.
There was a problem hiding this comment.
Mmh, I didn't even think about this. We are internally already using the new metadata. The switch to Noble might be a good opportunity to do it, but it feels like an orthogonal concern. I could even see this as leaving it as an implementation detail rather than specifying it in this RFC. WDYT?
There was a problem hiding this comment.
Minimally, I think the RFC should propose the builder & stack ids to use. The other builder & stack metadata is not as important.
I think we should start adding target metadata, if we're not doing that already. My understanding is that it can live side-by-side with stack metadata. So we should probably specify in the RFC what target metadata to set, see https://github.com/buildpacks/rfcs/blob/main/text/0096-remove-stacks-mixins.md#base-image-metadata.
I'd also like to see included the specific current image references and the future image reference.
I think this will help with implementation, but I think it'll also just make it more clear how we are consolidating things. So maybe have it in a before/after style?
There was a problem hiding this comment.
Minimally, I think the RFC should propose the builder & stack ids to use. The other builder & stack metadata is not as important.
Actually, we might even want to avoid stack id and stack metadata in general and switch over to using the new metadata. Are there many things to consider other that the few explicit references to the tiny stack id? Might be worth tackling as part of this.
There was a problem hiding this comment.
I'd also like to see included the specific current image references and the future image reference.
I think this will help with implementation, but I think it'll also just make it more clear how we are consolidating things. So maybe have it in a before/after style?
There was a problem hiding this comment.
Actually, we might even want to avoid stack id and stack metadata in general and switch over to using the new metadata. Are there many things to consider other that the few explicit references to the tiny stack id?
I don't have strong feelings on this either way. On the one hand, it would be nice to not need to support stacks into the full cycle of noble. On the other, the level of effort to support it is pretty small. It's just a little additional metadata.
Given that we have support for Jammy through April of 2027, that seems like plenty of time for users to transition, if we do want to not include stack metadata in Noble.
| This RFC proposes to create a new stack repository that will create a single `build` image and a number of `run` images based on the Ubuntu distribution and replace the existing `static`, `tiny` and `base` stacks. | ||
| This RFC further proposes to create a new builder repository that will create a single builder using the build image as a base layer and the `base` run image as the default `run` image. | ||
|
|
||
| Users will be able to use the new builder to build and run their applications using any of the language family buildpacks included. Instead of requireing a decision for an optimised builder, they can "just" start and later decide on an optimised `run` image. |
There was a problem hiding this comment.
I agree with that, it's confusing to choose which builder to use. But I think it would be better if the image starts by default being optimized and in case the user needs more packages into the run image (a bigger run stack image) then he/she could choose a different run image.
There was a problem hiding this comment.
I think this is a trade-off to consider (as usual) and I would be inclined to prioritize "works out of the box" over "provides minimal dependencies".
Extensions could be a way to remove the need to choose one over the other. However, they introduce other trade-offs. For one, with the recent news on Kaniko (see here and here) I'd say the future of at least the implementation of Extensions is unclear. Independent of that, I think an implementation for choosing the best run image based on language choice using Extensions can quickly become unwieldy - as far as I remember this would require Extension(s) and special Buildpack(s) to work in collaboration with each other via the Build Plan.
It is likely possible, but I am not sure it is worth the effort.
There was a problem hiding this comment.
I think this is a trade-off to consider (as usual) and I would be inclined to prioritize "works out of the box" over "provides minimal dependencies".
+1 - I think it needs to just work out of the box. If it's not the smallest possible image, that's OK. We can then provide other runtime images that allow you to make smaller app images.
I think a nice side effect of this approach is that it socializes and makes commonplace the usage of a runtime image not provided by the builder. This could even allow a user to take our runtime image and add or remove stuff in their own custom runtime image. You could do this before, but it's making it more accessible / "normal" if we're suggesting folks do it.
Co-authored-by: Daniel Mikusa <[email protected]>
Co-authored-by: Daniel Mikusa <[email protected]>
Co-authored-by: Daniel Mikusa <[email protected]>
Co-authored-by: Daniel Mikusa <[email protected]>
Co-authored-by: Daniel Mikusa <[email protected]>
Co-authored-by: Daniel Mikusa <[email protected]>
Co-authored-by: Daniel Mikusa <[email protected]>
Preview