Open Stack

On Thu, Sep 18, 2014 at 3:55 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

>
> On Sep 18, 2014, at 10:16 AM, Kapil Thangavelu <
> kapil.thangavelu at canonical.com> wrote:
>
> >
> >
> > On Thu, Sep 18, 2014 at 4:18 AM, Flavio Percoco <flavio at redhat.com>
> wrote:
> > On 09/17/2014 04:34 PM, Doug Hellmann wrote:
> > > This thread [1] has turned more “future focused", so I’m moving the
> conversation to the -dev list where we usually have those sorts of
> discussions.
> > >
> > > [1]
> http://lists.openstack.org/pipermail/openstack/2014-September/009253.html
> > >
> >
> >
> > I saw this mentioned in the `openstack` thread but I'd like us to
> > reconsider it.
> >
> > Since we've gone through the "hey please don't deprecate it, I'll help"
> > process a couple of times with the zmq driver, I'm thinking we should
> > pull it out of the code base anyway.
> >
> > I think the primary issue has been two fold, one is the lack of
> reviews/merges on extant patches that fix critical items that have been
> outstanding for months. I think that is compounded by the other issue which
> was the lack of tests. We've sprinted last week on adding in both unit
> tests, the extant patches and functionally verifying them by automating
> cloud deployments with zmq for the messaging driver. We're also committing
> as a company to supporting it on an ongoing basis. If we get the gates
> going for kilo, i don't see any reason for the churn below, if the gates
> don't get going we can yank to external in kilo anyway.
>
> I imagine that, as with drivers in other projects, part of the issue here
> is that there are not enough oslo.messaging core reviewers comfortable with
> zmq to feel confident reviewing the driver. Flavio’s proposal also has the
> benefit of addressing this, since some of the currently interested parties
> could be given core reviewer privileges on an oslo.messaging.zmq repository.
>
> For now, I’m in favor of keeping an eye on the current interest and seeing
> how things progress before making a final decision on whether to delete the
> driver, move it to its own repository, or keep it where it is. I’d like to
> hear from some of the rest of oslo-core and oslo-messaging-core about their
> opinions, too, though — it isn’t my call alone.
>

While I'm no longer involved and quite unlikely to again become involved, I
will say that I'm +1 on maintaining it separately.

At the time we merged the ZeroMQ driver, it was suggested that we keep it
out and maintain it outside the tree. I lobbied hard to get it in, and it
was... but it was at great cost. The review process is highly detrimental
to fast-moving code bases and imposes a severe handicap to gaining maturity
and full API compliance, etc. Once the ZeroMQ code went into Nova and
subsequently Oslo, it was incredibly difficult to balance the need to
increment and improve the code and improve testing while also managing
reviews.

The reason I lobbied hard to get the code in was because it couldn't really
be tested much otherwise. We couldn't keep track of changes in Nova and the
needs of OpenStack. Ultimately, as a the project evolved and introduced
changes to messaging for the needs of projects such as Ceilometer, what was
once an advantage became a disadvantage, when coupled with the long review
times.

However, the barriers to maintaining code out of the tree is lower than
ever.  I currently maintain the Docker driver out of Nova's tree and it's
doing fine. Well enough that I no longer want it to go back into Nova's
tree.  While I'd like it to become part of Nova, I'd like to maintain a
separate or superset of core reviewers as not to impede development and
maintenance, without changes to Gerrit, this means using a separate git
repository -- and that's okay.

The only reason I see moving the Docker code back into Nova would be
political, not based on the merit of a technical approach or ease and cost
of maintenance. In the last year, I've become very aware of the financial
requirements that the OpenStack community has unwittingly imposed on its
contributing members and I really wish, as much as possible, to roll this
back and reduce the cost of contributing. Breaking code out, while
accepting it may still be "valid" and "included" (if not core), is a big
step for OpenStack in reducing that cost. Obviously, all I've just said
could be applied to the ZeroMQ driver as well as it applies to Docker.

The OpenStack CI system is now advanced and mature enough that breaking
ZeroMQ out into a stackforge repo and creating dependencies between the
projects and setting up testing will be, in my opinion, better for any new
maintainers and users of this driver.

Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140918/b852de21/attachment.html>