Awesome, thanks Wido! Would this change make sense to add in 4.1 too?
I've assigned the issue to you - if the change can't be added in 4.1, I guess we can close the ticket. Thanks, Dave. On Thu, Mar 7, 2013 at 7:31 PM, Wido den Hollander <w...@widodh.nl> wrote: > Hi, > > See this commit: 9e02ed139fe8f7cd9fcb6a989dbe94**c326774c6b > > That should include all JAR files in the plugins directory in the > classpath. > > Wido > > > On 03/06/2013 05:14 PM, Marcus Sorensen wrote: > >> Yes, Ubuntu is doing that, but for example on CentOS, apache is >> packaged such that you have : >> >> [marcus@www2 modules]$ ls -l /etc/httpd/modules >> lrwxrwxrwx 1 root root 29 Apr 17 2012 /etc/httpd/modules -> >> ../../usr/lib64/httpd/modules >> >> On Wed, Mar 6, 2013 at 8:47 AM, David Nalley <da...@gnsa.us> wrote: >> >>> 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 >>> >> >
