Governance/CoreDefinition
== PRELIMINARY PAGE FOR REVIEW AT Oct 4th 2013 Board Meeting
- DRAFT *
The following list represents the "core principles" used by the Foundation Board to determine how commercial implementations of OpenStack can be granted use of the trademark.
- Implementations that are Core can use OpenStack trademark (OpenStack™)
- This is the legal definition of “core” and the why it matters to the community.
- We want to make sure that the OpenStack™ mark means something.
- The OpenStack™ mark is not the same as the OpenStack brand; however, the Board uses it’s control of the mark as a proxy to help manage the brand.
- Core is a subset of the whole project
- The OpenStack project is supposed to be a broad and diverse community with new projects entering incubation and new implementations being constantly added. This innovation is vital to OpenStack but separate from the definition of Core.
- There may be other marks that are managed separately by the foundation, and available for the platform ecosystem as per the Board’s discretion
- “OpenStack API Compatible ” mark not part of this discussion and should be not be assumed.
- Core definition can be applied equally to all usage models
- There should not be multiple definitions of OpenStack depending on the operator (public, private, community, etc)
- While expected that each deployment is identical, the differences must be quantifiable
- Claiming OpenStack requiring use of designated upstream code
- Implementation’s claiming the OpenStack™ mark must use the OpenStack upstream code (or be using code submitted to upstream)
- You are not OpenStack, if you pass all the tests but do not use the API framework
- This prevents people from using the API without joining the community
- This also surfaces bit-rot in alternate implementations to the larger community
- This behavior improves interoperability because there is more shared code between implementation
- Projects must have an open reference implementation
- OpenStack will require an open source reference base plug-in implementation for projects (if not part of OpenStack, license model for reference plug-in must be compatible).
- Definition of a plug-in: alternate backend implementations with a common API framework that uses common _code_ to implement the API
- This expects that projects (where technically feasible) are expected to implement a plug-in or extension architecture.
- This is already in place for several projects and addresses around ecosystem support, enabling innovation
- Reference plug-ins are, by definition, the complete capability set. It is not acceptable to have “core” features that are not functional in the reference plug-in
- This will enable alternate implementations to offer innovative or differentiated features without forcing changes to the reference plug-in implementation
- This will enable the reference to expand without forcing other alternate implementations to match all features and recertify
- Vendors may substitute alternate implementations
- If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in
- If a vendor plug-in does NOT pass all relevant test then the vendor is required to include the open source reference in the implementation.
- Alternate implementations may pass any tests that make sense
- Alternate implementations should add tests to validate new functionality.
- They must have all the must-pass tests (see #10) to claim the OpenStack mark.
- OpenStack Implementations are verified by open community tests
- Vendor OpenStack implementations must achieve 100% of must-have coverage?
- Implemented tests can be flagged as may-have requires list [Joshua McKenty]
- Certifiers will be required to disclose their testing gaps.
- This will put a lot of pressure on the Tempest project
- Maintenance of the testing suite to become a core Foundation responsibility. This may require additional resources
- Implementations and products are allowed to have variation based on publication of compatibility
- Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)
- Testing must respond in an appropriate way on BOTH pass and fail (the wrong return rejects the entire suite)
- Tests can be remotely or self-administered
- Plug-in certification is driven by Tempest self-certification model
- Self-certifiers are required to publish their results
- Self-certified are required to publish enough information that a 3rd party could build the reference implementation to pass the tests.
- Self-certified must include the operating systems that have been certified
- It is preferred for self-certified implementation to reference an OpenStack reference architecture “flavor” instead of defining their own reference. (a way to publish and agree on flavors is needed)
- The Foundation needs to define a mechanism of dispute resolution. (A trust but verify model)
- As an ecosystem partner, you have a need to make a “works against OpenStack” statement that is supportable
- API consumer can claim working against the OpenStack API if it works against any implementation passing all the “must have” tests(YES)
- API consumers can state they are working against the OpenStack API with some “may have” items as requirements
- API consumers are expected to write tests that validate their required behaviors (submitted as “may have” tests)
- A subset of tests are chosen by the Foundation as “must-pass”
- An OpenStack body will recommend which tests are elevated from may-have to must-have
- The selection of “must-pass” tests should be based on quantifiable information when possible.
- Must-pass tests should be selected from the existing body of “may-pass” tests. This encourages people to write tests for cases they want supported.
- We will have a process by which tests are elevated from may to must lists
- Potentially: the User Committee will nominate tests that elevated to the board
- OpenStack Core means passing all “must-pass” tests
- The OpenStack board owns the responsibility to define ‘core’ – to approve ‘musts’
- We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
- May-have tests include items in the integrated release, but which are not core.
- Must haves – must comply with the Core criteria defined from the IncUp committee results
- Projects in Incubation or pre-Incubation are not to be included in the ‘may’ list