Darren, Please see my responses in-line below.
Thanks, -John On Aug 21, 2013, at 11: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. +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]). [1]: http://markmail.org/thread/2b2egdruxvcognsz > > 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 <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 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
