There is no way of specifiying on which cluster charm should be deployed vSphere

Bug #1790185 reported by Vuk Vasic
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Low
Unassigned

Bug Description

On VMware vSphere cloud provider there is no way of defining on what cluster Juju will deploy virtual machines. For example if i have Development and Production cluster i cannot choose on which cluster will bundle be deployed on.

Zones are not same as Cluster in Vmware and should not be treated as same way.

Tim Penhey (thumper)
tags: added: vsphere-provider
Changed in juju:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Christian Muirhead (2-xtian) wrote :

Hi - can you explain how you would want Juju to behave?

It sounds like you want to be able to deploy a bundle to a specific cluster without having to specify zones in the bundle, is that right?

Would the ability to set a cluster in the model config provide what you want? Is there a situation where you would need to be able to deploy some applications to one cluster and some to another?

Revision history for this message
Vuk Vasic (vukvasic) wrote :

Hi Christian,

This is the situation. If i have VNware setup with two clusters (Development and Production) when i deploy it will put VMs on both cluster. I want a eay to specify when deploying a bundle on which Cluster it will deploy VMs. Also i tried to specify zone in each constraint but this didn't work. So i guess that implementing this option is good enough.

Revision history for this message
Camille Rodriguez (camille.rodriguez) wrote :

Is there any update on this feature? This impacts every deployment on VMWare. Being able to point to a cluster/resource pool with the "zone" is essential.

Revision history for this message
Camille Rodriguez (camille.rodriguez) wrote :

#cpe-onsite

tags: added: cpe-onsite
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!

Revision history for this message
Canonical Juju QA Bot (juju-qa-bot) wrote :

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

Changed in juju:
importance: Medium → Low
tags: added: expirebugs-bot
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.