I would think so, since its a function of packaging rather than a change to the codebase, but I'm not sure where we really draw the line on that. On the one hand, anything in git could be considered 'code'. On the other hand, it seems like packaging has already had a lot of work done on it after the deadlines, so I'm not sure if the same rules apply. Maybe it boils down to whether we intended to support agent plugins in 4.1, if so, then it could be considered an oversight and a bug. Otherwise it can wait for next round. Anyone else have a better idea? On Mar 7, 2013 9:47 PM, "Dave Cahill" <dcah...@midokura.com> wrote:
> 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 > >>> > >> > > >
