cloudstack-dev mailing list archives

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

Please don't take my proposal as a criticism of the approach taken in 4.1.  I think the current
model is a big improvement over the previous approach.  Given the time constraints and ambitions
of that work, I think it was a solid, pragmatic first step.  I believe we are at a point to
assess our needs, and determine a good next step that (hopefully) further improves the model.

Thanks,
-John

On Aug 22, 2013, at 7:44 PM, Kelven Yang <kelven.yang@citrix.com> 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" <darren.s.shepherd@gmail.com> 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 <tsp@apache.org> 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 BigRock.com
>>> 
> 


Mime
View raw message