hi Sent from my Samsung Galaxy S3 Apologies for any typos On Nov 15, 2012 6:52 PM, "Donal Lafferty" <donal.laffe...@citrix.com> wrote: > > 1. Is each service going to be a separate process?
well services being accessed using their rest interface can ease that for sure but will not limit it > > 2. Will the component model follow the current kernel / plugin strategy? I am not the right one to answer that. anyone else would like to give feedback abt this point ? > > 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
