Update Azure dependencies - Part III (Blob and container)

[FabioRosado]

Hello @nuwang I got a new dev account for Azure and I am testing things again. Thank you for merging the previous PR, it seems that the PR has less failing tests than when I run locally which is good.

I'll add some comments to this PR and I will try to test a bunch of other stuff to see if we can get Azure updated and working again. Thank you for the patience with this!

Also happy hacktoberfest!

[FabioRosado]

Thanks for continuing to hack away at this. Changes look good. Happy hacktoberfest! Let me know if you want to merge these changes and trigger the integration tests.

That's great! Thank you so much for pointing this to me, I'll add the prefix to this PR. I think something funky is happening with uploading to a blob, the tests failed with a permissions error both on #276 and locally. Not sure if this is actually a permissions error, we changed the permissions in our dev accounts. But I find it suspicious that its failing in both places :smile:

[FabioRosado]

Apologies for another ping @nuwang, I've figure out the issue with resources not being found in Azure. For example I created a disk called "test-volume", but when I did provider.storage.volumes.get("test-volume") Azure returned a Not Found error.

But when I pass the full name ("test-volume-4dc58f") it works. I believe this was a recent-ish change in Cloudbridge where we are adding a random(?) string to the name of the resources.

Is there a way to get this random string at the end of the resource somehow? If not we could try running disks.list and then iterate over them and return the disk with the id :thinking:

--UPDATE--

From the tests it seems that what is left to do is the fetching volume and then the compute failures

[nuwang]

@FabioRosado The reason for adding the random id is because unlike AWS and OpenStack, Azure and GCP do not generate unique resource IDs when you create objects, and instead use the name specified by the user as the resource identifier. This creates compatibility problems between providers because when you create a volume for example, you must give it a unique name, whereas in AWS and OpenStack, a unique name is never guaranteed. The design rationale for this is documented here.

The solution to this was to append a random uuid at the end, so that vol = vol_service.create(label="test") always returns a unique resource id. The id property in the returned volume contains the actual underlying volume id. So doing something like this should work:

  vol = vol_service.create(label="myvol")
  vol_service.delete(vol.id)

If you want to find a volume by user specified name, then the find method comes in handy:

matching_vols = vol_service.find(label="myvol")
for vol in matching_vols:
   vol.delete()

[FabioRosado]

That's great thank you so much for the explanation. I will see if we can use .find if not I will see how we are implementing it and do the same for the .get methods