Some folks have expressed concerns about the large number of custom resources involved in this spike, so we've been thinking of ways in which we can consolidate/remove them without too much impact to the design/functionality of the CF API Shim.
One opportunity to consolidate could be to condense CFPackages, CFBuilds, and CFDroplets into a single CR- probably named CFBuild.
Desired outcomes
Explore how feasible it would be to consolidate the CFPackages, CFBuild, and CFDroplet custom resources into a single resource. Implement it as a branch of this spike repo and write a Proposal document to explain your findings and propose a course of action.
Questions to consider:
How do we implement the granular Package & Droplet v3 endpoints if there is no dedicated Droplet resource?
We never implemented the GET endpoints for Droplets on the spike. We may need to implement it for this exploration.
We need to see if it's possible for the CFBuild controller to gracefully handle the addition of Droplet data- possibly with the addition of more Conditions or status fields.
What are the benefits of consolidating these resources?
What are the downsides?
If we combine all three resources, how could a person re-use packages for builds? Do we care about supporting this?
Check with Eric to confirm the prevalence of re-staging a package to test new buildpack compatibility. We assume there is room to de-prioritize the maintenance of that explicit workflow.
Acceptance Criteria / Scenarios
By the end of this explore we should have:
Example CR representing both Package/Build/Droplet
Workable spike code demonstrating what this looks like.
Callout of what features we may no longer be supporting by combining the three.
A Proposal document recommending a next course of action.
[Timeboxed to 3 days]
Context / Background
Some folks have expressed concerns about the large number of custom resources involved in this spike, so we've been thinking of ways in which we can consolidate/remove them without too much impact to the design/functionality of the CF API Shim.
One opportunity to consolidate could be to condense CFPackages, CFBuilds, and CFDroplets into a single CR- probably named CFBuild.
Desired outcomes
Explore how feasible it would be to consolidate the CFPackages, CFBuild, and CFDroplet custom resources into a single resource. Implement it as a branch of this spike repo and write a Proposal document to explain your findings and propose a course of action.
Questions to consider:
How do we implement the granular Package & Droplet v3 endpoints if there is no dedicated Droplet resource? We never implemented the GET endpoints for Droplets on the spike. We may need to implement it for this exploration. We need to see if it's possible for the CFBuild controller to gracefully handle the addition of Droplet data- possibly with the addition of more Conditions or status fields. What are the benefits of consolidating these resources? What are the downsides? If we combine all three resources, how could a person re-use packages for builds? Do we care about supporting this? Check with Eric to confirm the prevalence of re-staging a package to test new buildpack compatibility. We assume there is room to de-prioritize the maintenance of that explicit workflow.
Acceptance Criteria / Scenarios
By the end of this explore we should have:
Example CR representing both Package/Build/Droplet Workable spike code demonstrating what this looks like. Callout of what features we may no longer be supporting by combining the three. A Proposal document recommending a next course of action. [Timeboxed to 3 days]