[OpenStack Foundation] DefCore Update on Designated Sections, please disccuss/+1

Sandy Walsh sandy.walsh at RACKSPACE.COM
Mon Aug 18 16:25:26 UTC 2014


On 8/16/2014 5:30 PM, Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com> wrote:
Board Members,

Note: if you’d like a quick DefCore review, please read http://robhirschfeld.com/2014/08/12/patchwork-onion/

Last week, the DefCore committee had an open meeting to create the initial strawman Design Sections.  This strawman is intended as the basis for discussion leading up to an official DefCore recommendation at the September Board meeting.  We are planning to have open community discussion meetings for this in a few weeks after reviewing with the TC and other leaders.

Before we do that, we felt that the Board should have a chance to +1 and discuss the recommendations.  The recommendations are based on 10 principles (in the post script)

RECOMMENDATIONS:

·         Havana Nova is by default designated except scheduler, filter, drivers, API extensions and networking.

So, basically the REST API? I assume volume, networking and db fall under "drivers" The only other pieces are the conductor and cells.


·         Havana Swift has no designated code due to lack of consensus (see principles)

·         Havana Keystone is not designated.

·         Havana Glance designated sections are the API implementation code and domain model.

·         Havana Cinder designated sections are the API implementation code

API implementation code could be a little confusing. There's the code that implements the wsgi stack and then there's the code that implements the operations. I assume you mean the wsgi stack?


·         Havana Neutron has no designated sections.

·         Havana Heat is not a core capability, no position at this time.

·         Havana Horizon is not a core capability, no position at this time.

·         other projects do not are not core capabilities and are not reviewed at this time.

10 PRINCIPLES POST SCRIPT:
Should be DESIGNATED:
1.    code provides the project external REST API, or

I'd like to see the API-level integration tests included with this. A REST API isn't much use unless we can ensure it's functionally comparable across drivers.

Unless these integration/compatibility tests are going to be handled by another external project? (which would be unfortunate)

2.    code is shared and provides common functionality for all options, or
In the Nova case, I'm not sure what code this is referring to since everything else is non-designated.

Is it saying that there should be no single use-case code?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140818/3b61f984/attachment.html>


More information about the Foundation mailing list