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> > If <uuid/> is not specified, it is chosen automatically. > > The secret value can be either generated and stored by libvirt during > volume creation, or supplied by the user using virSecretSetValue(). > > A simple API is provided for enumeration of all secrets. Very large > deployments will manage secret IDs automatically, so it is probably not > necessary to provide a specialized lookup function (allowing the volume > key -> secret ID lookup in less than O(number of secrets)). These > functions can eventually be added later. > > Changes since the third submission: > - Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(), > virSecretGetValue(), virSecretSetValue(), and all derived interfaces. ACK, this API is fine now. 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