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 :|