The document discusses the DefCore process, which defines the minimum standards required for products to be labeled "OpenStack". It aims to drive interoperability through common validation testing and implementation of core code sections. The process balances community and vendor input, with the community writing tests and vendors performing self-testing. It will approve guidelines every few months delineating required capabilities validated by tests as well as designated core code sections. It seeks community review of the 2015A guidelines before they are approved by the OpenStack Board to govern what functionality and code is required for OpenStack products and platforms.

1. DefCore Targets:
Cloud Interop & Vendor Clarity
How a community answers “what is OpenStack” ?
DefCore Co-Chairs
Rob Hirschfeld & Egle Sigler

2. 2
2015A Process (http://bit.ly/defcore2015a)
In Vancouver, we expect the Board to approve the official
DefCore Process.
This process defines how the Board will manage core. We
spent the last 18 months figuring out the why.
We are seeking community input on the process before
the Board votes. Input may include “+1, yes, I like it.”
Our object today is to give you enough background to be
an informed reader of the 2015A process.

3. 3
DefCore = Commercial Use
Uses of the OpenStack mark:
1. Community (non-commercial use)
2. Code (integrated release)
3. Commerce (products and services)
DefCore covers #3 only!

4. 4
DefCore = Interoperability
• OpenStack™ should mean something to users
• What matters to users?
• OpenStack as a reliable platform (brand)
• Common Validation (testing)
• Common Implementation (code)
• And, don’t impede growth and innovation!

5. 5
What is DefCore?
• DefCore is a process that sets base requirements for all
OpenStack products by defining:
1) must-pass tests of capabilities, and
2) designated sections of code
• These definitions use community resources and involvement
to drive interoperability by creating the minimum standards
for products labeled “OpenStack”.

6. 6
DefCore Process based on Principles
Green Area
• Common Core
• For All Usages
Blue Area
• Reference Code
• With Substitutions
Orange Area
• community tests
• some required
• self-testing ok

7. 7
Balanced Process
We are committed to
an open and transparent
process that balances
community and vendors.

8. 8
Community
• Interop Map
○ to find widely used capabilities
• Writes Tests
• Defines Capabilities
TESTS ARE TRUTH
Note: Not limited to Tempest

9. 9
Vendor Responsibility
• Self-testing
• Clear Pass-Fail Results
• Transparent Reporting
• Can Appeal individual tests
MUST TEST TO USE BRAND

10. 10
• Is the final authority on “What is Core”
• Select & Scores Required Capabilities
• Acts through the DefCore Committee
• Publishes regular guidelines
PICKS REQUIRED TESTS
Foundation role:
• manages vendors
• enforces brand use
OpenStack Board

11. 11
DefCore Deliverables?
Guidelines!
Explains in simple terms
what capabilities and code
is required for OpenStack
platforms and products.
JSON version includes
detailed lists of tests.
RST version has high level
summaries for review.
OpenStack DefCore 2015.03
Releases Covered: ...
Platform Components Required: Compute, Object
Advisory: None
Deprecated: None
Removed: None
Status: approved
Compute Component Capabilities
Required
Advisory
Deprecated
Removed
Compute-auth (nova)
Compute-flavors (nova)
Compute-images (nova)
…
Auth-token (keystone)
Compute-servers-metadata (nova)
None
None
Designated Sections
Required …

12. 12
Process Timeline
DefCore is not about “latest releases”

13. 13
Guidelines Cover
Progression: Advisory ↦ Required ↦ Deprecated
• Releases
• Platform Components
• Capabilities
• Project APIs
• Validated by Tests
• Designated Sections
• Integrated Projects Only
• Required Upstream
Capabilities (API)
DesignatedSection
OpenStack Component
OpenStack Platform

14. 14
Platform & Components

15. 15
Which code gets Designated?
Designated:
● code provides the project external REST API, or
● code is shared and provides common functionality for all
options, or
● code implements logic that is critical for cross-platform
operation
Not Designated:
● code interfaces to vendor-specific functions, or
● project design explicitly intended this section to be
replaceable, or
● code extends the project external REST API in a new or
different way, or
● code is being deprecated

16. 16
Capabilities
Capabilities = Groups of API Tests, e.g.:
"block-snapshots" :
test_snapshot_create_get_list_update_delete,
test_volume_from_snapshot
NOT LIMITED TO TEMPEST

17. 17
2015A Process (http://bit.ly/defcore2015a)
ok, we’re finally ready to show you the process!

18. 18
2015A Process (http://bit.ly/defcore2015a)
Time Frame Milestone Activities Lead By
-3 months S-3 "Preliminary” draft (from current) DefCore
-2 months S-2 ID new Capabilities Community
-1 month S-1 Score Capabilities DefCore
Summit S "Solid" draft Community
Advisory/Deprecated items
selected
DefCore
+1 month S+1 Self-testing Vendors
+2 months S+2 Test Flagging DefCore
+3 months S+3 Approve Guidance Board

19. 19
2015A Process (http://bit.ly/defcore2015a)
4 phases:
1. Guidelines Draft Phase (A) - 3 months before summit
a. collect data
b. add new and advance advisory requirements
c. score items
2. Guidelines Review Phase (B) - at summit
3. Community Review & Vendor Self-Test (C) - after summit
a. changes tracked and managed in Gerrit
b. vendors work with Foundation on self-testing
4. Guideline Approval (D) - 3 months after summit

20. 20
Call to Action!
User? As your vendor which
guidelines they have passed!
Vendor? Validate your products!
We need YOUR HELP:
• Review the 2015.Next
• Help designate sections
• Run Tempest and upload
• Rock us some +1s!

21. 21
References
DefCore Github:
https://github.com/openstack/defcore/
WE USE GERRIT FOR CHANGES AND REVIEWS
DefCore Wiki: https://wiki.openstack.
org/wiki/Governance/DefCoreCommittee
Rob’s Blog:
http://robhirschfeld.com/?s=defcore
Please reach out to
OpenStack DefCore mailing list!
Rob (@zehicle) & Egle (@eglute)