Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of nour.mohammad@gmail.com
 designates 74.125.83.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA1E1CD81@SJCPMAILBOX01.citrite.net>
References: 
 <CAOvkMoZTGgYFzqifaGKPJNs=Tps=FcDz-okfvjqwrF9Tw24n5w@mail.gmail.com>
	<CCC7F0A0.1C0D0%kelven.yang@citrix.com>
	<CAAxZHddjhM=ABF8KxycSVvAexsZ4b4kkXnOzOD=tE312xthh+A@mail.gmail.com>
	<B1DF26ECC0458748AC97CECE2DA98D41012FA1E1CAFA@SJCPMAILBOX01.citrite.net>
	<CAOvkMoZXJ2RJLB8EhgxLuk1qEXtRvCoKF2_GXo5jFa8CXevuJQ@mail.gmail.com>
	<B1DF26ECC0458748AC97CECE2DA98D41012FA1E1CD7B@SJCPMAILBOX01.citrite.net>
	<B1DF26ECC0458748AC97CECE2DA98D41012FA1E1CD81@SJCPMAILBOX01.citrite.net>
Date: Thu, 15 Nov 2012 18:43:21 +0100
Message-ID: 
 <CAOvkMoZTsopzoC1BW0eHMJ+jSz2iydzPVniTDku=+ZA3O7v4Ww@mail.gmail.com>
Subject: RE: [DISCUSS] OSGi framework for plugins and more?
From: Mohammad Nour El-Din <nour.mohammad@gmail.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b344100f4f8a404ce8c2f7e

--047d7b344100f4f8a404ce8c2f7e
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7b344100f4f8a404ce8c2f7e--