incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <nour.moham...@gmail.com>
Subject RE: [DISCUSS] OSGi framework for plugins and more?
Date Fri, 16 Nov 2012 17:52:40 GMT
hi

Sent from my Samsung Galaxy S3
Apologies for any typos
On Nov 15, 2012 6:52 PM, "Donal Lafferty" <donal.lafferty@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.mohammad@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.Huang@citrix.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Alex Huang [mailto:Alex.Huang@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.mohammad@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.Huang@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message