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 <[email protected]> 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 < > [email protected]> 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 >> >
