ConflictError: The extension ID xxx-PaasDiagnostics-Production-Ext-0 is already in use for this deployment

[wangzq]

Where "xxx" is the role name. Repro steps:

1. Create a new cloud service.
2. Deploy a web role to Production slot or first deploy to Staging then swap.
3. Enable diagnostics extension using Set-AzureServiceDiagnosticsExtension in Production slot.
4. Deploy to Staging slot without enabling diagnostics extension.
5. Swap, notice now the Staging has diagnostics enabled while Production doesn't have it enabled.
6. Now if I use Set-AzureServiceDiagnosticsExtension to enable it again in Production slot, I will get the error in title.

Analysis so far:
I believe it is because the cmdlet is using following code to generate the extension id, therefore it will generate the same id when I enable the extension for Production slot the second time, since the same id is actually now used by Staging slot, thus the conflict:

public string GetExtensionId(string extensionName, string slot, int index)
{
    return string.Format(ExtensionIdTemplate, PrefixName, extensionName, slot, index);
}

[wangzq]

Update: I managed to debug the code and noticed that in following code the availableId will always return the first id:

    public ExtensionConfiguration InstallExtension(ExtensionConfigurationInput context, string slot, Microsoft.WindowsAzure.Management.Compute.Models.ExtensionConfiguration extConfig)
    {
        ExtensionConfigurationBuilder builder = GetBuilder(extConfig);
        foreach (ExtensionRole r in context.Roles)
        {
            var extensionIds = (from index in Enumerable.Range(0, ExtensionIdLiveCycleCount)
                                select r.GetExtensionId(context.Type, slot, index)).ToList();

            string availableId = (from extensionId in extensionIds
                                  where !builder.ExistAny(extensionId)
                                  select extensionId).FirstOrDefault();

I checked the allRoles is always empty in my case therefore the ExistAny will always return the first id:

    public bool ExistAny(string extensionId)
    {
        return allRoles.Any(id => id == extensionId)
            || namedRoles.Any(r => Exist(r.Key, extensionId));
    }

BTW, this issue doesn't exist if I configure the extension from Visual Studio Server Explorer, since it uses different format when generating the extension id; is the Azure Tools for Visual Studio also open source?

Thanks

[ccorsano]

Hi !
I am interested in this issue being fixed as well, right now we have to cleanup the diagnostics extension and reinstall it on each deployment, which basically double our deployment time.

@wangzq I haven't got the time to test it, but isn't the core issue that this line

var extensionIds = (from index in Enumerable.Range(0, ExtensionIdLiveCycleCount)
                                select r.GetExtensionId(context.Type, slot, index)).ToList();

only checks for the target slot of the extension ?

It should check for all slots on the service, because in my case I am deploying on Staging, and the Production slot has a "Default-PaaSDiagnostics-Staging-Ext-0" extension.

Anyway, if somebody could take a look at the proper way to fix this (maybe changing the naming convention, because after swap the name doesn't make sense anymore), it would help a lot !

Thanks!

[calebdoise]

@ccorsano What steps do you take to reliably cleanup the diagnostics extension as a workaround? We ran into this same problem.
http://stackoverflow.com/questions/30230617/azure-diagnostics-extension-conflicterror-for-empty-staging-slot-azure-sdk-2-6/30263535#30263535

After the swap, the diagnostics extension is on Production (with a misleading Id). Remove-AzureServiceDiagnosticsExtension does not work with either slot if the Staging slot is empty.

I was about to try out some different workarounds when I found this bug report. I'm guessing the basic steps will be:

1. Deploy new service to staging without extension.
2. Call Remove-AzureServiceDiagnosticsExtension on both Staging and Production (just to be sure I get the right one...)
3. Then, call Set-AzureServiceDiagnosticsExtension on Staging.
4. Proceed with normal method of swapping into production.

Edit:
The above steps don't actually work because it looks like I can't remove the diagnostics extension at all until the production deployment has been swapped back into the staging deployment. So, essentially, I guess I'll just have to wait until I've moved the staging deployment into production and then enable the diagnostics only after it is active in production.

[ccorsano]

@calebdoise So, I had a few tries on this, and my current solution is, including dealing with ReservedIP issues is:

• Deploy on Staging (with a staging specific ReservedIP if you have one set for Production)
• Configure PaaSDiagnostics on Staging
• Test / sanity check staging
• Remove all extensions from staging and production
• Swap
• Reconfigure production with correct ReservedIP (so that production has a coherent configuration and reconfiguring extensions does not throw errors)
• Configure PaaSDiagnostics on Production

I don't know when I'll get time to see if the fix resolves my issues, the ReservedIP problem might make me stick a little longer with my workaround.

[maartenba]

Is there an ETA when this fix will be released?