Open Stack

Point of clarification, Brian Coca (bcoca) confirmed there _will_ be an
ansible 1.9.5 to me the other day. So we will be unblocked at some point
for Docker 1.8.2. Unfortunately the module is broken with v1 registry past
Docker 1.8.2.

That said here are my issues:
    * its been 4 weeks since we fixed the bug upstream, we still don't have
a consumable version of ansible with the fix
    * waiting on new features to propagate through Docker and docker-py
then we must wait on ansible to implement/merge a PR for the new features
and THEN we must wait for a new ansible tag. At that point our new minimum
requirement is the latest version of ansible. Hopefully it doesn't have any
bugs
    * it has been said that because the v1 registry is deprecated so the
ansible  Docker module won't do anything to make that work (and its broken
with the upstream module). The local v2 registry is orders of magnitude
slower than a local v1. This is a big deal for us and its this type of
issue that makes me think we need our own module long term. We can't have
another project dictating such a crucial piece of our project and
development

In the case of liberty, while we can unpin 1.8.2, who is to say 1.9.3 won't
be broken for the same reason? Requiring later versions of ansible for
fixes here won't work long term.

I'm open to solutions that solve my concerns above without requiring a
module in our control.
On Nov 25, 2015 5:55 PM, "Steven Dake (stdake)" <stdake at cisco.com> wrote:

> Hey folks,
>
> I understand there is some contention over whether we should make our own
> docker module to deal with the fact that upstream is continually busted.
>
> The short answer is yes, I fully support our own docker module with some
> caveats:
>
> The long answer is:
> I would like the module to be compatible from a docker module perspective
> as it relates to Ansible integration.
> We are not waiting until Ansible 2.0 to unpin from docker 1.8.2.
> I want the code quality to be good, so I would appreciate thoughtful
> reviews of the docker module Sam has started on.
> The code may NOT be based upon a fork of the existing code for licensing
> reasons (GPLV3 incompatibility).  It doesn't have to be cleanroom, but it
> does have to be our own body of work.
> If upstream Ansible + docker ever get their act together, we will go back
> to using upstream.  If not, not. :)
>
> I am not blaming anyone from Ansible or Docker for these problems.
> Software integration is the hardest job on the planet as it relates to
> engineering, which is why the world is swiftly moving to full-blown CI to
> resolve these problems.  I know this isn't entirely the upstream way.  We
> should be fixing these things in upstream.  And we do actually do  that!
> The problem is Ansible 1.9.4 is the last release of Ansible 1.9, and
> Ansible, being a 50 person company, can't maintain two individual versions
> of Ansible.  So we are really doing this as a pragmatic factor of the
> environment in which we operate.
>
> Hope that clears up my position.
>
> Regards,
> -steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151126/a6e92e39/attachment.html>