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 Thu, 15 Nov 2012 17:43:21 GMT
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