Azure ARM: Adding scope to NodeId

[Dani Estévez <ka...@gmail.com>]

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!

Re: Azure ARM: Adding scope to NodeId

[Daniel Estévez <ka...@gmail.com>]

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 (<na...@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" <ka...@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!
> >
> >
> >
>

Re: Azure ARM: Adding scope to NodeId

[Ignasi Barrera <na...@apache.org>]

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" <ka...@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!
>
>
>