Hi!

Thanks for sharing Dani!

Just to make sure we understand the scope of the proposed changes.

This will just affect the format of the IDs we generate for some entities,
and the main purpose is to make listNodes, listImages, listSecurityGroups,
etc, methods more resilient to existing environments, not generated by
jclouds where, say, a VM can have its disks in a resource group and the
NICs in a different one.

Is this right? I assume we'll be still creating all stuff in "our" resource
group?


Thanks!

I.

On Feb 14, 2017 7:01 PM, "Dani Estévez" <kaed...@gmail.com> wrote:

> Hello!
>
> I've been working lately with the Azure ARM provider and found that some
> resources can't be properly accesed or managed due to current
> identification including only region/location and id/vmName. Many APIs in
> AzureARM require specifying this resourcegroup and with the current
> implementation we can only manage one resourcegroup for each location.
>
> I think the complete identifier for this provider should include the
> ResourceGroup name (as in scope) so we'd have an identifier such as
> {location/region}/{resourceGroupName/scope}/{vmName/id}
>
> What do you think? I'll be posting a PR soon with these changes but it'd
> be good to have some feedback first since this change would affect the
> whole provider behavior.
>
> Thanks!
>
>
>

Reply via email to