Context / Background
For the CRD Spike, we delayed on implementing the logic for the lifecycle block within the CF App and CF Build CRs. Instead we simply defaulted to using a single kpack ClusterBuilder for everything.
Now that we are implementing the CFBuild flow in earnest, we need to nail down a proposed design for handling these lifecycle fields as part of cf push.
At the time of writing this issue, we are contemplating the following approach:
Specify a default builder per-namespace with a superset of buildpacks/stacks to use
When users specify their own set of lifecycle fields, a new Builder is created for that App/Build exclusively as part of the CF Build Reconcile loop.
What modifications would we have to make to the staging Controllers and Webhooks to allow for users to build images in any CF Spaces they have access to, and push them to the per-Org/per-Space registry configured by the platform operator?
Constraints
We must be able to support a base-image upgrade. In cf-for-k8s it was common for the base image of cflinuxfs3 to be updated with CVEs, which would result in apps being rebuilt and redeployed automatically.
After an explore that we performed, we discovered that even the ClusterBuilder registry credentials must be available in every namespace where kpack builds are performed. The proposal should mention how the addition of new Spaces will be handled with regards to these Builder credentials, as well as how they will be discovered by the Build Controller.
Limit the scope of this exploration to exclude (we will follow up in the near future):
Rolling back to a previous droplet
The use of kpack Image vs Build to support build workflows
Desired outcomes
After deciding on a design, please create an ADR in the cf-k8s-controllers repo documenting the proposal and decision.
Additionally, please consider and include on the following questions:
If a default, superset Builder is used, how will it be configured, via ConfigMap or otherwise?
What implications does the proposed strategy have on buildpack/stack upgrades? Please include a high-level summary of the user actions required to roll out such an upgrade.
Acceptance Criteria / Scenarios
This issue can be closed when the ADR is accepted by at least two reviewers and merged to the main branch of the cf-k8s-controllers repo.
Context / Background For the CRD Spike, we delayed on implementing the logic for the lifecycle block within the CF App and CF Build CRs. Instead we simply defaulted to using a single kpack ClusterBuilder for everything.
Now that we are implementing the CFBuild flow in earnest, we need to nail down a proposed design for handling these lifecycle fields as part of
cf push.At the time of writing this issue, we are contemplating the following approach:
What modifications would we have to make to the staging Controllers and Webhooks to allow for users to build images in any CF Spaces they have access to, and push them to the per-Org/per-Space registry configured by the platform operator?
Constraints We must be able to support a base-image upgrade. In
cf-for-k8sit was common for the base image ofcflinuxfs3to be updated with CVEs, which would result in apps being rebuilt and redeployed automatically.After an explore that we performed, we discovered that even the ClusterBuilder registry credentials must be available in every namespace where kpack builds are performed. The proposal should mention how the addition of new Spaces will be handled with regards to these Builder credentials, as well as how they will be discovered by the Build Controller.
Limit the scope of this exploration to exclude (we will follow up in the near future):
Desired outcomes After deciding on a design, please create an ADR in the cf-k8s-controllers repo documenting the proposal and decision.
Additionally, please consider and include on the following questions:
Acceptance Criteria / Scenarios This issue can be closed when the ADR is accepted by at least two reviewers and merged to the main branch of the cf-k8s-controllers repo.
Notes
Timebox to 3 days, but check in with the team at 2 days.