Open Stack

On 12/02/2013 11:53 AM, Russell Bryant wrote:
> On 12/02/2013 10:19 AM, Jarret Raim wrote:
>> All,
>>
>> Barbican is the OpenStack key management service and we’d like to
>> request incubation for the Icehouse release. A Rackspace sponsored team
>> has been working for about 9 months now, including following the Havana
>> release cycle for our first release.
>>
>> Our incubation request is here:
>> https://wiki.openstack.org/wiki/Barbican
>>
>> Our documentation is mostly hosted at GitHub for the moment, though we
>> are in the process of converting much of it to DocBook.
>> https://github.com/cloudkeep/barbican
>> https://github.com/cloudkeep/barbican/wiki
>>
>>
>> The Barbican team will be on IRC today at #openstack-barbican and you
>> can contact us using the barbican at lists.rackspace.com mailing list if
>> desired.
> 
> The TC is currently working on formalizing requirements for new programs
> and projects [3].  I figured I would give them a try against this
> application.
> 
> First, I'm assuming that the application is for a new program that
> contains the new project.  The application doesn't make that bit clear,
> though.
> 
>> Teams in OpenStack can be created as-needed and grow organically. As the team
>> work matures, some technical efforts will be recognized as essential to the
>> completion of the OpenStack project mission. By becoming an official Program,
>> they place themselves under the authority of the OpenStack Technical
>> Committee. In return, their contributors get to vote in the Technical
>> Committee election, and they get some space and time to discuss future
>> development at our Design Summits. When considering new programs, the TC will
>> look into a number of criteria, including (but not limited to):
> 
>> * Scope
>> ** Team must have a specific scope, separated from others teams scope
> 
> I would like to see a statement of scope for Barbican on the
> application.  It should specifically cover how the scope differs from
> other programs, in particular the Identity program.
> 
>> ** Team must have a mission statement
> 
> This is missing.
> 	
>> * Maturity
>> ** Team must already exist, have regular meetings and produce some work
> 
> This seems covered.
> 
>> ** Team should have a lead, elected by the team contributors
> 
> Was the PTL elected?  I can't seem to find record of that.  If not, I
> would like to see an election held for the PTL.
> 
>> ** Team should have a clear way to grant ATC (voting) status to its
>>    significant contributors
> 
> Related to the above
> 
>> * Deliverables
>> ** Team should have a number of clear deliverables
> 
> barbican and python-barbicanclient, I presume.  It would be nice to have
> this clearly defined on the application.
> 
> 
> Now, for the project specific requirements:
> 
>>  Projects wishing to be included in the integrated release of OpenStack must
>>  first apply for incubation status. During their incubation period, they will
>>  be able to access new resources and tap into other OpenStack programs (in
>>  particular the Documentation, QA, Infrastructure and Release management teams)
>>  to learn about the OpenStack processes and get assistance in their integration
>>  efforts.
>>  
>>  The TC will evaluate the project scope and its complementarity with existing
>>  integrated projects and other official programs, look into the project
>>  technical choices, and check a number of requirements, including (but not
>>  limited to):
>>  
>>  * 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
> clarified.

I'm not.

*snip*

>>  
>>  * 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.

>>  ** 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.