Propose the merge of static, tiny and base stacks and builders #313
Conversation
| ## Implementation | ||
|
|
||
| I would propose to create the new stack and builder as part of moving to Ubuntu Noble Numbat. I.e. | ||
| - we should create a repository `paketo-buildpacks/stack-ubuntu-noble` |
There was a problem hiding this comment.
I think we should consider the implications of https://github.com/buildpacks/rfcs/blob/main/text/0096-remove-stacks-mixins.md with this change.
-
Does it make sense to continue using the word
stackin our repo name. The repo name and image names would be tricky to change later without potentially breaking things. -
While I think removing stacks should be a separate change for us, I think we should at least consider how that might go and if we can easily do it with this set up. The idea being to use this change to position us well for stack removal.
There was a problem hiding this comment.
Mmh, I was used to still using stack as the overarching term for the combination of build and run images... I briefly asked on Slack and Heroku seems to use "Bae Images".
Following that, we would have this:
| - we should create a repository `paketo-buildpacks/stack-ubuntu-noble` | |
| - we should create a repository `paketo-buildpacks/ubuntu-noble-base-images` |
I have no strong opinion on the matter though. Maybe react with 👍 or 👎 to indicate if the above suggestion should be merged.
|
|
||
| ## Unresolved Questions and Bikeshedding | ||
|
|
||
| What about the `full` stack and builders? |
There was a problem hiding this comment.
I feel like we should include full in this proposal. If we don't, that would effectively mean dropping support for buildpacks that only work in the full builder.
Have you looked at the difference between the base build image and the full build image? If it's not too much of a difference, we could conceivably do the same thing and just have another run image for full.
There was a problem hiding this comment.
I haven't looked into this. I'd hesitate to increase the size and attack surface of the builder based on the needs of a few buildpacks. The build image is by far not as critical as the run images, but it still feels like a lot like catering for edge cases and put the weight on standard cases.
We should probably just keep providing a full builder in addition to the one proposed here. WDYT?
There was a problem hiding this comment.
The list of packages in full is quite a lot larger than the list of packages in base.
For me, adding full packages to this new build image is not an option. I guess I will put a note into the RFC to show that if we need a full build image, we need separate build, run and builder images.
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.
| 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.
| ## Summary | ||
|
|
||
| Over the past, the Paketo project has created four different stacks and builders based on the Ubuntu Linux distribution. The difference is in the number of packages included which in turn is based on the requirements of the different buildpacks included. | ||
| 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. |
There was a problem hiding this comment.
I think it would be preferable to have run images based on the engine (e.g. nodejs, java, etc.) This would minimize to the absolute necessary, the packages that are needed for the engine during the runtime. We can also still have the static, tiny and the base for backwards compatibility.
There was a problem hiding this comment.
Indeed, I would consider the static, tiny, and base run images as kind of a means for compatibility. Although base also serves as an enabler for "works out of the box" (see my comment above).
There was a problem hiding this comment.
I think it would be preferable to have run images based on the engine (e.g. nodejs, java, etc.)
I'm OK with that so long as we have an obvious and suitable default, to make things easy for new users.
Co-authored-by: Daniel Mikusa <dan@mikusa.com>
Co-authored-by: Daniel Mikusa <dan@mikusa.com>
Co-authored-by: Daniel Mikusa <dan@mikusa.com>
Co-authored-by: Daniel Mikusa <dan@mikusa.com>
Preview