[bug] The resource 'mq-instance' already exists in extended location 'CustomLocation'
rido-min opened this issue · 5 comments
Describe the bug
Deploying AIO following this doc
https://learn.microsoft.com/en-us/azure/iot-operations/deploy-iot-ops/howto-deploy-iot-operations?tabs=portal
To Reproduce
I was able to deploy 1 cluster, however when I try to deploy the second one, in the same Subscription/Resource group, I got this error:
(InvalidExtendedLocation) The resource 'mq-instance' already exists in extended location 'CustomLocation':
Wondering if are there any known workarounds to deploy more that one instance in the same resource group.
Try deploying with CLI instead of Portal to gather a data point. CLI should account for this.
I tried using a different name "mq-instance-desktop" but then received this error later on:
The resource '/subscriptions/edb3848d-d2de-4aa9-89f4-c60ee8cadf79/resourceGroups/aio-test/providers/Microsoft.IoTOperationsMQ/mq/mq-instance-desktop/broker/broker' has a conflicting name which is already taken for the extended location '/subscriptions/edb3848d-d2de-4aa9-89f4-c60ee8cadf79/resourceGroups/aio-test/providers/Microsoft.ExtendedLocation/customLocations/aio-desktop-cl'. Please pick a different name or extended location for the resource. (Code: InvalidResourceName)
I have seen that most (if not all) resources cannot have the same name if they exist in the same resource group OR extended location. This means that you cannot have mq-instance-desktop twice in one resource group (even if they are in different extended locations) and you cannot have mq-instance-desktop twice in the same extended location (even if they are in different resource groups).
This is a service limitation - @digimaun we can add in a check to see if the name is used within the rg and extended location before these deployment calls to avoid users having to wait for the service to return this error message.
In 0.2.0b4 init adds a pre-flight check which should uncover these issues prior to a real deployment. I also find the service error is clear on remediation.
As these are service limitations, we could point users to relevant documentation.
IoT Ops has gone through a number of evolutions since this issue was made. init default options should cover this. Also, Portal improvements to default values to reduce name collisions like this.