azure arm instance-ids are not ids, cannot find machine in azure

[Curtis Hovey]

azure arm instance-ids are not ids, the are vm names in a resource group. Users cannot find machine in azure without first finding the resource group, then looking for the vm name. 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".

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. 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.

[Andrew Wilkins (axwalk)]

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.

[Aaron Bentley (abentley)]

You should not change it merely to make CI easier, you should change it because it violates expectations. All instance ids so far identify the object within the substrate with no other context required. They are all ugly already.

If you want pretty status output, hide the instance-id field from the default output. You can put "instance-name" instead, and that can be as pretty as you like.

[Andrew Wilkins (axwalk)]

The thing is, I don't hold the same expectation, and I can only assume that nobody else does, since this is the first time I've heard any complaint. However, I can see value in being able to identify the resource group from the instance ID.

For LXD and MAAS we're now including the last 5 or so characters of the model UUID in the instance ID. This should be sufficient to identify the resource group in Azure too, so I think we'll do the same thing there.

P.S. Re "They are all ugly already." -- this is something we're actively trying to fix for 2.0, hence my initial push back.

[Cheryl Jennings (cherylj)]

FWIW, I agree with Aaron that inst-id would be the actual unique identifier generated by the provider so that you could go to your dashboard and be able to look up that instance based on that ID.

The lxd case is special since juju is generating those IDs. I thought for MAAS we were going to be using the host name as the instance ID?

[Anastasia (anastasia-macmood)]

This falls into the category of improvements or technical debt as identifying machines uniquely is provided and is well described in comment # 1.

Identifying the resource group from the instance ID is a a smaller component of this improvement.

I am marking this bug as tech-debt item, lowering its priority and removing 2.1 milestone as we will not be addressing this issue in 2.1.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.