[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] [PATCH 0/4] Changes to API/ABI for secrets handling

This series makes two changes to the public API and wire protocol ABI
for the secrets handling support recently committed.  As such this is
a must fix before we do the release, since we can't break compatability
once released.

The first patch changes all the code to store UUIDs in raw format
instead of printable format. This is important because it ensures
that e3a9758f-b0c6-7a3a-ebb9-71a69c930289 is treated exactly the
same as e3a9758fb0c67a3aebb971a69c930289, which is not the case
with the currently committed code. It also makes the secrets and
storage encryption XML parsers use the internal UUID handling APIs

The second patch adds a new unique property to virSecretPtr. The
"owner ID" is intended to be unique on a host wrt all secrets with
matching usage type. This entails adding 2 APIs to querying the usage
type, and another API to lookup a secret based on its usage. In 
testing the current code I frequently  found myself getting into the
situation where there were many secrets for the same volume which was
not at all good. So if defining a secret to be used with a storage
volume this ensures that you only ever have one secret associated with
each storage volume path.

The third patch ensures that when you query the XML for a qcow
encrypted voluem, it will include the UUID of the secret. Previously
if you created a volume, and then restarted libvirtd, the secret
UUID would be lost. This patch is why we need the new API from
the second patch virLookupSecretByUsage - without that it would
be impossible to lookup the secret efficiently.

THe final patch is a minor tweak to the RNG

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]