Open Stack

On 12/02/2013 05:09 PM, Jarret Raim wrote:
> 
>>>>  * Process
>>>>  ** Project must be hosted under stackforge (and therefore use git as
>>>> its VCS)
>>>
>>> I see that barbican is now on stackforge,  but python-barbicanclient is
>>> still on github.  Is that being moved soon?
>>>
>>>>  ** Project must obey OpenStack coordinated project interface (such as
>>>> tox,
>>>>     pbr, global-requirements...)
>>>
>>> Uses tox, but not pbr or global requirements
>>
>> It's also pretty easy for a stackforge project to opt-in to the global
>> requirements sync job now too.
> 
> Are there some docs on how to do this somewhere? I added a task for us to
> complete the work as part of the incubation request here:
> https://wiki.openstack.org/wiki/Barbican/Incubation

I'm not sure there are docs per-se - you can essentially just add your
project name to projects.txt in openstack/requirements. Beware - really
soon this will tie you to the openstack pypi mirror (like, possibly
today) so if you have non-aligned requirements (see below) it may block
you until you either align or get requirements changed.

>>>>  ** Project should use oslo libraries or oslo-incubator where
>>>> appropriate
>>>
>>> The list looks reasonable right now.  Barbican should put migrating to
>>> oslo.messaging on the Icehouse roadmap though.
>>
>> *snip*
>>
>>>
>>>
>>> http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires
>>>
>>> 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.
>>
>> 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:

-f
http://tarballs.openstack.org/oslo.messaging/oslo.messaging-1.2.0a11.tar.gz#egg=oslo.messaging-1.2.0a11
oslo.messaging>=1.2.0a11

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 [1]. 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.

> [1] https://wiki.openstack.org/wiki/Oslo/Messaging
> 
> 
> 
> 
> Jarret
> 
>