Comment 1 for bug 1586089

Sorry, but I don't think we're going to change this just to make CI a bit easier. That is to say, we shouldn't be changing UX just to simplify CI (unless simplifying CI makes for a *better* UX). I'm open to changing this if there's a wider impact, but I'm not convinced there is yet.

It's important to be able to navigate to the instance in the console; it's possible to do that now by mapping model name -> resource group, and then instance ID -> VM. There's no guarantee that instance IDs are *directly* globally unique.

> azure arm instance-ids are not ids, the are vm names in a resource group.

Maybe you mean they're not *globally unique* IDs, but they are of course IDs.
</pedantry>

> Users cannot find machine in azure without first finding the resource group, then looking for the vm name.

This is just how things work in Azure. All resources are scoped to a resource group. The ID of a VM in Azure *is* its name; that name just isn't unique to the account, it's unique to the resource group.

We could prefix the VM name with the resource group name, but that's going to blow out the instance ID length. That's going to make "juju status" look ugly.

> Resource group names are also not predicable. Juju appends the model uuid to the model name to create the resource group. I can have multiple resource groups that start with the same model name and each group has a machines named "machine-0".

They're not predictable *before* bootstrap / creating a model, but that's because you have to have unique resource group names, which is why we include the model UUID. But after you've bootstrapped / created the model, you can predictably derive the resource group name from the model UUID and model name.

> CI uses the instance-id provided by juju status to identify the machine that needs instrumentation. This is true for aws, gce, openstack, maas, and lxd. Only azure does not have a unique id.

Azure ARM has a different model to all of the others.

> The only way to learn the machine's id is to use a third party library to search the azure account for a probable match.

As above, if you know the model UUID and model name (both of which you have at the client side) you can derive the resource group name. This is not probabilistic, it is exact.

Say we did include the resource group name in the instance ID; what would you do with it? Presumably you would split it apart, then look up the VM relative to the resource group. That's *already* Azure-specific. So ISTM that looking up the resource group from the model UUID/name is not a big task.