Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of darren.s.shepherd@gmail.com
 designates 209.85.220.47 as permitted sender)
References: <80AC8E03-0EF4-4032-95C2-69273512357D@basho.com>
 <20130821135102.GA1403@cloud-2.local>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20130821135102.GA1403@cloud-2.local>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <871B5864-B414-4D1C-849B-8501E3AD76E1@gmail.com>
Cc: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>,
 Daan Hoogland <daan.hoogland@gmail.com>,
 Hugo Trippaers <htrippaers@schubergphilis.com>,
 "La Motta, David" <David.LaMotta@netapp.com>
From: Darren Shepherd <darren.s.shepherd@gmail.com>
Subject: Re: [DISCUSS/PROPOSAL] Upgrading Driver Model
Date: Wed, 21 Aug 2013 08:42:33 -0700
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>

I also agree with this.  Spring XML should always be treated as code not rea=
lly 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 puttin=
g a jar in a directory.  If its in the directory it gets loaded.  Then addit=
ionally you should have a way such that you can explicitly tell it not to lo=
ad 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 "yu=
m install mycoolplugin" will just place jar somewhere.  But say your trouble=
shooting or whatever, you don't really want to have to do "yum remove..." ju=
st to troubleshoot.  It would be nice to just edit some file and say "plugin=
.mycoolplugin.load=3Dfalse" (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.
>=20
> This has been my pet-peeve too and I was told you can write properties fil=
es
> above the spring contexts to make it simpler for operators to look at.
>=20
> Overall a great proposal and look forward to see more concrete steps
> that follow on the implementation details.
>=20
> --=20
> Prasanna.,
>=20
> ------------------------
> Powered by BigRock.com
>=20