Open Stack

All,

With the call recording uploaded, I thought it was a good idea to distribute the meeting notes.

The source page is here: https://etherpad.openstack.org/p/openstack-designated-sections and I'm copying the full text into this email:

# Meeting Logistics for TC/DefCore Interlock

## Roll Call

*         DefCore: Rob Hirschfeld, Joshua McKenty, Will Auld
*         TC: Doug Hellmann, James Blair, Russell Bryant, Monty Taylor, Anne Gentle
*         PTL: David Lyle, John Dickinson

## SUMMARY

*         Recording: http://youtu.be/Vh5y7lXujLQ

Very successful working meeting that accomplished the following:
*         10 minute overview of the DefCore process
*         Working definition of designated sections (see bottom of document)
*         Answer questions raised by TC (see bottom of document)
*         Draft of guidelines (aka principles) for identifying designated and non-designated sections

## AGENDA
*
1.     DONE > History Lesson (if needed)  > https://wiki.openstack.org/wiki/Governance/CoreDefinition
2.     DONE > Process note: can we start by defining principles...  [SEE BOTTOM OF PAGE]
3.     DONE > Answer questions from response
4.     DONE > Define principles for selection
5.     DONE > Document "What is designated section? "
*
## SELECTION PRICIPLES FOR DESIGNATED SECTIONS

Goals:
    * Designated Sections decisions need to strike a balance between the commercial ecosystem and the community ecosystem.
    * Non-Designated Sections represent choice points for consumers

DESIGNATED when:
1.     API: code that provides the project API should be designated
2.     Shared: code that has common functionality for all options should be designated
3.     Cross-Platform: code that implements logic that is critical cross platform operation should be designated

NOT DESIGNATED when:
1.     Vendor: code that interfaces to vendor specific functions  should NOT be designated
2.     Choice: developer intended this section to be replacable should NOT be designated
3.     API "extensions": code that extends the API in a new or different way should NOT be designated
4.     Deprecation: code that is expected to be deprecated should NOT be designated

REQUEST: Have the TC approve a set of designated sections at or before the Juno Summit

QUESTION: Can we define a set of possible implementation for replacable sections that are ALSO required (must-pass) capabilities?  For example, do you have to ship the KVM driver even if you are not using it?  Also middleware?
*         Perhaps > We may have to resolve this in the future with more granular designated sections

## REFERENCE EXAMPLES

NOVA:
-----
Designated Sections:
*         All code except driver/plugins listed in "Replaceable sections".

  *   Even for replaceable drivers or plugins, we still expect use of the existing nova service that wraps those interfaces.

Replaceable Sections:
*         (Host and cell) Scheduler driver
*         (Host and cell) Filter scheduler driver's filters and weights

  *   While the line above implies the entire driver is fair game, this case is incredibly common and worth mentioning specifically.
*         Compute driver
*         REST API extensions

Rationale:
    Historically, nova has had plugins around schedulers and hypervisors.


SWIFT:
------

(not complete)

Designated Sections:
    proxy server
    middleware (to be detailed later)
    object server
    container server
    account server
    object expirer

Replaceable Sections:
    DiskFile implementations
    (future) DBBroker implementations
    you may add new middleware

Unsure:
    replicators
    auditors
    updaters
    account reaper

Rationale:
    TBD


KEYSTONE:
---------

Designated Sections:
    - At least one "stable" API (v2 or v3 at this time), using Keystone's routers, controllers, and managers
    - keystoneclient.middleware.auth_token

Replacable Sections:
    - Drivers (SQL, LDAP, memcached, flat-file, KVS, etc)
    - Authentication plugins (password, external, etc)
    - Token providers (UUID, PKI, etc)
    - Policy (which dictates how much of the API is exposed to consumers)
    - bin/keystone-all (Apache httpd is the preferred deployment approach)

Rationale:
    The API is really important, but custom implementations that implement the API should be allowed.


GLANCE:
-------

Designated Sections:
    (markwash proposes:) (and later markwash continues)
    Designated:
     - the HTTP APIs  Justification: API
     - the domain model Justification: Shared
     - the swift, filesystem, and http stores Justification: Cross platform
     Especially not designated:
     - the DB code Justification: should be replaceable
     - other stores Justification: should be replaceable, vendor-specific
     - the WSGI framework Justification: should be replaceable

Rationale:
    TBD

CINDER:
-------

