governance/reference/incubation-integration-requirements.rst
Zane Bitter 523376160d Note that the old incubation/graduation process is obsolete
The link to the page containing the historical incubation/graduation
requirements is labelled "Requirements for previously-used
incubation/integration process", but the document itself contained no
indication that the content was obsolete.

Add a note indicating the status and linking to the current process.

Change-Id: I51154558a76cda7be5eb8635c9fc938fe132e082
2018-05-17 12:28:29 -04:00

226 lines
8.8 KiB
ReStructuredText

===========================================================
Minimal Requirements for Incubation and Integrated Status
===========================================================
.. note:: The process described here is obsolete.
This document is retained only for historical reference. New projects seeking
to become part of OpenStack should refer to the
:doc:`new-projects-requirements` instead.
Incubation
==========
The TC will evaluate the project scope and its complementarity with existing
integrated projects and other official programs, look into the project
technical choices, and check a number of requirements, including (but not
limited to):
Scope
-----
* Project must have a clear and defined scope.
* Project's scope should represent a measured progression for OpenStack as a
whole.
* Project should not inadvertently duplicate functionality present in other
OpenStack projects. If they do, they should have a clear plan and timeframe
to prevent long-term scope duplication.
* Project should leverage existing functionality in other OpenStack projects
as much as possible
Maturity
--------
* Project should have an active team of contributors
* Project should not have a major architectural rewrite planned
Process
-------
* Project must be hosted under stackforge (and therefore use git as its VCS)
* Project must obey OpenStack coordinated project interface (such as tox,
pbr, global-requirements...)
* Project should use oslo libraries or oslo-incubator where appropriate
* If project is not part of an existing program, it needs to file for a new
program concurrently with the Incubation request, and fill the corresponding
requirements.
* Project must have a well-defined core review team, with reviews distributed
amongst the team (and not being primarily done by one person)
* Reviews should follow the same criteria as OpenStack projects (2 +2s
before +A)
* Project should use the official openstack lists for discussion
API
---
* Project APIs should be reasonably stable
* Project must have a REST API with at least a JSON entity representation
* Project must have a Python client library API for its REST API
* API service is made available as a WSGI application
QA
--
* Project must have a basic devstack-gate job set up
Documentation / User support
----------------------------
* Project must have docs for developers who want to contribute to the project
* Project should have API documentation for devs who want to add to the API,
updated when the code is updated
Legal requirements
------------------
* Project must be licensed under the Apache License v2
* Project must have no library dependencies which effectively restrict how
the project may be distributed or deployed [1]_
* All contributors to the project must have signed the CLA
* Project must have no known trademark issues [2]_
.. [1] https://wiki.openstack.org/wiki/LegalIssuesFAQ#Licensing_of_library_dependencies
.. [2] https://wiki.openstack.org/wiki/LegalIssuesFAQ#New_Project_Names
Graduation to integrated
========================
At the end of every cycle, incubated projects go through a graduation review
to check if they are ready to be made an integral part of the next development
cycle and be included in the next OpenStack integrated release. The TC will
evaluate the technical maturity of the project and check a number of
requirements, including (but not limited to):
Scope
-----
* Project must not duplicate functionality present in other OpenStack projects,
unless the project has intentionally done so with the intent of replacing it.
* In the case that a project has intentionally duplicated functionality of
another project, or portion of a project, the new project must reach a level
of functionality and maturity such that we are ready to deprecate the old
code and remove it after a well defined deprecation cycle. The deprecation
plan agreed to by the PTLs of each affected project, including details for
how users will be able to migrate from the old to the new, must be submitted
to the TC for review as a part of the graduation review.
Maturity
--------
* Project must have a large and diverse team of contributors
* Project must have completed integration work with other integrated
projects, as communicated by the TC when accepted into incubation (that
includes Dashboard integration if applicable)
Process
-------
* Project must have a diverse core reviewers team (more than 4 people)
* Core reviewers must enforce a minimum of 2 +2s before accepting a change
* Project should have engaged with marketing team to check suitable official
name
* Project must use OpenStack task, defect and design tracker(s)
QA
--
* Project must have a devstack-gate job running. This gate job should install
the project using devstack and then run tempest tests. This job should run
and vote in the check and gate pipelines for the project. It is*not* required
that this job is running for the projects it depends on. This demonstrates
that it would be easy to add the project to the integrated gate after
graduation.
* Project must have decent unit test and functional tests coverage
* Project must be compatible with all currently OpenStack-supported versions
of Python
* Project should have a decent record of triaging incoming bugs
Documentation / User support
----------------------------
* Project must have end-user docs such as API use, CLI use, Dashboard use
* Project should have installation docs providing install/deployment in an
integrated manner similar to other OpenStack projects, including
configuration reference information for all options
* Project should have a proven history of providing user support (on the
openstack@ mailing list and on Ask OpenStack)
Release management / Security
-----------------------------
* Project must have followed at least two common milestones (follow the common
cycle at least since X-2)
* Project must have had at least one of their milestones handled by the
release management team (at least the X-3 milestone)
* Project must provide a 2+ person team that will handle the project specific
vulnerability process [3]_
.. [3] https://wiki.openstack.org/wiki/Vulnerability_Management
First Integrated Cycle Expectations
===================================
In the release cycle after the project has graduated, the TC expects the project
to reach a level of maturity for its first integrated release. In order for the
project to graduate, the TC will need to be confident that the project will
reach that level of maturity in the time allowed.
API
---
* The REST API must be declared stable and the project must commit to
maintaining backwards compatibility
* If the project has resources which would make sense to provision
via a Heat template, then the project should have Heat integration
which enables this
* If the project has functionality which would make sense to be
available in the Horizon dashboard, then the project should ensure
that integration exists
* If the project has resources which could be metered, then the project
should expose methods that would allow Ceilometer to retrieve these
metrics
* The lifecycle of resources managed by the project should be externalized
via notifications so that they can be consumed by other integrated
projects
Upgrade
-------
Seamless upgradability of OpenStack components remains the most
requested feature by deployers and operators. Once a deployer of
OpenStack has installed a cloud, there is an implicit expectation that
it can be upgraded in place on the existing hardware without creating
downtime for any of the active resources that the cloud manages.
Note: at this point in time we still consider it acceptable to require
downtime of the API / control plane for upgrade, though encourage
projects to develop ways to reduce or eliminate that need.
As such, we expect projects to have a path for inplace upgrading from:
* one stable release to the next stable release (i.e. stable/havana =>
stable/icehouse)
* from the most recent stable branch to upstream master
(i.e. stable/icehouse => master during the Juno development cycle)
* within points in master (i.e. from a commit that merged to the
master branch two weeks ago, to the latest commit on the master
branch). This is for supporting deployers who wish to continuously
deploy their OpenStack clouds.
This requirement becomes relevant after the first stable release that
a project ships in, however projects are encouraged to incorporate a
culture of upgradability early in their project lifecycle.
In place upgrade also applies when migrating functionality out of one
project into another, as in nova-volume => cinder, nova-network =>
neutron, nova-baremetal => ironic, and/or nova-scheduler -> gantt.
QA
--
* The project should prepare upgrade testing (currently grenade) during
the first integrated cycle so that it is ready to enable upgrade testing
jobs shortly after its first integrated release.