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:31:22 GMT

Please see my responses in-line below.


On Aug 21, 2013, at 11: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.

+1.  I will take it a step further, with Spring 3, I don't even want to see a Spring configuration
file.  The @Configuration facility allows all wiring to be programatic with no Spring dependencies
in actual domain objects or service code (previous rant on this subject [1]).


> 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.

Large agree (as I laid in my original proposal).  However, I would like to extend the can
to a URL not just a filesystem path.  In a clustered environment, operators may want to put
their drivers in a S3/Swift bucket or simple deploy them as static assets on an HTTP server.
 Generally, we need to break CloudStack of the assumption that everything is stored in a filesystem.
 I don't see a need to complicate the mechanism with an exclusion list.  If the file is present,
it will be used.  

I also believe that we will need our own archive format to support the deployment of additional
capabilities such as UI plugins to actually configure/control a plugin, provide internalization
resources, and bundle up dependencies.  Finally, by default, CloudStack should only accept
signed components.  We can provide a configuration option to disable this requirement, but
I would like to see such a mechanism start on the proper security footing by requiring it
by default.

> 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)

I agree regarding the repository model.  I would like a simple, decentralized repository mechanism
such as Yum (apt is more powerful but also more difficult to configure).  Vendors publish
their repositories and operators point to them.  We could make the discovery of vendor repositories
a little easier by putting the repository definition for each GPG key issued to vendors. 
As a project, we don't want to get near driver distribution.  We only want to define a common
repository structure, and possibly, provide pointers to vendor repos.

> 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