Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose the merge of static, tiny and base stacks and builders #313

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open

Propose the merge of static, tiny and base stacks and builders #313

Changes from 2 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
ff8bafd
Propose the merge of static, tiny and base stacks and builders
loewenstein-sap Dec 16, 2024
5f690a1
Update text/0000-core-builder.md
loewenstein-sap Dec 18, 2024
8137bff
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
d32990e
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
b838461
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
18ec1fa
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
7f9a46c
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
e2eacae
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
237f192
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
4fa079b
Update text/0000-core-builder.md
loewenstein-sap Dec 19, 2024
e42a3a9
Document new image names
loewenstein-sap Dec 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions text/0000-core-builder.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Ubuntu Core Builder

## 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.
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Motivation

The Paketo project will be easier to use for users - they can start without being asked to decide on optimisation.
The stacks and builders maintainer team will have less work to do - they will only need to maintain a single stack and builder instead of three.

## Detailed Explanation

We would replace the current `base`, `tiny` and `static` stacks with a single stack that includes all packages required by the buildpacks. Similarly, we would replace the current `base`, `tiny` and `static` builders with a single builder.
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved

## Rationale and Alternatives

We could leave everything as it is. We would stick to maintaining four stacks repositories and eight builder repositories and creating new ones for every LTS we adopt. But that would increase the burden on the maintainers.

## 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`
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
- we should take the `build` image content from the `paketo-buildpacks/noble-base-stack` repository and apply it to `paketo-buildpacks/stack-ubuntu-noble`
- we should take the `run` image content from the `paketo-buildpacks/noble-base-stack` repository and apply it to `paketo-buildpacks/stack-ubuntu-noble`
- we should take the `run` image content from the `paketo-buildpacks/noble-tiny-stack` repository and apply it to `paketo-buildpacks/stack-ubuntu-noble` as additional run image
- we should take the `run` image content from the `paketo-buildpacks/noble-static-stack` repository and apply it to `paketo-buildpacks/stack-ubuntu-noble` as additional run image
- we should create a repository `paketo-buildpacks/builder-ubuntu-noble` and another`paketo-buildpacks/builder-ubuntu-noble-buildpackless`
- we should use the above `build` image as a base layer for the `builder` image
- we should use the above `run` image as the default `run` image for the `builder.toml`
- we should use the above `run-static` and `run-tiny` images as additional `run` images for the `builder.toml`

I would propose to delete the `paketo-buildpacks/noble-base-stack`, `paketo-buildpacks/noble-tiny-stack` and `paketo-buildpacks/noble-static-stack` repositories.
I would propose to delete the `paketo-buildpacks/builder-noble-buildpackless-static`, `paketo-buildpacks/builder-noble-buildpackless-tiny` and `paketo-buildpacks/builder-noble-buildpackless-base` repositories.

## Prior Art

This has been done in https://github.com/paketo-community/ubi-base-stack already. The `stacks` folder and `images.json` should give guidance on how to create multiple run images. Also, this is currently WiP in https://github.com/paketo-buildpacks/noble-base-stack/pull/11.

## Unresolved Questions and Bikeshedding

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

I added https://github.com/paketo-buildpacks/rfcs/pull/313/files#diff-a6cd29e680d46138ca93c24308bc8ac8f126e1d73463d1691e5091c2faf11eadR42-R48

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

https://ubuntu.com/about/release-cycle

loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved
What about the `full` stack and builders?
loewenstein-sap marked this conversation as resolved.
Show resolved Hide resolved