| 2019-10-24 02:32:15 |
Christian Muirhead |
description |
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 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? |
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? |
|
