Destroying model while creating it leaves Juju in error state

[oEscal]

Today, while using the python-libjuju (sync with the master's code), I tried to destroy a model (model b33efb29-37dc-4bd8-8a68-0aa097b5e6c1) while it was being deployed. This originated a strange error on Juju. The logs given by the python-libjuju are the following ones:

[...]
await controller.destroy_model(
  File "/usr/local/lib/python3.8/dist-packages/juju/controller.py", line 391, in destroy_models
    await model_facade.DestroyModels(models=params)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/facade.py", line 482, in wrapper
    reply = await f(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/_client5.py", line 7562, in DestroyModels
    reply = await self.rpc(msg)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/facade.py", line 655, in rpc
    result = await self.connection.rpc(msg, encoder=TypeEncoder)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connection.py", line 644, in rpc
    raise errors.JujuError(err_results)
juju.errors.JujuError: ['model b33efb29-37dc-4bd8-8a68-0aa097b5e6c1 has been removed']

At the same time, I was also destroying another model (osm-kdu-3fbc1930-9123-4104-a9fe-485e806ed788), where I first get the model, to then destroy it, which also has provoked the following error log:

JujuAPIError -> Attempts (3) are over for <function Libjuju.get_model at 0x7fced78ebd30>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/retrying_async.py", line 139, in wrapped
    ret = yield from ret
  File "/app/N2VC/n2vc/libjuju.py", line 275, in get_model
    return await controller.get_model(model_name)
  File "/usr/local/lib/python3.8/dist-packages/juju/controller.py", line 604, in get_model
    await model._connect_direct(**kwargs)
  File "/usr/local/lib/python3.8/dist-packages/juju/model.py", line 757, in _connect_direct
    await self._connector.connect(**kwargs)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connector.py", line 74, in connect
    self._connection = await Connection.connect(**kwargs)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connection.py", line 338, in connect
    await self._connect_with_redirect([_ep])
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connection.py", line 852, in _connect_with_redirect
    login_result = await self._connect_with_login(endpoints)
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connection.py", line 824, in _connect_with_login
    result = (await self.login())['response']
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connection.py", line 913, in login
    return await self.rpc({
  File "/usr/local/lib/python3.8/dist-packages/juju/client/connection.py", line 627, in rpc
    raise errors.JujuAPIError(result)

This then seems to create some kind of race condition in Juju, where I am trying to remove the first model (which does not appear when I run juju models --all):

juju destroy-model b33efb29-37dc-4bd8-8a68-0aa097b5e6c1 --force -y
ERROR cannot connect to API: model "osm-kdu-3fbc1930-9123-4104-a9fe-485e806ed788" has been removed from the controller, run 'juju models' and switch to one of them.

Note that the model given by the ERROR message in Juju is not the same, it is the second one... This one, on the other hand, is listed by juju models --all (with no status). When I try to remove it, the following message appears:

juju destroy-model osm-kdu-3fbc1930-9123-4104-a9fe-485e806ed788 --force -y
ERROR cannot connect to API: model "b33efb29-37dc-4bd8-8a68-0aa097b5e6c1" has been removed from the controller, run 'juju models' and switch to one of them.

In conclusion, it seams that then Juju is jumping back and forth between these two models, and cannot destroy any of them...
I don't know if this is an error caused by the python-libjuju or by the Juju itself, but since I am using the libjuju I am posting this error here.

The version of Juju I'm using is the 2.9.28-ubuntu-amd64 one.

[juanmanuel-tirado]

Could you please provide a reproducible set of steps? This looks like a Juju problem rather than an issue with pythonlib-juju. Said that, it would be nice to have some steps to reproduce and discriminate the source of the issue.

[oEscal]

Could you please provide a reproducible set of steps? This looks like a Juju problem rather than an issue with pythonlib-juju. Said that, it would be nice to have some steps to reproduce and discriminate the source of the issue.

Unfortunately, this was an isolated event, which I was not able to reproduce again. The most I can say is what I have already mentioned in the bug i.e., how it happened. However, if it happens again, I will try to obtain more details

[juanmanuel-tirado]

Do not hesitate to provide any steps to reproduce the incident if you experience it again. Meanwhile, I will close this issue.