Yeah, existing volumes have a path thats already set in stone. It would only concern new volumes.
It could cause problems down the line if people get used to them matching and decide to use uuid and path interchangeably. They're not by default identical though since the path usually contains the directory and filename/uuid (at least for qcow2, I think LVM just has the logical volume uuid as path). On Oct 9, 2013 11:21 PM, "Prasanna Santhanam" <t...@apache.org> wrote: > +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 > >
