When creating a model, Juju interprets an HTTP 500 status code received from LXD's "create storage pool" endpoint as an "Already Created" error (which is safe to ignore) iff the controller state has already made note of that storage pool.
In essence, Juju is querying two non-atomically updated sources to determine if an error from LXD is safe to ignore. These sources are not updated atomically so creating models in parallel can fail just as you have seen above.
I can see a couple of solutions to this problem:
1) We can ask to have the LXD API updated to return a more specific HTTP code for "Already Exists" (many popular API's i.e Github return 422 for already exists)
2) We can search the error string returned by the LXD API to determine the cause of the error - which as of LXD 2.21 will contain "pool already exists" when the pool has already been created
I do understand that literature exists which advises against processing error message strings.
Hello John,
When creating a model, Juju interprets an HTTP 500 status code received from LXD's "create storage pool" endpoint as an "Already Created" error (which is safe to ignore) iff the controller state has already made note of that storage pool.
In essence, Juju is querying two non-atomically updated sources to determine if an error from LXD is safe to ignore. These sources are not updated atomically so creating models in parallel can fail just as you have seen above.
I can see a couple of solutions to this problem:
1) We can ask to have the LXD API updated to return a more specific HTTP code for "Already Exists" (many popular API's i.e Github return 422 for already exists)
2) We can search the error string returned by the LXD API to determine the cause of the error - which as of LXD 2.21 will contain "pool already exists" when the pool has already been created
I do understand that literature exists which advises against processing error message strings.