Deploying an application to a specific node fails with invalid model UUID error
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
Critical
|
Caner Derici |
Bug Description
There seems to be a regression since Juju 3.3 where any attempt to deploy a simple application such as ubuntu charm to a specific undeployed machine from MAAS provider will result in an error.
I've deployed multiple versions of Juju controllers on the same MAAS cloud to confirm the behaviour and to check that MAAS does work correctly.
With the following cloud environment :
* Ubuntu 22.04
* MAAS 3.4.0
Works with :
* Juju 3.1.7 and 3.2.4
Fails with :
* Juju 3.3.3 and 3.4.0
Reproducer :
* Have an environment with MAAS 3.3 or 3.4
* Bootstrap a Juju controller on top of it (version 3.3 or 3.4)
* create a model
* run the following command
$ juju deploy ubuntu --base ubuntu@22.04 --to node-1
--> It fails with the following message
ERROR cannot add application "ubuntu": placement scope: invalid model UUID "model-uuid"
ERROR failed to deploy charm "ubuntu"
--> Expected outcome : The application gets deployed and the unit is properly chosen
(From Juju 3.1 and 3.2)
Located charm "ubuntu" in charm-hub, revision 24
Deploying "ubuntu" from charm-hub charm "ubuntu", revision 24 in channel stable on ubuntu@22.04/stable
It is to note that "juju add-machine node-1 --base ubuntu@22.04" still works on Juju 3.3 and 3.4
$ juju status
Model Controller Cloud/Region Version SLA Timestamp
test-migrate juju-3-4 maas_cloud/default 3.4.0 unsupported 03:30:59Z
Model "admin/
$ juju deploy ubuntu --base ubuntu@22.04 --to node-1
ERROR cannot add application "ubuntu": placement scope: invalid model UUID "model-uuid"
ERROR failed to deploy charm "ubuntu"
$ juju add-machine node-1 --base ubuntu@22.04
created machine 0
Changed in juju: | |
assignee: | nobody → Caner Derici (cderici) |
Changed in juju: | |
status: | Triaged → In Progress |
Changed in juju: | |
status: | In Progress → Fix Committed |
Changed in juju: | |
status: | Fix Committed → Fix Released |
This looks like fallout from the change to do most of the deploy processing server side.
Previously in the CLI, we would replace the "model-uuid" placeholder with the real model uuid before making the Deploy() API call. Now, when we make the new DeployFromRepos itory() API call, it appears this substitution is not done.
It looks like a regression to me. I'll mark this initially as critical pending confirmation my theory is correct (I haven't debugged / tested, just did a quick code read).