Interesting. I'm not sure how I missed this thread... I'll try to chime in where I can, then. However, everything going on in here sounds like work for post-4.3, but if we are adding revert volume snapshot to 4.3, we will need a solution to that before then. It seems like the idea I've got for this is fairly lightweight and could be either extended or removed depending on what comes out of that discussion. If there are other ideas, I'm more than happy to continue discussions.
-Chris -- Chris Suich chris.su...@netapp.com NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Oct 9, 2013, at 4:39 PM, John Burwell <jburw...@basho.com> wrote: > Kelven, > > As I stated in my proposal, I think it is important to recognize the > distinction between components that control/interact with infrastructure and > components that represent orchestration abstractions/mechanisms within the > management server. Currently, these two concepts are conflated -- > complicating the effort to modularize the system. Therefore, in my view, any > effort going forward must make this important distinction. > > The first type, in my vocabulary, are device drivers. In my view, these are > essential system extension points that require greater modularity and > isolation due to their potential to require conflicting dependencies and > their external QA. My proposal pertains only to these types of components, > and I think it important to continue the discussion as it has far reaching > implications to both the system architecture and our release process. IN > particular, I think it is possible for us to achieve the ability to have > completely segregated device drivers shipped separately from CloudStack > releases. > > Thanks, > -John > > On Sep 9, 2013, at 1:49 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > >> 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 >>>>>> >>>> >>> >> >
