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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list