cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cahill <dcah...@midokura.com>
Subject Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
Date Fri, 08 Mar 2013 04:46:57 GMT
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 <wido@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 <david@gnsa.us> wrote:
>>
>>> On Wed, Mar 6, 2013 at 10:20 AM, Marcus Sorensen <shadowsor@gmail.com>
>>> wrote:
>>>
>>>> On Mar 6, 2013 8:04 AM, "Wido den Hollander" <wido@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
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message