...
>>> + /* Shared processing code with storage pools can leave
>>> + * this empty, but disk formatting uses it as does command
>>> + * creation - so use the secretType to attempt to fill it in.
>>> + */
>>> + if (!authdef->secrettype) {
>>> + const char *secrettype =
>>> + virSecretUsageTypeToString(authdef->secretType);
>>> + if (VIR_STRDUP(authdef->secrettype, secrettype) < 0)
>>> + goto error;
>>> + }
>>
>> So _virStorageAuthDef has both @secrettype and @secretType? That's
>> rather perplexing.
>>
>
> Yeah - I think it was a "convenience" perhaps when trying to combine the
> various authdef functions that had existed. I look to generate a
> followup that removes the need for it
>
Ahh - now that a few more caffeine cells have been coursing through my
bloodstream - I remember what the difference is and I also see I made a
mistake in which I was using (<sigh>).
The 'secrettype' is what is read from XML "<secret type='%s'...". It is
optional and is used differently depending whether it's in the domain
'disk' or the storage pool 'source' definition.
For the domain disk, there is no <auth> 'type' field, while there is a
<secret> 'type' field.
For the storage pool, there is an <auth> 'type' field, while there is no
<secret> 'type' field.
The 'secretType' is used to determine whether a 'usage' or 'uuid' was
found the "<secret..." XML and virSecretUsageTypeToString does the magic
to properly format. So using it to format the secrettype is wrong.
Of course because I added the VIR_STORAGE_TYPE_VOLUME check to ignore
auth_secret_usage and eventually virStorageTranslateDiskSourcePool is
run, so I didn't see my mistake, but now I do.
I'll post an adjustment - the current patch works because eventually
virStorageTranslateDiskSourcePool overwrites the mistake.
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list