|
|
| (9 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | == PRELIMINARY PAGE FOR REVIEW AT Oct 4th 2013 Board Meeting
| + | This content has now been moved into Gerrit. Please [https://github.com/openstack/defcore/blob/master/doc/source/process/CoreDefinition.rst click here] to view it or go to: |
| | | | |
| − | * DRAFT *
| + | https://github.com/openstack/defcore/blob/master/doc/source/process/CoreDefinition.rst |
| | | | |
| − | The following list represents the "guiding principles" used by the Foundation Board to determine how commercial implementations of OpenStack can be granted use of the trademark.
| + | [[category: InteropWG]] |
| − | [[File:Core flow.png|500px|thumb|right]] | |
| − | | |
| − | # 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
| |
| − | # 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
| |
