...
>> + /* 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