Designated Sections:
    API    I'm fine with saying this but as I stated in the TC meeting this needs to be more than "API compat", this to me must mean the Cinder API
    (API section means actually the CODE that exposes the API, not just API-compatability)

Replacable Sections:
    Drivers
    Scheduler  Drivers, naturally... that's a no brainer, however "Scheduler" I disagree with.  Primarily because there is inherent functionality built into Cinder scheduler (multi-backend type filtering)
                        This can certainly be left as replaceable but IMO there MUST be requirements that it implements what's defined as core functionality in the Cinder API
    API extensions

Rationale:
    Historically, cinder has had plugins around schedulers and drivers.

Additional points:
        I think this is an "ok" start but IMO Cinder/OpenStack needs to be more than just an API, it needs to be about the process, the community etc etc  Perfect example is the new submissions that want to replace scheulder, quotas and drivers all in their own product.  IMO this is a dangerous path for OpenStack, it makes the bulk of the work done in the community a waste of time.  In other words OpenStack needs to be something MORE than just "hey we use the OpenStack API so we're OpenStack".


NEUTRON:
--------

Designated Sections:
    None.

Rationale:
    TBD

HEAT:
------

Designated Sections
*         heat-api
*         heat-engine
*         all OS::Heat::* resource types
*         OS::* resource types which correspond with the APIs of designated sections of other projects

Replaceable Sections
*         heat-api-cfn
*         heat-api-cloudwatch
*         AWS::* resource types
*         Deprecated OS::* resource types


HORIZON:
------

Designated Sections

Replaceable Sections

Rationale:
We may be able to delay discussion because we are not sure about requiring any parts of Horizon should be required at this point.


===

Other things:

    Ceilometer
    Horizon

Incubating (as of Havana):
    Ironic
    Sahara
    Trove

Non incubated as of Havana):
    Barbican
    Manila
    Marconi
    Designate
    Climate

## WHAT IS A "DESIGNATED SECTION"

This term is used to avoid using technical architecture terms like plug-in or extension.  These definitions should be durable regardless of if the capabilities are core or not.

There is a broad range of ideas for how to do this:
    1. it could be none and we'd just talk about APIs
    2. it could be all and we'd expect implementors to use OpenStack as is

When we talk about API comptability, we MEAN the code that implements the API.

A logical, non-audited portion of source code

We want to keep this light weight and easy to implement.  Calling out "big ticket" items should be enough.

QUESTION: Should we revisit section 6.13 ?
*         This may not be technically possible
*         This allows users to be protected against Vendors extending capabilities
*         Need to disclose differences that are not "portable" between implementations/deployments so users understand what those features are.

QUESTION: Is the specification of designated sections tied to or separate from the specification of "criteria" (see comment under Horizon above)? - Yes, those are separate considerations.

QUESTION: Are changes to designated sections ok?  YES (ideally, tied to the release time frames).

Questions in the TC response that need to be clarified:

http://git.openstack.org/cgit/openstack/governance/plain/resolutions/20140211-tc_defcore_response

QUESTION 1: how granular and specific does the board want this to be? How do we handle
  drift in the code over time from operations such as refactoring? How do we
  identify designated sections -- both line numbers and cryptographic hashes
  of the lines of code have been proposed, but both methods are flawed.

(Or perhaps better worded, how exactly should sections be defined, likely already clarified using examples here)

ANSWER 1: Not very granular.  Best effort is OK.

QUESTION 2 :  how limiting should it be? For example, are backports from master of fixes or
  features to the designated areas allowed?

ANSWER 2 : Best faith effort to submit patches upstream.  Monty: "seriously man, run the damn code!"

QUESTION 3: many parts of OpenStack are pluggable in ways that do not replace designated
  sections and are not alternate implementations of a plugin interface - for
  example you can add new WSGI middlewares or scheduler filters - how much of
  this extensibility does the board wish to allow?

ANSWER 3: If it passes the tests, it's probably not too bastardized.

QUESTION 4: altering libraries (3rd party, or part of OpenStack itself) can have as much
  impact on behaviour as altering OpenStack services itself. Is there a desire
  to address this?

ANSWER 4: There are times where this enables choice (like hyerpvisor) and others where it creates serious problems that do not create meaningful choice.  This will have to be case by case.  We can also rely on tests to help insulate users from behavior changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140330/9f7591a9/attachment-0001.html>