Needless brute forcing with finding AZ in space topology in the provisioner task
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Medium
|
Unassigned |
Bug Description
When attempting to locate an AZ in the space topology for machine placement, we do unnecessary brute forcing during the provisioning.
For example, assume that we're launching in eu-west-1:
juju bootstrap aws aws-test
juju add-space space-1 172.31.32.0/20
juju deploy cs:percona-
The bootstrap instance will be in eu-west-1a, the space-1 will be in eu-west-1b. During the deployment it will attempt to create an instance in eu-west-1a, fail because it can't find the correct corresponding subnet and then move to eu-west-1b.
The thing is, the machine space topology from provisioning info will tell you that there is only ever going to be one subnet available to that instance and that's in eu-west-1b. The availability zone in provisioning task ignores that key information and returns eu-west-1a.
Instead we should make the provisioner task smarter, so it inspects that information and tell us that there can only be ever one possible outcome for this and just recommend that zone.
If that failed it could go back to looping through the AZs like it does now, to keep backwards compatibility: eu-west-1b, eu-west-1a, etc
Changed in juju: | |
milestone: | 2.8.1 → none |
milestone: | none → 2.8-next |
Changed in juju: | |
importance: | Undecided → Medium |
Changed in juju: | |
milestone: | 2.8-next → 3.0.0 |
Changed in juju: | |
milestone: | 3.0.0 → 3.0.1 |
Changed in juju: | |
milestone: | 3.0.1 → 3.0.2 |
Changed in juju: | |
milestone: | 3.0.2 → 3.0.3 |
Changed in juju: | |
milestone: | 3.0.3 → 3.0.4 |
Changed in juju: | |
assignee: | Simon Richardson (simonrichardson) → nobody |
Close if proceeds.