Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
Hi, See this commit: 9e02ed139fe8f7cd9fcb6a989dbe94c326774c6b 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
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
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
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
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 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) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
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. 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) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
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
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
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
