That's correct.
It will also allow us to handle those cases when a VM has resources
attached (such as disks) in different resoruce groups as the VM itself, a
configuration allowed in Azure ARM but not possible to replicate in our
current implementation
El mié., 15 feb. 2017 a las 1:10, Ignasi Barrera (<n...@apache.org>)
escribió:
> 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!
> >
> >
> >
>
