addpool on windows always uses VMNamePrefix s00

[giskou]

Describe the bug

Adding a windows pool with addpool will always use s00 as a prefix which might overlap with existing pools.

Steps To Reproduce

1. Create a cluster with a windows pool (note that the initial pool might have a s01 prefix when added)
2. Add a new windows pool with addpool (this will get a s00 prefix)
3. try to add another windows pool. (this will use s00 as prefix again and deployment will fail with conflict errors from the existing resources)

Expected behavior
addpool should see which pools are present and try to find a prefix that is available.

AKS Engine version
v0.71.0
v0.73.0
v0.75.3

Kubernetes version
all available

Additional context
As a workaround, I ended up downloading the arm template from the Azure Stack Hub portal, update the secrets, change the VMNamePrefix to something that is available and redeploy the template manually.
I am a bit scared that this will cause issues with a future scale operation.
Prefixes on widows pools have been a mess.

[jadarsie]

@giskou Please validate this fix on your side as well.

I ended up downloading the arm template from the Azure Stack Hub portal ...

Check command aks-engine-azurestack generate

I am a bit scared that this will cause issues with a future scale operation.

Please validate the fix does not break scale, we do not have coverage for addpool and I do not that happening any time soon.

[giskou]

Hey,
@jadarsie where is this released? Is there a binary somewhere I can test with?
Or is this going to be a new patch release soon?

[jadarsie]

No plans to release soon, v0.76 just came out, I meant you could build from source.