On Tue, Nov 12, 2013 at 2:02 PM, Caitlin Bestler <caitlin.best...@nexenta.com> wrote: > On 11/12/2013 10:42 AM, John Griffith wrote: > >> >> Sorry, but I'm not seeing where you're going with this in relation to >> the question being asked? The question is how to deal with creating a >> new bootable volume from nova boot command and be able to tell whether >> it's timed out, or errored while waiting for creation. Not sure I'm >> following your solution here, in an ideal scenario yes, if the backend >> has a volume with the image already available they could utilize >> things like cloning or snapshot features but that's a pretty >> significant pre-req and I'm not sure how it relates to the general >> problem that's being discussed. >> > > I see the issue being discussed as "how to effectively deploy from Glance to > Cinder boot images". Viewing the issue as being the lack > of time-out or error messages on a path that was already too long > is limiting. > > Yes, if you are going to deploy from Glance in that fashion then > time-out and error messages are undoubtedly needed. The more important > issue is that the this is instrumenting a poor method of deploying > from Glance. > > There are indeed many steps in the more complete solution: > * Check-out from glance for target environment. > * Create snapshot > * Replicate snapshot to desired target(s). > * When bootable image is needed: > * Clone volume from snapshot. > * Boot from volume > > But all of those steps can be orchestrated behind a taskflow, which > can also deal with Volume Drivers that do not efficiently snapshot. > > My point is that taking the shackles off of snapshots and making them > first class Cinder objects is a solution to *many* problems - booting > based upon a Glance master is just one of them.
Ok, not related to the OP's question. We can start a specific Cinder thread if you like but honestly many of us have "solved" this in a sense already. For those backends that support things like fast cloning, COW's etc the solution in practice by users is to do the create from image once, then clone that volume as a template. This isn't exactly what you're getting at, however it's effective and the implementation is universal (ie it works no matter what backend you're using; granted some faster than others) but the implementation details you describe are abstracted away so the end users or even the operators don't have to care. I understand your device has a high value on what it can do in terms of snapshots, so by all means implement things like clone operations to use that capability since you can have that object live independently of the parent volume. The point though is to keep as much of that "specialized" behavior as possible hidden or abstracted while providing equivalent semantics regardless of backend device choices. Feel free to start a separate Cinder thread if you'd like a broader discussion. > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
