osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PROPOSAL] Azure ARM shared resource group


Thomas,

Sorry - wrong url - should have been
https://issues.apache.org/jira/browse/JCLOUDS-1331

Duncan

On Thu, 12 Apr 2018 at 15:27 Duncan Grant <duncan.grant@xxxxxxxxxxxx> wrote:

> Thomas,
>
> I think this problem is in jclouds as is does try to remove the resource
> group but fails due to caching on the api making it look like the resource
> group is not empty.  See
> https://issues.apache.org/jira/browse/JCLOUDS-1331?filter=-2&jql=project%20%3D%20JCLOUDS%20AND%20reporter%20in%20(currentUser())%20order%20by%20created%20DESC
>
> In the case of a multi-vm deployment I think we create a separate resource
> group for each VM so I don't think there should be an issue of the resource
> group having more than one VM in it. I think this is the correct behaviour
> as resource groups should group things with a shared life-cycle, which
> wouldn't apply to all the VMs in your app.
>
> cheers
>
> Duncan
>
> On Thu, 12 Apr 2018 at 15:17 Thomas Bouron <
> thomas.bouron@xxxxxxxxxxxxxxxxx> wrote:
>
>> Hi Brooklyners
>>
>> I have recently investigated an issue that occurs when Brooklyn is
>> deploying a blueprint to Azure ARM. On every deployment, Brooklyn will
>> start by creating a shared resource group [1] and add all the blueprint
>> VMs
>> into it. This is nice because all VMs are therefore able to talk to each
>> other.
>>
>> But, the main issue here is that this shared resource group is never
>> deleted. You end up with a load of unused resource groups that you have to
>> delete manually via the UI (one by one) or the CLI. While this won't cost
>> you money (resources groups are just logical groups of resources) that
>> leads to a very annoying issue: after a while, you will run out of
>> resource
>> groups, which will make subsequent deployments fail. Worse, I think it
>> particularly bad that we don't clean up after ourselves, leaving resources
>> that will prevent you from using you account.
>>
>> As it stands, I can see 2 solutions to fix this:
>> 1. try to remove the shared resource group after a VM is deleted. In case
>> of a mutli-VM deployment, this will fail for the first attempts (as you
>> cannot delete a resource group if it is not empty) but should succeed once
>> the last VM is deleted
>> 2. remove this code from `JcloudsLocation.java` file and use only jClouds
>> `network` configuration to specify the network the VM should be in. We
>> could also create an initializer from this code that will create a shared
>> resource group, but only while setup (i.e. conscious choice from the user)
>>
>> I'm leaning toward the second option here, as I think it's not Brooklyn
>> responsibility to sort out the networking. You should just pass the
>> relevant options to make your deployment successful. I believe it is the
>> responsibility of the cloud account owner to make sure VMs within the same
>> network can talk to each other.
>>
>> Either way, we need to fix this. WDYT?
>>
>> Best.
>>
>> [1]
>>
>> https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsLocation.java#L713
>> --
>>
>> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
>> https://cloudsoft.io/
>> Github: https://github.com/tbouron
>> Twitter: https://twitter.com/eltibouron
>>
>