osdir.com

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

Re: [PROPOSAL] Azure ARM shared resource group


Duncan.

jClouds does the right thing and remove the resource group when we release
the machine, the issue is definitely in Brooklyn (see my previous link):
Brooklyn always creates a shared resources group, multi-vm deployment or
not, and we never remove it.

The jClouds issue you referenced is precisely what I'm talking about. It
shouldn't be assigned to jClouds but Brooklyn.

Best.

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

> 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
> >>
> >
>
-- 

Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron