Comment 8 for bug 2020871

It looks like there's approx 3 different code paths in play here, and I'm not sure they're all consistent.

Originally, when storage was added to juju, there was an underlying constraint that the machine AZ must match the volume AZ, or else attachment of said volume to machine would not be possible. I think this very much was driven by an AWS requirement.

There's various places in the code that enforce the above constraint. As already noted in this bug, it is checked at deploy time. It is also checked if a placement directive is used, eg

juju deploy blah --to zone:foo

does validation on the zone placement which might return an error formatted as

"cannot create instance in zone %q, as this will prevent attaching the requested disks in zone %q"

And yet also as noted, using --attach-storage does not do the placement check.

As noted by Haw, it seems code was added to Openstack provider to specifically handle the (Openstack specific) case where the default volume zone "nova" is used, and strict AZ matches with machine are skipped. But there's been several changes to the provisioner worker since then, eg to deploy machines in parallel.

Looks like we need to revisit the logic here and consistently add a provider specific AZ check in all provisioning workflows.