cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: [DISCUSS] OSGi framework for plugins and more?
Date Thu, 15 Nov 2012 17:15:15 GMT

> -----Original Message-----
> From: Mohammad Nour El-Din []
> Sent: Wednesday, November 14, 2012 7:11 AM
> To:
> Subject: Re: [DISCUSS] OSGi framework for plugins and more?
> Hi Alex...
>    Thanks for opening the discussion in the direction of what we need to do
> and how to do it, I thought no one will respond to my request :D
> On Wed, Nov 14, 2012 at 3:45 PM, Alex Huang <>
> wrote:
> > Here's my two-bits on OSGi.  I actually started a thread like this
> > sometime ago to which Mohammad reference.  I then did some research
> on what
> > OSGi can do.  The problems I looked at using OSGi for just isn't solvable
> > by OSGi.
> >
> > For example,
> > - How to contain fault within an availability zone.
> > - How to do rolling upgrade and phase out the rolling upgrades over a span
> > of days to deal with the time that it might take.
> > - How to do database upgrades/downgrades for the plugins
> > - How to scale different components differently
> >
> > OSGi does solve some problems
> > - How to enable and disable plugins on a production system but I'm not
> > quite sure how reliable that is.  Even eclipse asks you to restart eclipse
> > after adding a plugin.
> >
> I know the answer that Marcel would say about this point :D

I just talked to someone who says it does work reliably in their environments. 

> >
> > I think after looking at this, then I decided that
> >
> > - For modularity, nothing is better than compilation boundaries.  The
> > problem with some of the plugins is that it depends on cloud-core and
> > cloud-server.  It shouldn't .  All plugins must build to cloud-api only.
> >  Since all interfaces of CloudStack is in cloud-api (if you think about
> > that then cloud-api is basically the OSGi bundle), that's sufficient to
> > separate the plugins.
> > - For lifecycle of plugins, it probably requires that we switch to deploy
> > in something like Karaf before we can achieve runtime lifecycle changes.
> >  I'm not sure it's entire necessary and it doesn't take care of a plugin's
> > database versioning problem.
> > - To resolve the other problems, we basically need to break cloudstack
> > into separate processes.  Hence I've proposed the idea of disaggregating
> > cloudstack.
> >
> Again, I am not an OSGi expert, but from what you say it is more about
> compile and build time and making the separation of what one module
> should
> depend on what very clear and documented which we already do in my
> company
> as we also have a huge stack and also looked into OSGi which again a great
> tool but when we don't need everything it offers, we exactly needed what
> you explained and we manage that mostly through good usage of Maven
> which I
> know is tricky
> About the runtime aspects and database versioning I am afraid I am not
> aware about the internals and the exact requirements and hence I can't give
> any input
> On another side, as in either case we need to *disaggregate* ACS, we can
> make the disaggregated module OSGi ready at least as a 1st step towards
> assessing whether OSGi is the way we should go or not, and when it is more
> clear then we can either say no it is not the option we need or we will
> then be ready for the full move to OSGi
> Thoughts ?

My current thoughts are the large disaggregated CloudStack Services are going to be RESTful
services.  I don't see any benefits for them to be OSGi components for the reasons I've already

However, each service still may deploy plugins.  Those plugins can be converted to OSGi. 
It shouldn't be too difficult to do it as well.


View raw message