Update-AzureRmServiceFabricDurability fails when NodeType differs from VMSS name

[John-Garland]

Cmdlet(s)

Update-AzureRmServiceFabricDurability

PowerShell Version

5.1.14393.1480 (from Azure Portal PowerShell shell)

Module Version

???

OS Version

10.0.14393.1480 (from Azure Portal PowerShell shell)

Description

The command assumes that VMSS name and Node Type must be matched for Service Fabric - they do not have to match, and can differ if a custom template is used.

Script/Steps for Reproduction

Create a SF Cluster where the VMSS name differs from the NodeType name. Attempt to run the command, passing it either name. The code in UpdateAzureRmServiceFabricDurability.cs line 68 calls GetVmss with the Node Type name. Within that call, it fails if it cannot locate a VMSS with that name. Later, in lines 71-74, an attempt is made to locate the NodeType with the matching name - if that isn't found, an error is thrown.

Suggested fix is to add an optional "VMSSName" parameter and change the call on line 68 to GetVmss(this.VMSSName ?? this.NodeType). This should result in extending the functionality without introducing a breaking change. Also please look at other NodeType-related command lets fro the same behavior.

[cormacpayne]

@QingChenmsft Hey Ching, would you mind taking a look at this issue?

[QingChenmsft]

Vaishanv and Justin will help take a look, they are the owners now, i am not .

[John-Garland]

Has anyone followed up on this? It's been 4 months, and it seems there was an assignment followed by an un-assignment, but nothing else. Obviously I worked around it months ago, but that doesn't change the fact that the script is still broken.

[juhacket]

We are fixing this issue in our next update.

[juhacket]

It was decided that this issue would not be fixed at this time because it requires changes across several cmdlets. The supported way to perform this type of update is to use an ARM template deployment.

[John-Garland]

Even though I worked around this issue months ago when it was initially reported, I'm disappointed by the decision - the cmdlet functions incorrectly - period, regardless of how many/few people need the actual functionality. The fix can be isolated to adding a parameter so that existing functionality is retained intact. At a minimum, please be sure to update the documentation to state the cmdlet's limited functionality (the fact that the supported way to work with this supported configuration is to not use the cmdlets) , and point users to an example of how the proper functionality can be achieved by other means.

[vaishnavk]

@dotnetgator - Thank you for the feedback. We take feedback from all customers seriously. We understand the limited functionality the PowerShell cmdlet provides and we are constantly working on improving it. The decision was to work on few high priority work items immediately and work on PS cmdlet improvements in the next semester. We will update the documentation to explicitly call out that the VMSS resource name and node type name has to match.