**POTENTIAL BREAKING CHANGES** RFC: Rename the CustomBuilder Resource. Remove the Builder Resource. #439
Conversation
matthewmcnew
force-pushed
the
rfc-remove-builder
branch
from
c9e8213
to
44e18e7
Compare
matthewmcnew
changed the title
There was a problem hiding this comment.
Overall I would lean to approving this RFC. But would feel better if we had a strong mitigation for the transition from pack to kpack.
Edit: approving because I think the benefits of simplicity outweigh the loss of pack build && kubectl create builder -f pack-builder.yaml.
| @@ -0,0 +1,34 @@ | |||
| Today, kpack has a complicated hierarchy of builder resources (Builder & ClusterBuilder & CustomBuilder & CustomClusterBuilder). Navigating this hierarchy is hard to explain and has consistently been confusing in early feedback. This is complicated by the recommended kpack experience being "CustomBuilders" when it appears that the obvious default is "Builder" or "ClusterBuilder". | |||
|
|
|||
| The existing "Builder" relies on a polling mechanism to monitor an external Builder for buildpack and stack updates. External polling mechanisms in core kpack types have been a source of confusion that contradicts the pure declarative philosophy outlined in the [kpack monitors rfc](https://github.com/pivotal/kpack/pull/433). | |||
There was a problem hiding this comment.
+1 that I think kpack monitors cover the use case of Builders
| The Builder could be renamed to something like "PreBuilt" Builder. This will allow users to continue utilizing external Builders. However, this approach does not resolve the underlying problems with the Builder concept and may continue to encourage users to use the PreBuiltBuilder. | ||
|
|
||
|
|
||
| ## Risks: |
There was a problem hiding this comment.
This has been brought up by @djoyahoy – one risk is that the Builder is a Cloud Native Buildpacks concept (however not a spec concept) and is an artifact that can be created and used by the Cloud Native Buildpacks pack cli project.
This means the builders created by pack can be used in kpack and makes builders a natural transition path from using pack cli to using kpack. Removing the Builder resource could make this transition tougher.
There was a problem hiding this comment.
If we do switch to renaming CustomBuilder > Builder, it would end up with the term Builder meaning two different things (as pointed out by @tylerphelan) in the CNB context and kpack context. And, considering kpack is a CNB platform implementation, this may not be ideal?
I do agree that CustomBuilder usage is the best experience for a kpack user.
There was a problem hiding this comment.
This means the builders created by pack can be used in kpack and makes builders a natural transition path from using pack cli to using kpack. Removing the Builder resource could make this transition tougher.
I am hopeful that our kpack cli will be able to help make the transition from pack to kpack smoother and easier for new users.
I also would conjecture that it is more important to optimize for onboarding with (Custom)Builders in kpack than optimizing for onboarding in general.
There was a problem hiding this comment.
If we do switch to renaming CustomBuilder > Builder, it would end up with the term Builder meaning two different things (as pointed out by @tylerphelan) in the CNB context and kpack context. And, considering kpack is a CNB platform implementation, this may not be ideal?
I'll need to think about this a bit more but, it is not quite two different things because the (Custom)Builder concept in kpack is broadly equivalent to pack create-builder and kpack (Custom)Builder image are usable as a builder with pack. So, it is more that pack created builders are not directly useable with kpack.
| @@ -0,0 +1,34 @@ | |||
| Today, kpack has a complicated hierarchy of builder resources (Builder & ClusterBuilder & CustomBuilder & CustomClusterBuilder). Navigating this hierarchy is hard to explain and has consistently been confusing in early feedback. This is complicated by the recommended kpack experience being "CustomBuilders" when it appears that the obvious default is "Builder" or "ClusterBuilder". | |||
There was a problem hiding this comment.
I agree that the overhead and confusion of having two resources is a significant concern.
|
I remember circling back a bunch of times re-reading the docs before settling on what is presently If we can't ponder a valid use case for the ClusterCustomerBuilder it could be another decision point to axe to simplify initial adoption. |
tylerphelan
changed the title
|
That is a good question @thephw. I think the thought is that a Custom(Cluster)Builders are useable in a multi-namespace/multi-tentant environment where a cluster administer would like to create and manage a builder for multiple different namespaces. It seems like our docs should recommend starting with namespaced resources. Do you think you would ever use kpack in a multi-namespace environment? |
|
@matthewmcnew We really use the build artifacts (built images) across namespaces, but not the whole kpack build process itself. We have the build process isolated since buildpacks need source access and we build images for multiple tenants of the service. In our usage, namespaces and other k8s security policies help avoid having as many attack vectors for multi-tenant builds. |
|
@thephw Doest that mean all kpack images are in one namespace? |
|
I like this idea a lot, but I would like to also raise the possibility that we remove |
|
This may be implicitly part of the RFC and I'm missing it, but I understood the intention of the static "Builder" to partly be a convenience for new users who just wanted to learn the tool and weren't particularly picky about how their app got built (i.e. didn't need to customize or optimize the build process). How does this change affect this use case? Will there still be a default builder to get started with? |
@sampeinado A resource has a scope (Namespace/Cluster), so it is not possible to for this to be configured in the resource's spec. |
@sampeinado kpack will provide new tooling to make it easy to easily get setup. This is likely possible with an import functionality on the kpack cli that can automatically setup the necessary resources. |
|
Merging. This will be released in the 0.1.0 release of kpack. Please submit a future RFC if you would like to take kpack in a different direction. |
Readable