summaryrefslogtreecommitdiffstats
path: root/reference/incubation-integration-requirements.rst
blob: c68f1079704943b7d904645d1e1eb50ffbb8ce77 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
===========================================================
 Minimal Requirements for Incubation and Integrated Status
===========================================================

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

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.