Azure Provisioning Form: default "Use managed disks" based on existing node pools to avoid availability set mismatch

[jferrazbr]

Is your feature request related to a problem? Please describe.
When editing an existing Azure cluster that was created with unmanaged disks, the node pool form in the UI still defaults "Use managed disks" to true when adding a new node pool.

If the cluster uses an availability set with unmanaged disks, Azure does not allow mixing managed and unmanaged disks in the same availability set, and node creation can fail with an error like:

error creating machine: error in driver during machine creation: cannot convert non-managed availability set jferraz-test-as to managed availability set

Describe the solution you'd like
When updating or editing an existing Azure cluster, the default value of "Use managed disks" in the node pool form should match the current cluster / node pool configuration.

For example:

• If the existing node pool(s) are using unmanaged disks, then when the user clicks "Add node pool", the "Use managed disks" option should default to false.
• If the existing node pool(s) are using managed disks, then the option can stay true by default.

This will help avoid mixing disk types inside the same availability set and prevent node creation errors.

Additional context
This is a follow up to #16184, which changed the default to use managed disks.

The issue appears when:

1. A cluster is created on Azure using an availability set with unmanaged disks.
2. Later, in the UI, the user clicks "Add node pool" for this cluster.
3. The "Use managed disks" option is true by default and the user keeps this value.
4. Node creation fails with the error about converting a non-managed availability set to a managed availability set.

[rak-phillip]

@jferrazbr I added some additional validation to assert that the value for managed disks is consistent across all pools. There's a video attached to #16306 to demonstrate the updated behavior. Can you confirm that this looks correct?

[jferrazbr]

Thanks @rak-phillip, I've checked the video and LGTM 💯

[eva-vashkevich]

Hi @jferrazbr does it only apply to to nodes in the same availability set?
For example, should it be possible to have

• managed in a pool with availability set A and unmanaged in a pool with set B? (worked in my env)
• a cluster with a pool with unmanaged availability set and a pool with availability zone? (didn't work but may be unrelated)

Screen.Recording.2026-01-08.at.4.54.00.PM.mov

[jferrazbr]

Hi @eva-vashkevich, my original goal was only to keep the same default value as before for already existing clusters, so updates don’t unexpectedly flip from unmanaged -> managed and then fail (especially when Availability Sets are involved, since Azure can’t mix managed/unmanaged disks inside the same Availability Set).

Now that you mentioned the different combinations (managed vs unmanaged across different Availability Sets, and pools using Availability Zones), I agree that we should align on the expected behavior first to not push this in the wrong direction.

I'll discuss this with my team and come back with a clearer proposal. In the meantime, I'll ask @rak-phillip to hold off on merging the PR for now, until we confirm the correct default logic for these scenarios. Sorry for missing this during the issue creation.

[snasovich]

@rak-phillip @eva-vashkevich (cc @jferrazbr who I discussed it with)
I'd like to suggest we reconsider this approach based on Azure's deprecation timeline for unmanaged disks.

According to Microsoft's official documentation:

After March 31, 2026, you can't start IaaS VMs that use unmanaged disks. Any VMs that use unmanaged disks and are running or allocated will be stopped and deallocated.

Given that the v2.14.0 release is scheduled for late March 2026, implementing support for dynamically defaulting to unmanaged disks would provide essentially no value to users - by the time they're using v2.14.0, Azure will have already deprecated unmanaged disks entirely.

Additionally from the same announcement:

we announced the retirement for unmanaged disks on September 13, 2022. Unmanaged disks will be fully retired on March 31, 2026 (extended from previously published date of September 30, 2025).

So Azure users had ample time to migrate to managed disks and original deadline was in September 2025.

Suggestions:

1. Don't implement the dynamic true/false defaulting for "Use managed disks" - the effort wouldn't be worthwhile given the deprecation deadline aligns with our release timing.

2. Remove "(unmanaged)" from the "Availability Set (unmanaged)" label - Since unmanaged disks are being deprecated, we should simplify this to just "Availability Set" to avoid confusion and references to a soon-to-be-obsolete feature.

3. Consider adding a deprecation warning - If users are still on older clusters with unmanaged disks, we could potentially show a warning directing them to migrate to managed disks before the Azure deadline. But given the timeline noted earlier in this message it's unlikely to help a lot of users.

[eva-vashkevich]

Hi @snasovich, this might be a question for UX, but should we be showing this checkbox on Create at all in this case? It sound like provisioning new instances with unmanaged disks will be unsupported by Azure, so we shouldn't allow it either?

[snasovich]

@eva-vashkevich , I'd approach it cautiously just in case there are weird corner case configurations like some sort of "private Azure deployment" that still allows unmanaged disks for some reason. So keeping the checkbox there but changing its default to checked is IMO safer option.