[openstack-dev] [openstack-tc] Incubation Request for Barbican
markmc at redhat.com
Thu Dec 5 22:57:26 UTC 2013
On Mon, 2013-12-02 at 17:33 -0500, Monty Taylor wrote:
> On 12/02/2013 05:09 PM, Jarret Raim wrote:
> >> I'd like to address the use of Celery.
> >> WTF
> >> 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.
> > Is the challenge here that celery has some weird license requirements? Or
> > that it is a new library?
> The second thing - as a thing to address functionality that has been in
> OpenStack since the beginning.
> > When we started the Barbican project in February of this year,
> > oslo.messaging did not exist. If I remember correctly, at the time we were
> > doing architecture set up, the messaging piece was not available as a
> > standalone library, was not available on PyPi and had no documentation.
> That is true. However, the equivalent oslo-incubator pieces were there.
> You can also get the latest pre-release library here:
> As soon as we get the wheel publication pre-release code working, those
> will go to pypi.
> > It looks like the project was moved to its own repo in April. However, I
> > can¹t seem to find the docs anywhere? The only thing I see is a design doc
> > here . Are there plans for it to be packaged and put into Pypi?
> > We are probably overdue to look at oslo.messaging again, but I don¹t think
> > it should be a blocker for our incubation. I'm happy to take a look to see
> > what we can do during the Icehouse release cycle. Would that be
> > sufficient?
> I think it would go a long way if you had a roadmap for how you're going
> to move to oslo.messaging from celery. The worrying part for me, to be
> honest, is that you didn't sync up with the state of the art in that
> subject across openstack but instead went to a library that clearly
> no-one else was using. A couple of conversations with markmc or
> dhellman, or anyone from oslo, or anyone from any of the projects that
> are currently also using Rabbit (or zeromq or qpid) for the reasons
> you're using it would have gotten you aligned pretty quickly with how
> everyone else is doing this ... OR, and argument could have been made as
> to why all of that was a terrible idea and that the whole project should
> move to celery.
> It's not that oslo-incubator was unknown - you're using other things.
> When we look at incubating things, part of it is about the tech, but
> part of it is the question about whether or not the project is going to
> add to the whole's ability to be greater than the sum of its parts, of
> if we're going to inherit another group of folks who will be balkanized
> in the corner somewhere.
> I don't want to sound punitive, that's not my intent - and I want you
> guys to succeed and to be a part of things. I just want to be careful
> that we don't add more complexity and confusion into an already
> difficult to fully digest landscape. I want to make sure that when we
> release an integrated release of OpenStack that it's an actual
> integrated stack that works together, and I want to make sure that we
> have an integrated developer community.
> SO - without drawing a hard line in the sand or anything, I think that a
> discussion of what the real concrete plans are around alignment with the
> messaging strata in OpenStack is will probably be one of the more
> important questions we look at.
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.
More information about the OpenStack-dev