[openstack-dev] [openstack-tc] Incubation Request for Barbican
Fox, Kevin M
kevin.fox at pnnl.gov
Tue Dec 3 01:40:33 UTC 2013
I've been anxious to try out Barbican, but haven't had quite enough time to try it yet. But finding out it won't work with Qpid makes it unworkable for us at the moment. I think a large swath of the OpenStack community won't be able to use it in this form too.
From: Dolph Mathews [dolph.mathews at gmail.com]
Sent: Monday, December 02, 2013 3:46 PM
To: Russell Bryant
Cc: openstack-tc at lists.openstack.org; OpenStack Development Mailing List (not for usage questions); cloudkeep at googlegroups. com; barbican at lists.rackspace.com
Subject: Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican
On Mon, Dec 2, 2013 at 11:55 AM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:
On 12/02/2013 12:46 PM, Monty Taylor wrote:
> On 12/02/2013 11:53 AM, Russell Bryant wrote:
>>> * Scope
>>> ** Project must have a clear and defined scope
>> This is missing
>>> ** Project should not inadvertently duplicate functionality present in other
>>> OpenStack projects. If they do, they should have a clear plan and timeframe
>>> to prevent long-term scope duplication.
>>> ** Project should leverage existing functionality in other OpenStack projects
>>> as much as possible
>> I'm going to hold off on diving into this too far until the scope is
> I'm not.
Ok, I can't help it now.
>> The list looks reasonable right now. Barbican should put migrating to
>> oslo.messaging on the Icehouse roadmap though.
Yeahhh ... I looked and even though rpc and notifier are imported, they
do not appear to be used at all.
>> It looks like the only item here not in the global requirements is
>> Celery, which is licensed under a 3-clause BSD license.
> I'd like to address the use of Celery.
> Barbican has been around for 9 months, which means that it does not
> predate the work that has become oslo.messaging. It doesn't even try. It
> uses a completely different thing.
> The use of celery needs to be replaced with oslo. Full stop. I do not
> believe it makes any sense to spend further time considering a project
> that's divergent on such a core piece. Which is a shame - because I
> think that Barbican is important and fills an important need and I want
> it to be in. BUT - We don't get to end-run around OpenStack project
> choices by making a new project on the side and then submitting it for
> incubation. It's going to be a pile of suck to fix this I'm sure, and
> I'm sure that it's going to delay getting actually important stuff done
> - but we deal with too much crazy as it is to pull in a non-oslo
> messaging and event substrata.
Yeah, I'm afraid I agree with Monty here. I didn't really address this
because I was trying to just do a first pass and not go too far into the
I think such a big divergence is going to be a hard sell for a number of
reasons. It's a significant dependency that I don't think is justified.
Further, it won't work in all of the same environments that OpenStack
works in today. You can't use Celery with all of the same messaging
transports as oslo.messaging (or the older rpc lib). One example is Qpid.
I feel like I'm trying to read past the rant :) so I'd like to stop an ask for clarification on the exact argument being made. Is the *only* reason that celery should not be used in openstack because it is incapable of being deployed against amqp 1.0 brokers (i.e. qpid).
I'm really trying to understand if the actual objection is over the use (or not) of oslo (which seems like something the TC should express an opinion on, if that's the case), but rather about limiting OpenStack's deployment options.
OpenStack-TC mailing list
OpenStack-TC at lists.openstack.org<mailto:OpenStack-TC at lists.openstack.org>
More information about the OpenStack-dev