cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
Date Wed, 06 Mar 2013 15:20:03 GMT
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.

>
>
>> Noa, Hugo and I are happy with that solution, but if anyone has any
>> thoughts, please let us know.
>>
>> Thanks,
>> Dave.
>>
>>
>> On Wed, Mar 6, 2013 at 4:58 PM, Hugo Trippaers (JIRA) <jira@apache.org
>wrote:
>>
>>>
>>>      [
>>>
https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594478#comment-13594478
]
>>>
>>> Hugo Trippaers commented on CLOUDSTACK-1489:
>>> --------------------------------------------
>>>
>>> Good idea, but discuss these things on list so everybody is involved.
>>>
>>>> cloudstack agent plugin classpath is missing
>>>> --------------------------------------------
>>>>
>>>>                  Key: CLOUDSTACK-1489
>>>>                  URL:
>>>
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-1489
>>>>
>>>>              Project: CloudStack
>>>>           Issue Type: Improvement
>>>>       Security Level: Public(Anyone can view this level - this is the
>>>
>>> default.)
>>>>
>>>>           Components: KVM
>>>>     Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2
>>>>          Environment: Linux kvm
>>>>             Reporter: Hiroaki Kawai
>>>>             Assignee: Noa Resare
>>>>
>>>> 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.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA
>>> administrators
>>> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>>>
>>
>

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