In Juju 2.5-beta2, if I add a model and then destroy it I sometimes see the warning "cannot remove unknown model from cache: model E:admin/m not found"
It seems like a race where the client tries to get info from the controller after the model has gone - sometimes it's still there so the warning doesn't happen.
Debug logging below:
xtian@marathe:~$ juju add-model m
Added 'm' model on localhost/localhost with credential 'localhost' for user 'admin'
xtian@marathe:~$ juju destroy-model m -y --debug
11:16:49 INFO juju.cmd supercommand.go:56 running juju [2.5-beta2 gc go1.11.2]
11:16:49 DEBUG juju.cmd supercommand.go:57 args: []string{"juju", "destroy-model", "m", "-y", "--debug"}
11:16:49 INFO juju.juju api.go:67 connecting to API addresses: [10.62.129.82:17070]
11:16:49 DEBUG juju.api apiclient.go:883 successfully dialed "wss://10.62.129.82:17070/api"
11:16:49 INFO juju.api apiclient.go:603 connection established to "wss://10.62.129.82:17070/api"
11:16:49 INFO juju.juju api.go:67 connecting to API addresses: [10.62.129.82:17070]
11:16:49 DEBUG juju.api apiclient.go:883 successfully dialed "wss://10.62.129.82:17070/model/a6c57475-d552-404d-8727-ea788c805a9e/api"
11:16:49 INFO juju.api apiclient.go:603 connection established to "wss://10.62.129.82:17070/model/a6c57475-d552-404d-8727-ea788c805a9e/api"
11:16:49 INFO cmd destroy.go:277 Destroying model
11:16:50 INFO cmd destroy.go:295 Waiting on model to be removed...
11:16:52 INFO cmd destroy.go:356 Model destroyed.
11:16:52 WARN juju.cmd.modelcmd base.go:174 cannot remove unknown model from cache: model E:admin/m not found
11:16:52 DEBUG juju.api monitor.go:35 RPC connection died
11:16:52 DEBUG juju.api monitor.go:35 RPC connection died
11:16:52 INFO cmd supercommand.go:465 command finished
I could not reproduce this at all... not on lxd provider not on aws...
However, just by examining the code, it looks like we are indeed throwing a NotFound error when we get a request to remove a model from cache that is not in the cache.
We can treat this situation as a no-op and not throw an error... But at this stage, I ma not too sure what the implications are for other usages of this API.
So the fix is for us to ignore NotFound errors @ https:/