I’ll be completely honest in that I do not know what precisely a strategy plugin is. Perhaps we should have an irc discussion on the topic so you can educate me ;)
That said, I assume Ansible loads the strategy plugin. We already hide Ansible behind a network service (popen). Is the issue that the strategy plugin needs to import a whole bunch of Ansible code? If that is the concern, the strategy plugin can be written in ASL2.0, sit in our code base, and import stuff from Ansible proper, and it will still be sitting behind that popen once instantiated. The popen I am talking about is the one used within kolla-ansible (the tool that used to be a shell script which is now python). I’m pretty sure if you give Jeffrey some requirements, he can implement one just as Sam did with kolla_docker.py. If its ASL2.0 it can sit in the Kolla repo. If it is not ASL2.0 it needs to sit somewhere else, probably upstream in Ansible itself. There are only a few strategies for parallel runtime at present. They would probably take more if it was made to be generic. One assumption I make is the strategy plugins can be specified at runtime in Ansible. Is that the case? Regards -steve From: Michał Jastrzębski <inc...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Friday, November 4, 2016 at 7:11 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3 I read what you say Steven;) strategy plugin is not module, we don't use popen there. Also it will require importing GPL code from Ansible itself. Clint is right in this context. Writing it from scratch is not an option to (way to complex than docker stuff we did). Imho only option will be to write GPL driver that will be run with popen. Question is whether this driver can sit in Kolla repo or not, and if not, where? On Nov 4, 2016 6:51 PM, "Steven Dake (stdake)" <std...@cisco.com<mailto:std...@cisco.com>> wrote: Michal, Have you read nothing I’ve said? If its new code, write it as ASL2.0. The fact that it plugs in or uses GPLv3 code is totally irrelevant since it is isolated by a network layer (specifically popen). Regards -steve From: Michał Jastrzębski <inc...@gmail.com<mailto:inc...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Friday, November 4, 2016 at 5:54 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3 So as Clint mentioned, strategy plugins probably will be tainted by GPL. One of alternatives would be to create separate project for this single plugin, but I'd rather avoid that. Any other alternatives comes to mind? On Nov 4, 2016 5:18 PM, "Fox, Kevin M" <kevin....@pnnl.gov<mailto:kevin....@pnnl.gov>> wrote: Must be gplv3 compatible. not necessarily gpl. apache license is compatible. Thanks, Kevin ________________________________________ From: Clint Byrum [cl...@fewbar.com<mailto:cl...@fewbar.com>] Sent: Friday, November 04, 2016 4:38 PM To: openstack-dev Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3 Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +0000: > On 2016-11-04 22:50:10 +0000 (+0000), Jeremy Stanley wrote: > [...] > > As I understand it, the challenge here is that plugins for Ansible > > will by definition be derivative works of Ansible and thus inherit > > their license choice. No amount of "clean room reimplementation" > > will solve that unless you also reimplement Ansible under a > > different license while you're at it. > [...] > > Further research suggests I'm wrong on this front. I was assuming > Ansible was providing a Python plug-in API here, in which case > coding to that would potentially create a derivative work. Instead > it looks like for at least some things they refer to as plug-ins > they pass around a JSON data structure which upstream Ansible has > said in the past they do not consider to result in plug-ins becoming > derivative works of Ansible. For example: > > https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py Modules are not plugins. > https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk Same here. > https://github.com/ansible/ansible/issues/8864 This only refers to dynamic inventory, which is hardly even a plugin interface. Strategy plugins run in ansible itself and must import pieces of Ansible, and thus must be GPLv3: https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
