[RFC] Enhance Stack Handling

[FloThinksPi]

Click Here for a better reviewable/readable version.

General RFC Review comments can go into this PRs comments section.
If you`d like to comment/join the conversation on a specific proposal see following sub discussions per proposal:
RFC-0040 - Proposal: Improve logical stack management in CF API (cloud_controller_ng)
RFC-0040 - Proposal: Bring your own Stack
RFC-0040 - Proposal: Provide a stack with every ubuntu LTS

[rkoster]

Hi @FloThinksPi,

Thank you for drafting RFC-0040! It provides a comprehensive overview of enhancements to stack handling in Cloud Foundry, and I appreciate the effort you’ve put into addressing these critical issues.

However, I feel the RFC could benefit from being split into individual, logically scoped RFCs to improve focus and facilitate discussion. For example:

1. Improved Logical Stack Management: Covering changes to CF API for stack states like deprecated, locked, disabled, and their timestamps.

2. Bring Your Own Stack: Discussing the introduction of user-managed stacks via container image references and the related CF API changes.

3. Stack Release Cycle Alignment: Addressing the proposal to build stacks for every Ubuntu LTS release.

4. Org-Scoped Stack Management: Introducing organization-specific stack visibility and control.

Each topic is significant and detailed enough to warrant its own RFC. Splitting them would allow contributors to dive deeper into specific areas, streamline discussions, and prioritize implementation efforts more effectively.

On a higher level I'm also worried about handing responsibility for stacks in the hands of app developers. One of the great features of CF is that platform operators can fix CVEs in for example OpenSSL with a single bosh deploy.

I understand the desire to fix this, but maybe a compromise could be found in making stack management an admin only feature (using the cf cli). Ideally using a blobstore first approach so it works in airgapped environments.

Last but not least I'm wondering about the roll out mechanisms for handeling custom stack updates, given these changes are not orchestrated through bosh, how do we ensure we don't over we Diego? There needs to be some sort of global max_in_flight setting to control the total number of apps that are being restarted at the same time.

[FloThinksPi]

Thanks for the Feedback @rkoster,

I can split it in multiple RFCs however i think then the big picture is lost for which the RFCs are made as the sum of the 3 RFCs/Proposals only together brings improvements for the problem. I would rather like to accept or dismiss individual proposals as the result of the review and then document it in the proposals which one is accepted and which one is not. And then Accept or Dismiss the RFC as a whole. Maybe we can open multiple https://github.com/cloudfoundry/community/discussions for each proposal and link them here, would that help in the review process to structure it better ?

E.g. for the Proposals:
RFC-0040 - Proposal: Improve logical stack management in CF API (cloud_controller_ng)
RFC-0040 - Proposal: Bring your own Stack
RFC-0040 - Proposal: Provide a stack with every ubuntu LTS

The last proposal is just a "Note for Future Reference" not an actual proposal to commit to but to pull out in case its desired in some months/years as extension scenario.

I`ll answer in the Discussions on the other questions you had just to try that also out :)