John, I understand. The effort we did in 4.1 was mainly to free developers from the needs to work at low-level plumbing layer, prior to 4.1, not every developer knows how to modify ComponentLocator safely, switching to a standard framework can let us focus on Cloud operating business logic.
Breaking CloudStack into a more modularized architecture is a long journey which we are still striving to get there, Daren's work will again bring us one step closer, I think this incremental refactoring approach can help reduce the turbulence during the flight and ensure smoother releases along the way. kelven On 8/25/13 8:35 PM, "John Burwell" <jburw...@basho.com> wrote: >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.y...@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.sheph...@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 <t...@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 >>>> >> >
