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