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

Tim Bell Tim.Bell at cern.ch
Mon Aug 18 16:04:22 UTC 2014


Thanks for this list.

As regards "Havana Keystone is not designated", does this mean that I can have an OpenStack(tm) cloud without having a Keystone compatible API ?

If it is just the requirement for API compatibility, should this not be that it has no designated code.

If it is actually not required, can the other components function fully without Keystone ? I would hope to be able to point a standard CLI such as nova at an OpenStack (tm) cloud and for it to work.

This may reflect that some clouds have alternative identity implementations but I am not aware if they are API compatible yet.


From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com]
Sent: 16 August 2014 22:28
To: foundation at lists.openstack.org
Subject: [OpenStack Foundation] DefCore Update on Designated Sections, please disccuss/+1

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)


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

*        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

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

1.     code provides the project external REST API, or
2.     code is shared and provides common functionality for all options, or
3.     code implements logic that is critical for cross-platform operation
4.     code interfaces to vendor-specific functions, or
5.     project design explicitly intended this section to be replaceable, or
6.     code extends the project external REST API in a new or different way, or
7.     code is being deprecated
8.     UNdesignated by Default
?  Unless code is designated, it is assumed to be undesignated.
?  This aligns with the Apache license.
?  We have a preference for smaller core.
9.      Designated by Consensus
?  If the community cannot reach a consensus about designation then it is considered undesignated.
?  Time to reach consensus will be short: days, not months
?  Except obvious trolling, this prevents endless wrangling.
?  If there's a difference of opinion then the safe choice is undesignated.
10.      Designated is Guidance
?  Loose descriptions of designated sections are acceptable.
?  The goal is guidance on where we want upstream contributions not a code inspection police state.
?  Guidance will be revised per release as part of the DefCore process.

Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

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

More information about the Foundation mailing list