<div dir="ltr">Steve,<br><br>We will need some of the modules from the "merge-it-all" branch of emoty's fork[1]. If it is more convient, you can just grab them all. The ones we require to proceed without triggering Option #4 would be the keystone related modules. That list is as follows:<br><br>os_auth.py<br>os_keystone_domain.py<br>os_keystone_endpoint.py<br>os_keystone_role.py<br>os_keystone_service.py<br>os_user.py<br>os_user_group.py<br>os_user_role.py<span class=""><br></span><br>I would also suggest to use git-submodule to add these directly to the ansible/library folder for Kolla. Assuming this doesn't still somehow taint the license or violate some stackforge rule. This too would only be temporary until Ansible 2.0.<br><br>[1] <a href="https://github.com/emonty/ansible-modules-core/tree/merge-it-all/cloud/openstack">https://github.com/emonty/ansible-modules-core/tree/merge-it-all/cloud/openstack</a><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Sam Yaple<br>864-901-0012</div></div>
<br><div class="gmail_quote">On Fri, Jul 3, 2015 at 1:56 PM, Greg DeKoenigsberg <span dir="ltr"><<a href="mailto:greg@ansible.com" target="_blank">greg@ansible.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Option 3 sounds fine to me. We hope to have 2.0 out in August, so one<br>
hopes you wouldn't have to carry them very long.<br>
<br>
--g<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Jul 3, 2015 at 2:53 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote:<br>
> Kolla Devs as well as the Technical Committee,<br>
><br>
> I wanted to get the TC’s thoughts on this plan of action as we intend to<br>
> apply for big tent once our Ansible code has completed implementation.  If<br>
> the approach outlined in this email seems like a blocker and we should just<br>
> start with #4 instead, it would be immensely helpful to know now.<br>
><br>
> The problem:<br>
> A whole slew of OpenStack modules exist upstream in the Ansible core<br>
> directory.  Kolla wants to use these modules.  These files are licensed<br>
> under the GPLv3.  They will be released with Ansible 2.0 but Ansible 2.0 is<br>
> not yet available.  In the meantime we need these modules to execute our<br>
> system.  The repo in question is:<br>
><br>
> <a href="https://github.com/ansible/ansible-modules-core" rel="noreferrer" target="_blank">https://github.com/ansible/ansible-modules-core</a><br>
><br>
> The possible solutions:<br>
> 1. Mordred suggested just merging the code in our repo, but I thought this<br>
> might trigger license contamination so I am not hot on this idea.<br>
> 2. Relicense the upstream modules in ASL short term.  Mordred tried this but<br>
> thinks its not possible because of the varied contributors.<br>
> 3. Fork the repo In question, remove everything except cloud/openstack<br>
> directory and turn this into a pip installable library.<br>
> 4. Make a hacky solution that doesn’t use any upstream modules but gets the<br>
> job done.<br>
><br>
> For the moment we have settled on #3, that is creating a repo here:<br>
><br>
> <a href="https://github.com/sdake/kolla-pre-ansible-2-openstack/" rel="noreferrer" target="_blank">https://github.com/sdake/kolla-pre-ansible-2-openstack/</a><br>
><br>
> And installing these in the deployment system.  Once Ansible 2.0 is<br>
> available, we would deprecate this model, and rely on Ansible 2.0<br>
> exclusively.<br>
><br>
> Thoughts or concerns on this approach?<br>
><br>
> Thanks<br>
> -steve<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Greg DeKoenigsberg<br>
Ansible Community Guy<br>
<br>
Find out why SD Times named Ansible<br>
their #1 Company to Watch in 2015:<br>
<a href="http://sdtimes.com/companies-watch-2015/" rel="noreferrer" target="_blank">http://sdtimes.com/companies-watch-2015/</a><br>
</font></span></blockquote></div><br></div>