Re: [libvirt] [PATCH 01/20] Secret manipulation step 1: Public API
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 :|