cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [DISCUSS/PROPOSAL] Upgrading Driver Model
Date Sun, 25 Aug 2013 11:43:04 GMT
It seems I am the only one not sharing your reservations regarding
OSGi, so let's go for it, John.

I would personally  try to not bother with the hot-loading and
-unloading of drivers and create a install and a drivers directory for
all running processes, where these will be checked upon starting to
update or install any new stuff. If a real life-cycle management is
needed on run-time I would once again urge to go with OSGi.

I would love to help on this not withstanding any objection I have on
the way to go. It seems like fun to implement:)

On Fri, Aug 23, 2013 at 1:44 AM, Kelven Yang <> wrote:
> Spring is not meant to be used as a solution for run-time "plug-ins".
> Darren is correct that Spring XML should be treated as code (ideal place
> for it is the resource section inside the jar). Why we end up the way now
> is mainly for practical reason. Since most of our current pluggable
> features are not yet designed to be fully run-time loadable, most of them
> have compile time linkage to other framework components that are solved at
> loading time by Spring.
> Only after we have cleaned up all these tightly coupled loading time
> bindings, can we have a much simpler plugin configuration. And this
> run-time loadable framework does not necessary to be based on any complex
> ones (i.e., OSGi).
> Kelven
> On 8/21/13 8:42 AM, "Darren Shepherd" <> wrote:
>>I also agree with this.  Spring XML should always be treated as code not
>>really configuration.  It's not good to have a sysadmin touch spring
>>config and frankly it's just mean to force them to.
>>I would ideally like to see that registering a module is as simple as
>>putting a jar in a directory.  If its in the directory it gets loaded.
>>Then additionally you should have a way such that you can explicitly tell
>>it not to load modules based on some configuration.  That way, if for
>>some reason moving the jar is not possible, you can still disallow it.
>>So for example the directory based approach works well with rpm/deb's so
>>"yum install mycoolplugin" will just place jar somewhere.  But say your
>>troubleshooting or whatever, you don't really want to have to do "yum
>>remove..." just to troubleshoot.  It would be nice to just edit some file
>>and say "plugin.mycoolplugin.load=false" (or env variable or whatever)
>>On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam <> wrote:
>>> On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
>>>> Leaky Abstraction:  Plugins are registered through a Spring
>>>> configuration file.  In addition to being operator unfriendly (most
>>>> sysadmins are not Spring experts nor do they want to be), we expose
>>>> the core bootstrapping mechanism to operators.  Therefore, a
>>>> misconfiguration could negatively impact the injection/configuration
>>>> of internal management server components.  Essentially handing them
>>>> a loaded shotgun pointed at our right foot.
>>> This has been my pet-peeve too and I was told you can write properties
>>> above the spring contexts to make it simpler for operators to look at.
>>> Overall a great proposal and look forward to see more concrete steps
>>> that follow on the implementation details.
>>> --
>>> Prasanna.,
>>> ------------------------
>>> Powered by

View raw message