On 09/22/2017 05:44 AM, Peter Krempa wrote: > On Fri, Sep 15, 2017 at 20:30:14 -0400, John Ferlan wrote: >> Currently when an AES secret object is added to the domain for >> either a network disk, a LUKS encryption secret, or for a SCSI >> hostdev there is no way for domain restart to be able to connect >> or determine which secret by secrettype and uuid or usage was >> used in order to generate the object. >> >> So, in order to be able to lookup which secret generated the >> object, this patch will create and manage a private object hash >> table that tracks when a disk using the secret object is added >> or removed in order to be able to "rebuild" the secret. >> >> This information will be recorded in the domain private XML file >> so that when libvirtd restarts, we can rebuild and determine which >> secret was used. >> >> The qemuDomainObjDiskSecretObjectAliasEntryLookup helper is >> currently unused, but it's purpose would be to find the object >> alias in the table and return the usageType and seclookupdef >> that created the object. Could be quite useful for something. > > I don't quite see the reason to add all this code. All secret related > stuff can be stored in the virStorageSource private data. If you need to > format and load it, you can iterate them in the private XML formatter > and don't need any hash table. > > Additionally you should not need to be able to identify which secret was > used once the VM is running, since we don't access it afterwards. Also > the secret data can become stale since user may undefine the secret. > > Looks like this is quite a lot of code without any real use case, thus > I'm inclined to a NACK, if you don't provide any more supporting > explanation. > No special reason - I wasn't sure if being able to look up the secret from an alias provided was going to be useful or not. I did discuss this in the cover, but IIRC you don't always read those ;-). John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
