Comment 5 for bug 1790185

Revision history for this message
Christian Muirhead (2-xtian) wrote :

I think the original bug here is resolved - the vsphere provider supports the zones constraint, and that can be used to specify a particular cluster or any resource pool inside the cluster.

From what I understand of your problem Camille, you can deploy things with the `--to zone=resource-pool` placement directive but not by constraint `--constraints zones=resource-pool`? Is that right? It's surprising because the code to find the destination resource pool is the same whether it's specified via placement or constraint. We don't support the zone placement directive in bundles because it's too inflexible/error prone - with a constraint any new units added after the bundle is deployed will also be deployed according to the constraint but with a placement directive it would need to be specified again.

To work out why the constraint isn't working for you, can you please collect the controller machine log (/var/log/juju/machine-<n>.log) and the model log for the model you're deploying the application in (/var/log/juju/models/<user>-<model-name>-<model-uuid>.log) while the deploy is happening? (If the controller is HA get the logs from all machines.) I'm expecting to see the provisioner trying to create the machine and specifying the availability zone (= resource pool in vsphere). Then we should see the vsphere provider (the logger is still called juju.provider.vmware) trying to create the VM and hitting some kind of error. If you can't see anything from those loggers, set the following model config:

juju model-config -m controller logging-config="<root>=DEBUG;juju.provider.vmware=TRACE"
juju model-config logging-config="<root>=DEBUG;juju.worker.provisioner=TRACE"

Thanks!