Mark T. Voelker d8fb682a2b Change doc references to DefCore

At the Board of Directors meeting on April 24, 2016 the Board of
Directors indicated that as DefCore has evolved it's focus on
interoperability and it's working structure, it's name may be a source
of some confusion to those outside of the community or who are new to
the community.  The Board made an informal request that the DefCore
Committee consider changing it's name to more clearly reflect it's focus
and structure.

This patch is the first step in that process.  It updates references
in various documents to change the name "DefCore Committee" to
"Interop Working Group" as agreed at the summer 2016 DefCore Committee
Sprint [1].

It should be noted that this patch should be considered a work in
progress to generate discussion until the new name is approved by
the DefCore Committee and the Board of Directors.  Should we elect
to go forward with the new name, some other actions will also need
to be taken, including but not limited to:

1. We will need to consider updating references on the OpenStack wiki.
2. We will need to consider updating the name of our IRC channel,
   mailing list, Launchpad project, and git repository.  Most of these
   changes will need to be carefully coordinated with the OpenStack
   Infrastructure team.
3. We will need to take into account external resources that point to
   DefCore artifacts, such as Foundation-maintained websites (such as:
   http://www.openstack.org/interop ).
4. We will need to coordinate with RefStack to minimize impact.
5. We will need to clearly communicate the name change to the rest of the
   community.

Note also that I've intentionally left many historical documents that
have been superceded (such as the 2015A process docs, Guidelines that
are no longer used, etc) in tact.  There seemed little value in
spending time on them and cluttering the patch with them since they're
now obsolete.

[1] https://etherpad.openstack.org/p/DefCoreSummer2016Sprint

Change-Id: I79d337c193e75c54d49f1d847468f6347e2ef2b3

2017-01-23 21:25:05 -05:00

3.7 KiB

Raw Blame History

Core Criteria

General

This is a subcomponent of the larger Core Definition documentation.

Core Capability Selection uses 12 criteria grouped into four primary categories:

Usage: the capability is widely used (Refstack will collect data)
Direction: the capability advances OpenStack technically
Community: the capability builds the OpenStack community experience
System: the capability integrates with other parts of OpenStack

These categories summarize critical values that we want in OpenStack and so make sense to be the primary factors used when we select required Capabilities. While we strive to make the process objective and quantitive, we must recognize that these choices drive community behavior.

Graphic showing Capabilities Seleciton Criteria

Details

With this perspective, here are the selection criteria.

To make cross reference easier, criteria are given a shortened name.

SHOWS PROVEN USAGE

"Widely Deployed" Candidates are widely deployed capabilities. We favor capabilities that are supported by multiple public cloud providers and private cloud products.
"Used by Tools" Candidates are widely used capabilities: Should be included if supported by common tools outside of the OpenStack community (RightScale, Scalr, CloudForms, jClouds, Fog, etc...).
"Used by Clients" Candidates are widely used capabilities: Should be included if called by common OpenStack clients (openstackclient, neutronclient, novaclient, etc) if necessary. This Criteria pertains mostly to API versioning. For example: if v2 of a given API is not used by other OpenStack clients but v1 is, then v2 doesn't achieve the "used by clients" Criteria.

ALIGNS WITH TECHNICAL DIRECTION

"Future Direction" Should reflect future technical direction (from the project technical teams and the TC) and help manage deprecated capabilities.
"Stable" Capabilities are required to be stable for >2 releases because we do not want required Capabilities that do not have dependable APIs.
"Complete" Where the code being tested has a designated area of alternate implementation (extension framework) as per the Interoperability Principles, there should be parity in capability tested across extension implementations. This also implies that the capability test is not configuration specific or locked to non-open technology.

PLAYS WELL WITH OTHERS

"Discoverable" Capability being tested is Service Discoverable (can be found in Keystone and via service introspection).
"Doc'd" Should be well documented, particularly the expected behavior. This can be a very subjective measure and we expect to refine this definition over time.
"Required in Last Release" A required capability should stay a required capability. This makes Capabilities sticky per release. Leaving the Interoperability Guidelines is disruptive to the ecosystem.

TAKES A SYSTEM VIEW

"Foundation" Capabilities that are required by other required capabilities and/or depended on by many other capabilities.
"Atomic" Capability is unique and cannot be built out of other required capabilities.
"Proximity" (sometimes called a Capability Cluster) selects for capabilities that are related to other required capabilities. This helps ensure that related capabilities are managed together.

NON-ADMIN

The original 13th "non-admin" criteria has been removed because Admin APIs cannot be used for interoperability and are not considered for end users.

3.7 KiB Raw Blame History