Azure provider attempts to deploy with unsupported "D1" RoleSize

[Aaron Bentley]

As of revision a1b54741, juju attempts to use the D1 RoleSize, which is not supported:

2014-12-02 11:37:29 ERROR juju.cmd supercommand.go:323 failed to bootstrap environment: cannot start bootstrap instance: POST request failed: BadRequest - Value 'D1' specified for parameter 'RoleSize' is invalid. Allowed values are 'ExtraSmall,Small,Medium,Large,ExtraLarge,A5,A6,A7,A8,A9,Basic_A0,Basic_A1,Basic_A2,Basic_A3,Basic_A4,Standard_D1,Standard_D2,Standard_D3,Standard_D4,Standard_D11,Standard_D12,Standard_D13,Standard_D14'. (http code 400: Bad Request)

Juju 1.20.10 does not error this way, therefore this is a regression.

Deploy with a1b54741:
http://juju-ci.vapour.ws:8080/job/azure-deploy-precise-amd64/2725/console

Deploy with 1.20.1:
http://juju-ci.vapour.ws:8080/job/azure-upgrade-precise-amd64/3197/console

[Dimiter Naydenov (dimitern)]

The correct fix seems to be renaming "D*" role sizes in gwacl to "Standard_D*", updating pricing/disk sizes/etc. attributes of all D* role sizes (if needed; while at it), and finally updating dependencies.tsv in juju-core to use the updated gwacl.

I started working on the fix described above, but it's getting late and I wasted 2h trying to setup an azure account so I can test the fix. If the fix can't wait until tomorrow, I'm sure Andrew Wilkins can take it over easily. If it's not that urgent I'll propose a fix tomorrow.

Because the fix is in gwacl itself, we can backport it to 1.21/1.20 if needed (to take advantage of the new D* instance types).

[Andrew Wilkins (axwalk)]

I fixed gwacl, but there's still an issue. I now get:

ERROR failed to bootstrap environment: cannot start bootstrap instance: asynchronous operation failed: Compute.OverconstrainedAllocationRequest - The VM size (or combination of VM sizes) required by this deployment cannot be provisioned due to deployment request constraints. If possible, try relaxing constraints such as virtual network bindings, deploying to a hosted service with no other deployment in it and to a different affinity group or with no affinity group, or try deploying to a different region. (http code 403: Forbidden)

Looking into it.

[Andrew Wilkins (axwalk)]

Looks like it's to do with virtual networks being tied to affinity groups. I left a comment a while ago about not using Location when creating virtual networks:

// Note: the Azure documentation recommends to use
// Location when creating virtual network sites.
// We have historically used Affinity Group, and
// have observed intermittent issues when switching.
// http://msdn.microsoft.com/en-us/library/azure/jj157100.aspx

It would seem there's a guaranteed failure for D-series instances when using AG, so I'll switch it over again. It could have been that there were problems in the transitional period.

One problem that we'll have is that existing environments will not be able to provision D-series machines. We'll have to filter them out if the vnet has an affinity group.

[Andrew Wilkins (axwalk)]

... and now I'm finding that some locations don't have all the role sizes. More changes required.

[Andrew Wilkins (axwalk)]

http://reviews.vapour.ws/r/576/

[Andrew Wilkins (axwalk)]

Because of the way we've been setting up virtual networks, we cannot reliably create D-series VMs in existing environments. I've changed how we create virtual networks so that it works reliably going forward. For this reason, D-series (and above) will only be available in new environments.