On Tue, Jul 05, 2016 at 10:44:30AM -0400, John Ferlan wrote: > > > >>> Ok, so for LUKS i'd expect us to continue to just use the existing > >>> USAGE_TYPE_VOLUME we already have for this purpose. > >>> > >> > >> That then requires the "usage" of a <secret> in the domain xml to list > >> the volume path. So rather than: > >> > >> <encryption format='luks'> > >> <secret type='passphrase' usage='luks_example'/> > >> </encryption> > >> > >> it'd be: > >> > >> <encryption format='luks'> > >> <secret type='volume' usage='$LUKS_VOLUME_PATH'/> > >> </encryption> > >> > >> (or of course uuid='$UUID') > >> > >> I was looking to have a "more clear" delineation between a secret that > >> "could be" generated automagically (e.g. some randomly generated > >> passphrase) for a qcow volume and one that "someone" defines/sets for a > >> luks volume. > > > > Why would we want any such delineation ? Regardless of where the secret > > is generated, it is still used in the same functional manner, so I don't > > see an obvious benefit to distinguish them ? > > > > One is generated for you (essentially) and one is provided by someone in > order to unlock their luks volume. I guess I see a functional > delineation between the two, although I do understand what your > viewpoint is on this. There may have been another reason I felt the need > to delineate, but that would mean more time to put the qcow volume > encryption code back into my head than I have to process right now... >From the POV of the code that is consuming the secrets, there absolutely no functional difference. The usage type is associating with the consuming so I think the difference in generation approach is really irrelevant for the consumer. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list