On Tue, Jul 05, 2016 at 09:33:30AM -0400, John Ferlan wrote: > > > On 07/04/2016 09:42 AM, Daniel P. Berrange wrote: > > On Fri, Jun 24, 2016 at 04:53:31PM -0400, John Ferlan wrote: > >> Add a new secret type known as "passphrase" - it will handle adding the > >> secret objects that need a passphrase without a specific username. > >> > >> The format is: > >> > >> <secret ...> > >> <uuid>...</uuid> > >> ... > >> <usage type='passphrase'> > >> <name>mumblyfratz</name> > >> </usage> > >> </secret> > > > > I'm not seeing the purpose of adding this secret usage type. It also > > seems quite different from the usage types we have already. > > > > The essential purpose of the usage 'name' is to allow you to figure > > out what corresponding libvirt object is using the secret. So for > > example with usage type=volume, the name refers to the disk path > > of the volume. With usage type=iscsi or type=ceph, the name refers > > to the server name. > > > > This usage type=passphrase is not directly associating the secret > > with anything, and doesn't appear to have any defined sematics for > > what the 'name' should contain or refer to. > > > > This all feels quite odd & possibly wrong to me. > > > > FWIW: I'm on PTO this week, but I do have a few minutes of time to > provide some feedback... NP, we can wait until you return to resolve it - as long as we decide before the 2.1 release we're fine. > This type of secret started out in my own branches as a "luks" secret, > since that's what it was designed to (at least) initially support. > > After starting to think and work with the TLS code, I modified it to a > "key" secret - mainly because they were the essentially the same type of > secret. At that time I did consider passphrase, but wasn't convinced it > was the best name, so "key" was it (plus less characters to type). I > also figured it was better to use the same type of secret since they > provided essentially the same functionality - a key/passphrase to be > provided for some other object to unlock access to the object (for lack > of a better term, at this moment). > > Both series were posted and I noted the common parts of both. The luks > code was reviewed and the suggestion was to use "passphrase", so I went > that way. Ok, so for LUKS i'd expect us to continue to just use the existing USAGE_TYPE_VOLUME we already have for this purpose. > If it needs to change again, that can be done when I'm back next week > (or by someone before I get back). If the two need to be separated > that's fine too. They'll share a lot of similarities though. I think > other than the target service object they support, the iscsi and ceph > secret are fairly similar. So it's not unprecedented. If they are > separated, then does that mean there's a TCPTLS secret, a MIGRATIONTLS > secret, and an NBDTLS secret? The secret usage is associated with a particular type of object requiring credentials. In that case the object type is a TLS key. The fact that you can use the TLS key for different services is not relevant. So I'd say the usage would be USAGE_TYPE_TLS_KEY and the data associated with it would be the path of the TLS key pem file. 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