Hello,
based on your comments, here is a proposal for a "secret management" API.
Rather than add explicit accessors for attributes of secrets, and hard-code the
"secrets are related to storage volumes" association in the API, the proposed
uses XML to manipulate the association as well as other attributes, like it is used in
other areas of libvirt.
The user would allocate an ID for the secret using virSecretAllocateID(), set attributes
of the secret using XML, e.g.
<secret ephemeral='no' private='yes'>
<volume>/var/lib/libvirt/images/mail.img</volume>
<description>LUKS passphrase for the main hard drive of our mail
server</description>
</secret>
Then, the secret value can be either generated and stored by libvirt, or supplied by the
user using virSecretSetValue().
A simple API is provided for enumeration of all secrets. Very large deployments manage
secret IDs automatically, so it probably is not necessary to provide specialized lookup
functions (e.g. allowing the volume key -> secret ID lookup in less than O(number of
secrets)).
The <encryption> element used in volume and domain specifications remains, but it
never contains any secrets directly, only something like
<secret type='passphrase'
secret_id='c1f11a6d-8c5d-4a3e-ac7a-4e171c5e0d4a' />
More detailed documentation is in the patch.
Does that look OK?
Thank you,
Mirek