The Road to Persistence on Cloud Foundry Diego
summary
Research spike shows Cloud Foundry Diego can schedule persistent storage by treating volumes as first‑class resources, implementing a pluggable volume manager and two lifecycle signals interrupt and drain. Prototype runs Redis cluster and broker via CF CLI, supports both fixed and floating volumes (host‑local block devices vs network‑attachable storage), schedules volume sets across availability zones, and works on Diego with modest effort, enabling service brokers and per‑instance addressability.
AI-written summary · about
chapters (11)
- 0:00Introduction to research
- 0:23Current state of Cloud Foundry
- 2:12Extending 12 Factor apps
- 6:02Example CF CLI workflow
- 9:50Diego implementation overview
- 13:01Fixed vs floating volumes
- 14:06Scheduling example walkthrough
- 16:36Operational requirements
- 21:10Key interface changes
- 23:29Handling drain and interrupt
- 25:45Q&A session
related talks
30mDeploying Cloud Foundry with BBL, BOSH 2.0 and CF-Deployment
32mCloud Foundry Diego Update
20mAdvancing the Future of Cloud Foundry
33mCloud Foundry Weekly: Live at CF Day Germany
33mDocker and Cloud Foundry: The 3 Use Cases
30mHow to Facilitate the Cloud Foundry Adoption with Object Storage - Denis Jannot, Dell EMC
43mHow Platforms Work
30mOn-Demand Data Services with Cloud Foundry - Maria Ntalla & Simon Jones, Pivotal