Oscon 2014 def core review


Published on

OpenStack DefCore presentation given for OSCON OpenCloud Day.

Published in: Software
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Oscon 2014 def core review

  1. 1. How the Board’s DefCore Committee is Crowdsoucing Core Redefining OpenStack Core with Community, Tests & Code DefCore Co-Chair Rob Hirschfeld
  2. 2. 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!
  3. 3. 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 grown and innovation! DefCore = Interoperability
  4. 4. 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”.
  5. 5. Capabilities AND then Code Capabilities Project APIs Validated by Tests Designated Sections Integrated Projects Only Required Upstream Capabilities (API) DesignatedSection Integrated Release OpenStack Project Integrated Release
  6. 6. 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
  7. 7. Overview: How do we do this? One Committee, with - 10 Principles - 12 Criteria - 75+ Capabilities - 1 Scoring Matrix (per release)
  8. 8. DefCore Principles
  9. 9. Core = Tests+Designated Code
  10. 10. 12 Criteria
  11. 11. Capabilities Capabilities = Groups of API Tests, e.g.: "block-snapshots" : test_snapshot_create_get_list_update_delete, test_volume_from_snapshot
  12. 12. Capabilities Scoring Matrix Capabilities << Tests Score max 100 Non-Admin API Scored per Release Preliminary Havana Enforced for Juno
  13. 13. Community Feedback DefCore Depends on Usage Data! 1. Users 2. Tools 3. Clients
  14. 14. Some Examples
  15. 15. Case 1: BananaCloud Example Public Cloud “mostly” using OpenStack Active in community “OpenStack Powered”
  16. 16. Case 2: SpRocket Example Private Cloud “heavily” using OpenStack add missing core feature Specialized code base, ok “OpenStack Powered”
  17. 17. Case 3: “Mist” API Client “OpenStack Compatible” No Impact from DefCore, but… 1. should share their API use 2. add tests for untested APIs 3. reconsider non-must-pass
  18. 18. Tools: RefStack
  19. 19. Refstack, the Site Community Interop Portal Collects Test Results Shows Compliance Allows Comparison
  20. 20. Refstack, the Project Primary Use: Runs the Public Site Secondarily: Can be setup as private test collector for QA team note: Does not use or require Docker!
  21. 21. Call to Action! We need YOUR HELP Review the Havana Core Help designate sections Participate in Refstack Run Tempest and upload Rock us some +1s!
  22. 22. References RefStack Wiki: https://wiki.openstack.org/wiki/RefStack DefCore Wiki: https://wiki.openstack.org/wiki/Governance/DefCoreCommittee Rob’s Blog: http://robhirschfeld.com/tag/defcore/ RefStack: https://github.com/stackforge/refstack Please reach out to me, @zehicle, or OpenStack DefCore mailing list!