1. Is each service going to be a separate process? 2. Will the component model follow the current kernel / plugin strategy?
DL -----Original Message----- From: Mohammad Nour El-Din [mailto:nour.moham...@gmail.com] Sent: 15 November 2012 5:43 PM To: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS] OSGi framework for plugins and more? sounds like a good plan. allow me to brief what has been said: 1- disaggregatio of ACS into a set of services which are accessed restfully 2- the components of these services can be implemented as OSGi or at least OSGi ready any missing points ? additional ones ? other insights ? Sent from my Samsung Galaxy S3 Apologies for any typos On Nov 15, 2012 6:20 PM, "Alex Huang" <alex.hu...@citrix.com> wrote: > > > > > -----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
