Date
1 - 4 of 4
Persistent Volumes on Cloud Foundry
Ted Young
This proposal describes the changes necessary to the Service Broker API to
utilize the new Volume Management features of the Diego runtime. It contains examples of how services can provide a variety of persistent data access to CF applications, where each service maintains control of the volume lifecycle. This is to allow some services that provide blank storage space to applications, and other services that provide access to complex or externally managed data (such as IBM's Watson). http://bit.ly/cf-volume-proposal We are moving fast on delivering a beta of this feature, so please have a look and give feedback now if this is of interest to you. More detail will be added to the proposal as necessary. Cheers, Ted Young Senior Engineer / Product Manager Pivotal Cloud Foundry |
|
Dr Nic Williams <drnicwilliams@...>
Is a goal of this work to run pure data services like PostgreSQL or Redis inside "application instances"?
toggle quoted message
Show quoted text
On Tue, Apr 5, 2016 at 5:01 PM -0700, "Ted Young" <tyoung(a)pivotal.io> wrote:
This proposal describes the changes necessary to the Service Broker API to utilize the new Volume Management features of the Diego runtime. It contains examples of how services can provide a variety of persistent data access to CF applications, where each service maintains control of the volume lifecycle. This is to allow some services that provide blank storage space to applications, and other services that provide access to complex or externally managed data (such as IBM's Watson). http://bit.ly/cf-volume-proposal We are moving fast on delivering a beta of this feature, so please have a look and give feedback now if this is of interest to you. More detail will be added to the proposal as necessary. Cheers, Ted YoungSenior Engineer / Product ManagerPivotal Cloud Foundry |
|
James Bayer
nic,
if you look at this section of the doc [1] it discusses "Reattachable Volumes" which are similar to EBS volumes attaching to EC2 instances without allowing multiple instances to be bound to the same volume at the same time. that likely aligns better with a database style use case (although performance of remote volumes will certainly be a consideration depending on the performance requirements). there is some new diego scheduling work required for "Reattachable Volumes". "Distributed Filesystem" (same volume attached to multiple instances at the same time like NFS) and "Scratch" (temporary extra disk) are use cases which are planned to be supported first as they do not require diego scheduler changes to use now. the doc also references snapshots as something that may be needed for this use case. there is discussion going on in the doc if you want to continue it there. [1] https://docs.google.com/document/d/1FPTOI1Wqhceh_7SsSICuhhosbtCw6PDCEvLbsxrep0A/edit#heading=h.mxp2p82umj8r On Tue, Apr 5, 2016 at 8:02 PM, Dr Nic Williams <drnicwilliams(a)gmail.com> wrote: Is a goal of this work to run pure data services like PostgreSQL or Redis -- Thank you, James Bayer |
|
Ted Young
Yes like James said, assuming a Consistent/Service Scheduler is running in
toggle quoted message
Show quoted text
alongside our High Availability Scheduler, you could run databases like PostreSQL and Redis. They would use network attached storage, or local storage if the deployment supports that scenario. On Wed, Apr 6, 2016 at 11:22 AM, James Bayer <jbayer(a)pivotal.io> wrote:
nic, |
|