On 12/06/2013 08:35 AM, John Wood wrote: > Hello folks, > > Just an FYI that I've submitted a pull request [1] to replace Celery > with oslo.messaging.
wow. That was quick! /me is impressed Since you jumped on that - I went ahead and jumped on a pbr-ification patch for you. It may not work yet - I'm on weird network and having trouble install python things into virtualenvs: https://review.openstack.org/60551 https://review.openstack.org/60552 > I've tagged it as a work in progress per this note: > > "Please review this CR, which replaces Celery with oslo.messaging > components. I've verified that this works in my local environment, > but I still need to add unit testing. I also need to verify that it > works correctly with an HA Rabbit MQ cluster, as that is a hard > requirement for Barbican." > > Special thanks to Mark McLoughlin and Sylvain Bauza for pointing me > to very useful links here [2] and here [3] respectively. > > [1] https://review.openstack.org/#/c/60427/ [2] > https://review.openstack.org/#/c/39929 [3] > https://review.openstack.org/#/c/57880 > > Thanks, John > > ________________________________________ From: Monty Taylor > [mord...@inaugust.com] Sent: Thursday, December 05, 2013 8:35 PM To: > Mark McLoughlin; Douglas Mendizabal Cc: OpenStack Development Mailing > List (not for usage questions); openstack...@lists.openstack.org; > barbi...@lists.rackspace.com Subject: Re: [openstack-tc] > [openstack-dev] Incubation Request for Barbican > > On 12/06/2013 01:53 AM, Mark McLoughlin wrote: >> On Thu, 2013-12-05 at 23:37 +0000, Douglas Mendizabal wrote: >>>> >>>> I agree that this is concerning. And that what's concerning >>>> isn't so much that the project did something different, but >>>> rather that choice was apparently made because the project >>>> thought it was perfectly fine for them to ignore what other >>>> OpenStack projects do and go off and do its own thing. >>>> >>>> We can't make this growth in the number of OpenStack projects >>>> work if each project goes off randomly and does its own thing >>>> without any concern for the difficulties that creates. >>>> >>>> Mark. >>> >>> Hi Mark, >>> >>> You may have missed it, but barbican has added a blueprint to >>> change our queue to use oslo.messaging [1] >>> >>> I just wanted to clarify that we didn’t choose Celery because we >>> thought that “it was perfectly fine to ignore what other >>> OpenStack projects do”. Incubation has been one of our goals >>> since the project began. If you’ve taken the time to look at our >>> code, you’ve seen that we have been using oslo.config this whole >>> time. We chose Celery because it was >>> >>> a) Properly packaged like any other python library, so we could >>> just pip-install it. b) Well documented c) Well tested in >>> production environments >>> >>> At the time none of those were true for oslo.messaging. In >>> fact, oslo.messgaging still cannot be pip-installed as of today. >>> Obviously, had we know that using oslo.messaging is hard >>> requirement in advance, we would have chosen it despite its poor >>> distribution story. >> >> I do sympathise, but it's also true is that all other projects >> were using the oslo-incubator RPC code at the time you chose >> Celery. >> >> I think all the verbiage in this thread about celery is just to >> reinforce that we need to be very sure that new projects feel a >> responsibility to fit closely in with the rest of OpenStack. It's >> not about technical requirements so much as social responsibility. >> >> But look - I think you've reacted well to the concern and hopefully >> if it feels like there was an overreaction that you can understand >> the broader thing we're trying to get at here. > > I agree. I think you've done an excellent job in responding to it - > and I appreciate that. We're trying to be clearer about expectations > moving forward, which I hope this thread in some part helps with. > > Monty > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev