> -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Thursday, November 15, 2012 9:15 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: [DISCUSS] OSGi framework for plugins and more? > > > > > -----Original Message----- > > From: Mohammad Nour El-Din [mailto:nour.moham...@gmail.com] > > Sent: Wednesday, November 14, 2012 7:11 AM > > To: cloudstack-dev@incubator.apache.org > > 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 <alex.hu...@citrix.com> > > 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 listed. > > 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.
And that is if we see there's a good match with OSGi. I can see for example that if people want to add more automation, background monitoring etc, deploying and undeploying those on a live system can be very helpful. That maybe one good use of it. --Alex
