Tested with 2.7-beta1 against aws and vsphere, but from reading the code it seems like this applies to any other provider with availability zones.
Bootstrapping with --bootstrap-constraints zones=some-zone silently ignores the constraint and creates the controller VM in the first availability zone.
Looking into the code there's a point in provider/common/bootstrap.go:startInstanceZones where the constraints are passed into the provider's DeriveAvailabilityZones function, but none of the implementations consider constraints, they only look at placement (ie the --to option).
The workaround for this is to use --to, which in this case doesn't have the negative that it usually would (where subsequent add-unit calls won't also create machines in the right AZ). Although maybe it should be used when enable-ha is run?
Having the same issue while bootstraping juju controller for k8s model on top of Openstack cloud.
Juju version 2.7.2
Same flavor openstack server create to the same zone, I get success rate 5/5 (server created in z2): bionic- cloudimg --flavor m1.large --availability-zone z2 --network ext_net z222
openstack server create --image ubuntu-
However trying to bootstrap to this zone gets me controller in zone3 (constant).
juju bootstrap --bootstrap- constraints zones=z2 --model-default /home/ubuntu/ alex/deployment /generated/ juju_openstack_ controller/ model_defaults. yaml --metadata-source /home/ubuntu/ alex/deployment /generated/ juju_openstack_ controller/ images openstack_cloud foundation- openstack
After disabling all hypervisors in zone3, the same bootstrap command gets me controller in zone2 no problem.
After enabling back the hypervisor in zone3, the controller goes there again, so looks like it doesn't notice the constraint at all.