Deploying an application to a specific node fails with invalid model UUID error

[DUFOUR Olivier]

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/test-migrate" is empty.

$ 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

[Ian Booth (wallyworld)]

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 DeployFromRepository() 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).

[Heather Lanigan (hmlanigan)]

This does work for an AWS cloud and creating a container, may be specific to MAAS.

$ juju deploy ubuntu --to lxd --base ubuntu@22.04 ubuntu-base
Deployed "ubuntu-base" from charm-hub charm "ubuntu", revision 24 in channel stable on ubuntu@22.04/stable

[Heather Lanigan (hmlanigan)]

It's very ugly that this change from "model-uuid" to an actual one is hidden in the client. This led to it being missed.

 https://github.com/juju/juju/blob/67d89ab27eb0af6d5dcc53b26345fd32e495f10b/cmd/juju/application/deploy.go#L88-L93

[Caner Derici (cderici)]

Fix is up and under review https://github.com/juju/juju/pull/17024

Will update the status when it lands.