From ff8bafd51c3756fb3a5cf695c5b95bfd83590a9c Mon Sep 17 00:00:00 2001 From: Jan von Loewenstein Date: Mon, 16 Dec 2024 11:41:04 +0100 Subject: [PATCH 01/11] Propose the merge of static, tiny and base stacks and builders --- text/0000-core-builder.md | 46 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 text/0000-core-builder.md diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md new file mode 100644 index 00000000..535aae4b --- /dev/null +++ b/text/0000-core-builder.md @@ -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. +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. + +## 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. + +## 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` +- 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 + +None. + +## Unresolved Questions and Bikeshedding + +What about the `full` stack and builders? From 5f690a1fd63bdb85495a2195d101e6b6094f2543 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Wed, 18 Dec 2024 12:26:50 +0100 Subject: [PATCH 02/11] Update text/0000-core-builder.md --- text/0000-core-builder.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 535aae4b..b8457bde 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -39,7 +39,7 @@ I would propose to delete the `paketo-buildpacks/builder-noble-buildpackless-sta ## Prior Art -None. +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 From 8137bff20095c89ee7dd850b5aa8fae9387b2c1a Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 08:48:29 +0100 Subject: [PATCH 03/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index b8457bde..57e2d9da 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -17,6 +17,8 @@ The stacks and builders maintainer team will have less work to do - they will on 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. +Container images have a layer limit and in the past, we have had issues with builders that include a lot of buildpacks because this can quickly cause the builder to hit the layer limit. To prevent this from happening, we will by default squash layers for all composite buildpacks included in the builder. This will be done by using the `--flatten` of `pack builder create`, and it should allow the builder to scale to include all of the Paketo buildpacks. + ## 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. From d32990edacd2456d888ef5f4765266dab9f22881 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 08:52:29 +0100 Subject: [PATCH 04/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 57e2d9da..46059b90 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -44,5 +44,11 @@ I would propose to delete the `paketo-buildpacks/builder-noble-buildpackless-sta 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 +Q: With pack, it is very easy to specify a different run image. Is it similarly easy when not using pack? +A: We know this to work with some platforms. The notable exception is kpack. +For example: + +- Spring: https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image.customization +- Tekton: https://github.com/buildpacks/tekton-integration/tree/main/task/buildpacks/0.4#parameters What about the `full` stack and builders? From b838461b65ac8b5d25aac1d970a7320ab347a5b3 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 08:52:47 +0100 Subject: [PATCH 05/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 46059b90..a2944365 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -48,6 +48,8 @@ Q: With pack, it is very easy to specify a different run image. Is it similarly A: We know this to work with some platforms. The notable exception is kpack. For example: +Q: How does this impact the [language-specific builders RFC](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0055-create-language-family-builders.md)? +A: It does not impact language-specific builders and Paketo buildpacks language families can continue to ship language-specific builders as needed. - Spring: https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image.customization - Tekton: https://github.com/buildpacks/tekton-integration/tree/main/task/buildpacks/0.4#parameters From 18ec1fae68e335ee4b2b3cdb84a65f6d66b083b2 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 10:28:30 +0100 Subject: [PATCH 06/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index a2944365..9890af6d 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -50,7 +50,8 @@ A: We know this to work with some platforms. The notable exception is kpack. For example: Q: How does this impact the [language-specific builders RFC](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0055-create-language-family-builders.md)? A: It does not impact language-specific builders and Paketo buildpacks language families can continue to ship language-specific builders as needed. - +Q: Does this proposal require Paketo buildpacks language families to implement an extension to switch or auto-select runtimes? +A: No. That is out of the scope of this RFC, and will be the topic of a future discussion and possibly future RFC. - Spring: https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image.customization - Tekton: https://github.com/buildpacks/tekton-integration/tree/main/task/buildpacks/0.4#parameters What about the `full` stack and builders? From 7f9a46c45bf5e7940cad8b47a0cb6eda416c0ae1 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 14:19:24 +0100 Subject: [PATCH 07/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 9890af6d..2224e9f5 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -17,6 +17,8 @@ The stacks and builders maintainer team will have less work to do - they will on 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. +The `full` stack will be deprecated, making the present Jammy stack the last iteration of the `full` stack released by the Paketo team. This provides support for the full stack through [April of 2027](https://ubuntu.com/about/release-cycle), which is a sufficiently long deprecation period. Upon approval of this RFC, the Paketo Steering Committee will write a blog post announcing the stack changes and the deprecation of the full stack. The PHP buildpack will then need to be altered so that it can run on the new base stack or it will need to be changed to utilize extensions to install any additional packages that it requires over and above what is in the base image. + Container images have a layer limit and in the past, we have had issues with builders that include a lot of buildpacks because this can quickly cause the builder to hit the layer limit. To prevent this from happening, we will by default squash layers for all composite buildpacks included in the builder. This will be done by using the `--flatten` of `pack builder create`, and it should allow the builder to scale to include all of the Paketo buildpacks. ## Rationale and Alternatives From e2eacaea0912cb6b7d5d88db3a9cd307d986a543 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 14:19:39 +0100 Subject: [PATCH 08/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 2224e9f5..55b4db8c 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -3,7 +3,7 @@ ## 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. +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. The `full` stack will be deprecated immediately, making the Jammy stack the last iteration of it. 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. From 237f192c7704bcd9a442b495cd6fa2b8a1c9bf3a Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 14:24:05 +0100 Subject: [PATCH 09/11] Update text/0000-core-builder.md --- text/0000-core-builder.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 55b4db8c..11d7b774 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -28,7 +28,7 @@ We could leave everything as it is. We would stick to maintaining four stacks re ## 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` +- we should create a repository `paketo-buildpacks/ubuntu-noble-base-images` - 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 From 4fa079b2721543adf65a2b03c664ef505b162391 Mon Sep 17 00:00:00 2001 From: loewenstein-sap Date: Thu, 19 Dec 2024 14:24:54 +0100 Subject: [PATCH 10/11] Update text/0000-core-builder.md Co-authored-by: Daniel Mikusa --- text/0000-core-builder.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 11d7b774..264af23d 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -56,4 +56,5 @@ Q: Does this proposal require Paketo buildpacks language families to implement a A: No. That is out of the scope of this RFC, and will be the topic of a future discussion and possibly future RFC. - Spring: https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image.customization - Tekton: https://github.com/buildpacks/tekton-integration/tree/main/task/buildpacks/0.4#parameters -What about the `full` stack and builders? +Q: What about the `full` stack and builders? +A: This proposal does not include the `full` builder and recommends that it be deprecated. If approved, this RFC will make the Jammy Full stack the last supported iteration of the full stack. There is presently only one buildpack, PHP, which requires the full stack and is thus impacted. This buildpack will be able to continue using the Jammy Full stack through [April 2027](https://ubuntu.com/about/release-cycle) with the goal of converting it to run on the new Noble all-in-one stack before that point. From e42a3a9eb040133f58ada1cfd7403cd8b687f4b0 Mon Sep 17 00:00:00 2001 From: Jan von Loewenstein Date: Thu, 19 Dec 2024 15:00:47 +0100 Subject: [PATCH 11/11] Document new image names --- text/0000-core-builder.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/text/0000-core-builder.md b/text/0000-core-builder.md index 264af23d..910fdab0 100644 --- a/text/0000-core-builder.md +++ b/text/0000-core-builder.md @@ -29,14 +29,23 @@ We could leave everything as it is. We would stick to maintaining four stacks re 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/ubuntu-noble-base-images` -- 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 take the `build` image content from the `paketo-buildpacks/noble-base-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` +- we should take the `run` image content from the `paketo-buildpacks/noble-base-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` +- we should take the `run` image content from the `paketo-buildpacks/noble-tiny-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` 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/ubuntu-noble-base-images` as additional run image +- we should create a repository `paketo-buildpacks/ubuntu-noble-builder` - 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` + - we should use the above images in another `builder-buildpackless.toml` in the same repository to create and publish a buildpackless builder + +The image names will be changed like the following: +paketobuildpacks/build-noble-base -> paketobuildpacks/ubuntu-noble-build +paketobuildpacks/run-noble-base -> paketobuildpacks/ubuntu-noble-run +paketobuildpacks/run-noble-static -> paketobuildpacks/ubuntu-noble-run-static +paketobuildpacks/run-noble-tiny -> paketobuildpacks/ubuntu-noble-run-tiny +paketobuildpacks/builder-noble-base -> paketobuildpacks/ubuntu-noble-builder +paketobuildpacks/builder-noble-buildpackless-base -> paketobuildpacks/ubuntu-noble-builder-buildpackless 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.