On Thu, Aug 20, 2009 at 08:17:59PM +0200, Miloslav Trma?? wrote:
This patch adds a "secret" as a separately managed object, using a special-purpose API to transfer the secret values between nodes and libvirt users.
Rather than add explicit accessors for attributes of secrets, and hard-code the "secrets are related to storage volumes" association in the API, the API uses XML to manipulate the association as well as other attributes, similarly to other areas of libvirt.
The user can set attributes of the secret using XML, e.g. <secret ephemeral='no' private='yes'> <uuid>b8eecf55-798e-4db7-b2dd-025b0cf08a36</uuid> <volume>/var/lib/libvirt/images/mail.img</volume> <description>LUKS passphrase for our mail server</description> </secret>
Following on with my comments fro the virsh patch later in this series, I reckon we ought to move the 'volume' element inside a 'usage' element eg, to look like <secret ephemeral='no' private='yes'> <uuid>b8eecf55-798e-4db7-b2dd-025b0cf08a36</uuid> <usage type='volume'> <volume path='/var/lib/libvirt/images/mail.img'/> </usage> <description>LUKS passphrase for our mail server</description> </secret> So, if we then allow the virSecret APIs to be used for things like the guest VNC server, we could have a nice variation such as <secret ephemeral='no' private='yes'> <uuid>b8eecf55-798e-4db7-b2dd-025b0cf08a36</uuid> <usage type='vnc'> <guest name='myguest'/> </usage> <description>LUKS passphrase for our mail server</description> </secret> and other variations for whatever we might need in the future. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|