Azure-sdk-for-python: Azure virtual machine statuses using the API or Python SDK

[prashanthmadi]

When querying Azure virtual machine statuses using the API or Python SDK through the compute client (i.e. compute_client.virtual_machines.instance_view(resource_group_name, vm_name)), it is possible for the virtual machine instance view to omit the virtual machine operating status. This frequently occurs when the virtual machine is changing state, e.g. deallocated->starting. This is assumed to occur as the virtual machine is unreachable.

This is undesirable as it requires logic to be built downstream to accomodate an inconsistent number of arguments, e.g.

instance_view = self.client_compute.virtual_machines.instance_view(
    resource_group_name=self.resource_group_name,
    vm_name=vm_name)

try:
    status_operating = instance_view.statuses[1]
    status_code_operating = status_operating.code
except IndexError:
    logging.error('Azure failed to return operating status')
    status_code_operating= 'Unknown'

[lmazuel]

I have no reason to believe there is a contract from Compute VM team to ensure this array is not empty. Being that it’s “instanceView”, if you come back from a deallocation, that could even makes sense (deallocated VM have no instance by design).

It’s perfectly normal to get an IndexError is you try to access an array that is empty. That’s not an error in the SDK, but in the code calling the SDK

If you want robust code, you can write:

status_code_operating = ",".join([s.code for s in instance_view.statuses]) or 'Unknown'

[dejeroWilliamScott]

Greetings! I am the original ticket owner and I will clarify my request in line.

I am not satisfied with this response because this response implies that consumers are responsible for interpreting partial or incomplete Azure responses. I hope this is not the case and that Azure is continuously improving their services instead of passing this responsibility downstream.

I have no reason to believe there is a contract from Compute VM team to ensure this array is not empty.

I don't know what this means. I think it is a reasonable expectation that the Compute VM team is responsible for reporting the status of compute resources I'm leasing from Azure.

Being that it’s “instanceView”, if you come back from a deallocation, that could even makes sense (deallocated VM have no instance by design).

Deallocated VMs have a state or 'instance' as returned by instance_view, i.e. 'ProvisioningState/succeeded', 'PowerState/deallocated'.

It’s perfectly normal to get an IndexError is you try to access an array that is empty. That’s not an error in the SDK, but in the code calling the SDK.

Yes it is normal to receive an error when accessing an empty array, the complaint is the array is empty.

If you want robust code, you can write:
status_code_operating = ",".join([s.code for s in instance_view.statuses]) or 'Unknown'

I've already implemented similar logic as a workaround solution to this problem prior to contacting Azure. This is a poor solution, because it requires every API consumer to write their own logic for something that should be upstream (i.e. the API should report an operating state).

To clarify, I'm not suggesting this be fixed within the Python SDK. This issue originates from the Azure RESTAPI and should be fixed there instead of pushing the fix downstream to the Azure Python SDK, Azure Ruby SDK, or any other API consumer.

[huangpf]

@dejeroWilliamScott Just FYI, multiple teams are now doing triage on this reported issue again. Will try to get back to you soon. Thanks.

[changov]

Hi dejero,
I work on the Computer Resource Provider. Your expectations are generally right. From inspection of the code, I think there will always be at least the ProvisioningState entry in the statuses array (e.g. "code": "ProvisioningState/updating"). However, the PowerState and VM extension statuses may be missing, if CRP does not manage to get the current status quickly from the respective infrastructure source.
If you have a case of empty statuses array, we'll have to debug. Please open a support case with all the details you can gather. Most useful would be the VM resource id, region, time range, and any API raw response captured.

[prashanthmadi]

@dejeroWilliamScott , @changov is looking for below info
Request id and/or timestamp and VM resource id needed to debug.

[dejeroWilliamScott]

@changov This matches my experience. I have not encountered a missing provisioning state in the statuses array. I can seemingly reproduce it on any Linux VM, although I have not attempted to reproduce it on Windows VMs. I've updated the original support request (118091218991225) with a VM which can be used to reproduce the symptoms. The ticket itself complains regarding the API response, therefore I am providing it here.

Raw API response;

{
  "disks": [
    {
      "name": "sqa03_OsDisk_1_7856cf9678c5485ebaf9497890fbc9eb",
      "statuses": [
        {
          "code": "ProvisioningState/succeeded",
          "level": "Info",
          "displayStatus": "Provisioning succeeded",
          "time": "2018-10-18T16:12:46.4658527+00:00"
        }
      ]
    }
  ],
  "statuses": [
    {
      "code": "ProvisioningState/updating",
      "level": "Info",
      "displayStatus": "Updating"
    }
  ]
}

Expected response is of the form,

{
  "disks": [
    {
      "name": "sqa03_OsDisk_1_7856cf9678c5485ebaf9497890fbc9eb",
      "statuses": [
        {
          "code": "ProvisioningState/succeeded",
          "level": "Info",
          "displayStatus": "Provisioning succeeded",
          "time": "2018-10-18T16:12:46.4658527+00:00"
        }
      ]
    }
  ],
  "statuses": [
    {
      "code": "ProvisioningState/succeeded",
      "level": "Info",
      "displayStatus": "Provisioning succeeded",
      "time": "2018-10-18T16:12:46.4815653+00:00"
    },
    {
      "code": "PowerState/deallocated",
      "level": "Info",
      "displayStatus": "VM deallocated"
    }
  ]
}