On Wed, Mar 6, 2013 at 10:20 AM, Marcus Sorensen <shadow...@gmail.com> wrote: > On Mar 6, 2013 8:04 AM, "Wido den Hollander" <w...@widodh.nl> wrote: >> >> On 03/06/2013 09:03 AM, Dave Cahill wrote: >>> >>> Moving discussion from Jira ticket to dev list as suggested by Hugo. >>> >>> Request from Kawai-san: >>>> >>>> There is no place to put plugin jar files for cloudstack agent program >>> >>> now, while management server program has default @PLUGINJAVADIR@ where >>> plugin classes will be loaded into server at startup. >>>> >>>> We will need to load a class, for example when we try to use a custom >>> >>> "libvirt.vif.driver" which can be configured at agent.properties. >>> >>> Suggestion by Marcus: >>>> >>>> I'd actually defer to the guys who have been working on the packaging. > It >>> >>> seems like it would be distribution specific, and handled by the startup >>> scripts. >>>> >>>> The obvious solution to me would be to create a directory, say >>> >>> /usr/share/cloudstack-agent/plugins, and append that to the classpath in >>> the init scripts so that the agent can see the plugins copied there. >> >> >> Sounds very good to me! The init scripts can do that, no problem. >> >> I would indeed use a "plugins" directory which is by default empty since > what we distribute goes into "lib". While you could place your plugin in > the "lib" directory I wouldn't recommend it. >> >> >>>> Maybe go a step further and make a symlink > /etc/cloudstack/agent/plugins; >>> >>> easier for admins to find. >>> >> >> Nack, that symlink will start haunting us at some point I think. /etc is > also for configuration, not for plugins. Better point the admin into the > right directorion. >> >> We can always add a comment in the example agent.properties. >> >> Wido > > That's fine with me as well, I've just seen a trend of apps doing that > (apache modules for example) on certain distros, so I thought it might be > worth discussing. If we were putting the agent stuff in a different > location for each distro I might care about having that more, to present a > more standard/predictable interface to admins. >
Typically in most cases I've seen distros that are doing that are using those directories as a way to show all modules and a way to enable modules that (e.g. mods_available and mods_enabled). I personally am not a fan of that, and hope that we wouldn't use such trickery to accomplish things when a simple text file will do. --David
