Open Stack

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 <greg at 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) <stdake at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150707/df0cf936/attachment.html>