+1 - happens in lots of places in our code where a random-uuid associates with a physical resource's uuid.
Will this will happen only for new volumes? Old volumes can still be listed and found using the old method? I'm specifically concerned about upgraded systems. On Wed, Oct 09, 2013 at 11:05:48PM -0600, Mike Tutkowski wrote: > Yeah, I'm not really clear how the snapshot strategy works if you have > multiple vendors that implement that interface either. > > > On Wed, Oct 9, 2013 at 9:57 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > > > Does anyone have any reservations about changing the volume identifier in > > KVM's volume creation command to be the uuid of the volume? Currently for > > new volumes it generates a random uuid and passes that back to be stored in > > the database. From an admin perspective, the only way to link a volume on > > the back end (be it a qcow2 image or an LVM volume) to one as reported is > > to look in the DB and see what this 'secondary uuid' is and look for THAT > > as the filename/image name on the back end. It would simply remove a layer > > of translating uuid to another hidden uuid to get file/volume name. > > > > It shouldn't disrupt or change current volumes, just new ones. > > > > The only caveat I can think of so far is if we wanted multiple files/images > > on the back end to map to one volume, but I don't see that as a blocker > > since it would probably have lots of other implications to the tracking > > volume objects. > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *?* -- Prasanna., ------------------------ Powered by BigRock.com
