Open Stack

On Sep 18, 2014, at 4:16 PM, Eric Windisch <eric at windisch.us> wrote:

> 
> 
> 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.

That’s great feedback, Eric, thank you. I know some of the other projects are moving drivers out of the main core tree, and we could certainly consider doing that here as well, if we have teams willing to sign up for the work it means doing.

In addition to the zmq driver, we have a fairly stable rabbit driver, a qpid driver whose quality I don’t know , and a new experimental AMQP 1.0 driver. Are we talking about moving those out, too, or just zmq because we were already considering removing it entirely?

Doug

> 
> Regards,
> Eric Windisch 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev