RFC: Introduce Buildpack/ClusterBuildpack Resources #931
Conversation
rfcs/0000-buildpack-resource.md
Outdated
| - group: | ||
| - id: paketo-buildpacks/java | ||
| ``` | ||
| The `paketo-buildpacks/java` buildpack referenced in the Builder order would be sourced from the Buildpack resource within the `my-builder` namespace or the ClusterBuildpack resource that provides the `paketo-buildpacks/java` with the highest version number as defined by semver. If multiple Buildpack resources provide the same selected Buildpack the Builder should reconcile with an error. |
There was a problem hiding this comment.
Could this get you into a state where someone else creates a buildpack or clusterbuildpack providing the same id and version that would inadvertently cause your builder to error out
There was a problem hiding this comment.
If multiple Buildpack resources provide the same selected Buildpack the Builder should reconcile with an error.
Maybe buildpacks should fail to reconcile if a buildpack with the same version/id combo already exists.
There was a problem hiding this comment.
I think this is a risk but, inherent if a builder is letting its versions float without direct references to a buildpack.
There was a problem hiding this comment.
Maybe buildpacks should fail to reconcile if a buildpack with the same version/id combo already exists.
I think that would be difficult to enforce.
Codecov Report
@@ Coverage Diff @@
## main #931 +/- ##
==========================================
+ Coverage 69.42% 69.77% +0.34%
==========================================
Files 119 119
Lines 5370 5574 +204
==========================================
+ Hits 3728 3889 +161
- Misses 1285 1305 +20
- Partials 357 380 +23
Continue to review full report at Codecov.
|
rfcs/0000-buildpack-resource.md
Outdated
|
|
||
|
|
||
| **Prior Art:** | ||
| * [kapp controller](https://carvel.dev/kapp-controller/) models available Package versions as indepdent Package resources. | ||
| * [kapp controller](https://carvel.dev/kapp-controller/) models available Package versions as independent Package resources. | ||
|
|
||
| **Risks:** | ||
| This will require introducing a new api version within kpack. Future kpack releases will need to maintain support for ClusterStore resources until the kpack apis which contain the ClusterStore are removed. |
There was a problem hiding this comment.
Another risk that should be considered is the possible need for a conversion webhook or some mechanism to allow migration from clusterstores to clusterbuildpacks when clusterstores are removed. at minimal documentation needs to be provided to ease the process for users.
There was a problem hiding this comment.
This RFC does not propose the ClusterStore to be removed so, migration of resources is outside the scope of the RFC. I will add this as a risk though.
rfcs/0000-buildpack-resource.md
Outdated
|
|
||
| Some kpack clusters may be operated in an environment where different personas manage available buildpacks from the persona that manages the builder config. This is especially likely in an enterprise environment where only blessed buildpacks are available to developers but, developers can modify their buildpack usage by owning namespace scoped Builders. This can be restricted via RBAC with a distinct Buildpack resource but, would not be possible if Builders directly referenced buildpack images as developers could then use any Buildpack. | ||
|
|
||
| These distinct personas may also exist in non-enterprise settings where buildpacks and builders have independent lifecycles. For example, the kpack build cluster is a multitenant kpack cluster that provides up-to-date dependencies for multiple teams by continually updating new paketo dependencies. The kpack components are built with a kpack specific namespace Builder that utilizes the [Paketo Go Buildpack](https://github.com/paketo-buildpacks/go) alongside a custom buildpack to build libgit2. The kpack namespace scoped Builder continually pulls in new versions of the Paketo Go buildpack. If the buildpack images were configured on the Builder resource the process that updated the Paketo Go Buildpack would also need to update the kpack Custom Builder. This would be unnecessarily complicated and may not even be possible if the cluster operator does not know all the uses of a Buildpack within the cluster. |
There was a problem hiding this comment.
This would be unnecessarily complicated and may not even be possible if the cluster operator does not know all the uses of a Buildpack within the cluster.
Good point. Thank you for enumerating the drawbacks of having the Builder reference the buildpack images.
rfcs/0000-buildpack-resource.md
Outdated
|
|
||
| The status of the ClusterBuildpack should match the status of the Buildpack resource. | ||
|
|
||
| ##### ClusterStore Resources |
There was a problem hiding this comment.
Will there be any migration concerns? One problem that jumped to mind is that this may increase complexity for getting started compared to configuring a ClusterStore. Although the user has to configure one less resource in this new world, they can currently pretty much copy and paste several lines of paketo buildpackages in one yaml file to configure the clusterstore. From this RFC it seems like the user would have to configure a buildpack/clusterbuildpack for each buildpackage they want to reference in a builder/clusterbuilder.
Most likely out of scope of this RFC, but perhaps it's additional impetus for the project to consider a more streamlined buildpack and stack bootstrapping process
There was a problem hiding this comment.
One problem that jumped to mind is that this may increase complexity for getting started compared to configuring a ClusterStore
I can add this to the RFC but, I hope that this will actually help simplify onboarding. Currently, because the Clusterstore is a monolithic resource users essentially need to use the kp cli and a published descriptor to be used alongside the cli. However, a Buildpack resource enables the Buildpacks to be managed independently which means a descriptor is not needed. Instead users can directly apply a preconfigured set of Buildpack/Builder/Stack resources with kubectl apply to get started fast. (This does require this WIP RFC to be implemented as well #932)
|
Just want to comment saying that I am excited for this update. As a user of kpack / "platform author" of platforms using kpack, these two points really resonate with me.
We had a use case where one team managed a set of the "blessed" buildplacks for the platform and we wanted to provide a few ancillary buildpacks around them. We didn't want to just copy the "blessed" |
matthewmcnew
force-pushed
the
buildpack-resource
branch
from
7738995 to
7cbd334
Compare
Thanks @yaelharel! Co-authored-by: Yael Harel <[email protected]>
|
solves #964 |
Readable