Bootstrapping with bootstrap-constraints doesn't apply zones constraint

[Christian Muirhead]

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?

[Alexander Litvinov (alitvinov)]

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):
openstack server create --image ubuntu-bionic-cloudimg --flavor m1.large --availability-zone z2 --network ext_net z222

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.

[Camille Rodriguez (camille.rodriguez)]

The only way I found to force juju to deploy the controllers in HA to the correct vSphere zone is to apply bootstrap-constraints AND extra options --to zone: X.

Here is how I modeled it in a yaml file for a deployment with FCE.

layers:
- name: juju_vsphere_controller
  type: juju_vsphere_controller
  config:
    ha: 3
    cloud_name: vsphere
    cloud_yaml: config/cloud.yaml
    credentials_yaml: config/credentials.yaml
    controller_name: foundation_vsphere
    extra_options:
      to: zone=Cluster/ResourcePoolParent/ResourcePoolChild
      bootstrap-constraints: "zones=Cluster/ResourcePoolParent/ResourcePoolChild"
    model_defaults:
      cloudinit-userdata: |
        timezone: "America/Detroit"
      primary-network: vm-network-xxxx
      root-disk-source: HX_Datastore_xx
      datastore: HX_Datastore_xx
      juju-no-proxy: 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
      automatically-retry-hooks: false

Any other try, either with only the "to zone" or with the "bootstrap-constraints" alone did not successfully deploy the 3 HA juju controllers to the right resource pool in vsphere.

[Harry Pidcock (hpidcock)]

Cloud this have been related to these bugs?
https://bugs.launchpad.net/juju/+bug/1819365
https://bugs.launchpad.net/juju/+bug/1860083

[Camille Rodriguez (camille.rodriguez)]

The problem in my situation is not that it would not find a zone, but that it would deploy in a random zone without respecting the constraint.

[Harry Pidcock (hpidcock)]

https://github.com/juju/juju/pull/11515