cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: [DISCUSS/PROPOSAL] Upgrading Driver Model
Date Mon, 26 Aug 2013 03:32:49 GMT

I think I mentioned in my proposal to defer hot loading/unloading to a later release.  It
is a hard issue, and not required to address the current pain points.


On Aug 25, 2013, at 7:43 AM, Daan Hoogland <> wrote:

> 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:)
> Daan
> 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)
>>> Darren
>>> 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
>>>> files
>>>> 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