Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

This is very clear - thank you for taking the time to split it out from #4055.

I'm not sure it makes sense to punt on the dynamic creation issue - that seems like it will be a very common use case (AWS, GCE, OpenStack, SANs). What is the plan here? I can see two options:

1. The cloud provider dynamically creates a volume when one is claimed. (And if so, how does the client know that a volume will magically appear on-demand so it doesn't block the request because it sees there are no volumes available?)
2. the caller creates a volume (with an API call) before creating their claim.

I think a worked example of launching a pod with a volume in this scenario would clear up my confusion here!

We're not punting on dynamic provisioning, just putting the API in place first for Persistent Volumes. The horse goes before the cart.

Our experience with Open Shift is that creating and formatting a volume on the fly is slow. Better to have a pool of readily available volumes to mount, at least at the present time. As that process gets better, though, the time between "create" and "consume" will decrease, possibly enough to allow on the fly creation.

The dynamic provisioning of volumes is not yet specified.

I expect dynamic provisioning will come soon after this is all integrated. I think THIS is a 1.0 blocker, but dynamic is probably not.

@thockin agreed because an admin can script the creation of the volumes. dynamic provisioning eases their pain.

Can you clarify if a PersistentVolume drives Events in the system? If so, can we assert that any events it spawns will be treated consistent with Node objects. Meaning they will go in the cluster-id namespace?

And because I was bit by this before, why did we merge a PR that was WIP?

I forgot to edit the subject, but you have good feedback. Mark can get
that feedback wrapped up as a new PR :)

On Fri, Mar 6, 2015 at 4:55 PM, Derek Carr notifications@github.com wrote:

And because I was bit by this before, why did we merge a PR that was WIP?

—
Reply to this email directly or view it on GitHub
#5096 (comment)
.