Open Stack

> -----Original Message-----
> From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
> Sent: Thursday, December 13, 2012 6:46 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Booting multiple instances with block device
> mapping
> 
> 
> On Dec 12, 2012, at 3:45 PM, Caitlin Bestler <Caitlin.Bestler at nexenta.com>
> wrote:
> 
> >
> >
> > Phillip Pao wrote:
> >
> >> "it would be nice for cinder to have a concept of a read-only volume that
> could be attached to multiple instances"
> >
> > Or to be more precise, to be able to create thin volumes that
> > overlayed a read-only base, where multiple instances could each reference
> their own overlay of the common read-only base.
> 
> We already have this. If you create a snapshot and boot from the snapshot it
> will create a volume from the snapshot and run that way. Some backends
> already support thin provisioning on the snapshot -> volume conversion.
> 
> A read-only volume is different and could be useful for different reasons.
> These include copy-on-write or copy-on-read on the connecting side as well
> as worker images that could have a read-only root filesystem and a scratch
> disk.
> >
> > Further, we should allow that reference image to be replicated, so as
> > to allow the cloning to be done as close to the working VM as possible.
> 
> Replicating some "golden" images to multiple storage arrays also makes
> sense.
> 
> Vish
> __________


If we reject subsequent requests to attach a reserved volume during boot,
what would be the correct API response that should be returned for them.

Does 409 ConflictingRequest sound an appropriate response for the remaining instances?
_____________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding