Steve, 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:
os_auth.py os_keystone_domain.py os_keystone_endpoint.py os_keystone_role.py os_keystone_service.py os_user.py os_user_group.py os_user_role.py 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. [1] https://github.com/emonty/ansible-modules-core/tree/merge-it-all/cloud/openstack Sam Yaple 864-901-0012 On Fri, Jul 3, 2015 at 1:56 PM, Greg DeKoenigsberg <g...@ansible.com> wrote: > Option 3 sounds fine to me. We hope to have 2.0 out in August, so one > hopes you wouldn't have to carry them very long. > > --g > > On Fri, Jul 3, 2015 at 2:53 PM, Steven Dake (stdake) <std...@cisco.com> > wrote: > > Kolla Devs as well as the Technical Committee, > > > > I wanted to get the TC’s thoughts on this plan of action as we intend to > > apply for big tent once our Ansible code has completed implementation. > If > > the approach outlined in this email seems like a blocker and we should > just > > start with #4 instead, it would be immensely helpful to know now. > > > > The problem: > > A whole slew of OpenStack modules exist upstream in the Ansible core > > directory. Kolla wants to use these modules. These files are licensed > > under the GPLv3. They will be released with Ansible 2.0 but Ansible 2.0 > is > > not yet available. In the meantime we need these modules to execute our > > system. The repo in question is: > > > > https://github.com/ansible/ansible-modules-core > > > > The possible solutions: > > 1. Mordred suggested just merging the code in our repo, but I thought > this > > might trigger license contamination so I am not hot on this idea. > > 2. Relicense the upstream modules in ASL short term. Mordred tried this > but > > thinks its not possible because of the varied contributors. > > 3. Fork the repo In question, remove everything except cloud/openstack > > directory and turn this into a pip installable library. > > 4. Make a hacky solution that doesn’t use any upstream modules but gets > the > > job done. > > > > For the moment we have settled on #3, that is creating a repo here: > > > > https://github.com/sdake/kolla-pre-ansible-2-openstack/ > > > > And installing these in the deployment system. Once Ansible 2.0 is > > available, we would deprecate this model, and rely on Ansible 2.0 > > exclusively. > > > > Thoughts or concerns on this approach? > > > > Thanks > > -steve > > > > -- > Greg DeKoenigsberg > Ansible Community Guy > > Find out why SD Times named Ansible > their #1 Company to Watch in 2015: > http://sdtimes.com/companies-watch-2015/ >
__________________________________________________________________________ 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