空的暂存插槽的Azure诊断扩展ConflictError（Azure SDK 2.6）

Question

I am deploying an Azure cloud service deployment to an empty Staging slot with New-AzureDeployment in PowerShell along with an extension configuration for diagnostics created via New-AzureServiceDiagnosticsExtensionConfig.

When I swap that to production and call:

Get-AzureServiceDiagnosticsExtension -ServiceName "my-service-name-here" -Slot Production

The "Id" property comes back as "MyRole-PaaSDiagnostics-Staging-Ext-0". Note that it still says "Staging".

Now, if I try to do a new deployment to staging I get an error that says:

New-AzureDeployment : ConflictError: The extension ID MyRole-PaaSDiagnostics-Staging-Ext-0 is already in use for this deployment.

This seems broken since there is nothing deployed to staging at the time. The only way I can deploy a new cloud service to "Staging" with a diagnostics extension is if I first delete the diagnostics extension from "Production" with Remove-AzureServiceDiagnosticsExtension.

Is this a bug or any thoughts on what I might be doing wrong? I didn't see an option that would let me specify an alternate Id for the extension.

Update

This definitely feels like a bug to me. If I do:

Get-AzureServiceDiagnosticsExtension -ServiceName "my-service" -Slot Production

I get back the extension with the staging Id. If I do the following:

Remove-AzureServiceDiagnosticsExtension -ServiceName "my-service" -Slot Production

I get back (NOTE: The extension was deployed into staging originally and then I swapped it into production):

WARNING: No existing Microsoft.Azure.Diagnostics.PaaSDiagnostics extensions enabled on given roles.

If I do the following:

Remove-AzureServiceDiagnosticsExtension -ServiceName "my-service" -Slot Staging

I get back:

Remove-AzureServiceDiagnosticsExtension : Deployment not found in service: my-service and slot: Staging.

So, it actually appears that I have zero means of removing the diagnostics extension without first deploying something new into the slot.

Answer 1

Turns out this is a reported bug on the github azure-powershell project: https://github.com/Azure/azure-powershell/issues/193

and looks like someone already submitted a potential fix too.