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

> 
> 
> On Thu, Sep 18, 2014 at 3:55 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> On Sep 18, 2014, at 10:16 AM, Kapil Thangavelu 
> <kapil.thangav...@canonical.com> wrote:
> 
> >
> >
> > On Thu, Sep 18, 2014 at 4:18 AM, Flavio Percoco <fla...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to