In a large open source project made up of lots of interacting pieces developed by different teams, how do you decide what officially becomes a part of the core release and what stays outside? In OpenStack, a formal process of incubation helps prepare fledgling projects for integration into the main code body as they develop and mature.
A history
Two projects, Nova (compute) and Swift (object storage) were a part of OpenStack at its inception and initial release. Nova, initially developed at NASA, along with Rackspace's Swift, were merged into a single computing platform to create the initial seed of OpenStack. While meeting the needs of certain cloud computing workloads, there were still many components needed to build a complete platform, and the project grew over time.
Since the inaugural Austin release, the number of integrated projects has steadily grown, along the alphabetically-named release cycle which typically runs for six months. Glance, the OpenStack image service, was integrated at the Bexar release. A few releases passed before the next formal addition, of identity project Keystone and web user interface Horizon at the Essex release. The next release, Folsom, added networking project Neutron and block storage project Cinder.
As the project has grown and adapted, so has the process for handling the addition of new projects. The telemetry project, Ceilometer, and orchestration project, Heat, were both brought into an incubation process in the Grizzly release before officially becoming integrated at the next release, Havana. During this period, the incubation process was more stringently formalized by a committee tasked with updating the process, which more carefully defined what incubation, integration, and core projects would mean in the context of OpenStack and what tests would determine when a project was ready for each stage.
More recently, database service Trove and bare metal project Ironic were incubated for the Havana release, but only Trove has since made it out of incubation at the Icehouse release. Icehouse saw the addition of queue service Marconi and Hadoop-facilitator Sahara to incubation, with Sahara set make it into integration at the upcoming Juno release. And the Juno development cycle, our current cycle, has added a key management service, Barbican, and DNS as a service through Designate.
Incubation today
So what does all of this mean? What is the incubation process today, and how does a project accomplish the things necessarily to graduate?
Today, the steps are clearly laid out, although there is still plenty of room for interpretation by the Technical Committee, who are charged with determining how well each project stacks up against the criteria. To be ready for incubation, a project must meet several criteria.
- The project should have a clear scope, which advances OpenStack and does not unnecessarily duplicate the scope of an existing project, but rather, should utilize functionality in other OpenStack projects to the extent possible.
- The project should be reasonably mature, with an active team of developers and no major rewrites planned.
- The project should adhere to the existing process under which existing projects fall, including hosting location, use of git as a version control system, an established review system like that used of other OpenStack project, use the official OpenStack listserv for communcation, and similar traits.
- The project should have a developed REST API which is reasonbly stable, a JSON entity representation, and a Python client library.
- The project should be buildable through devstack to match other projects' QA requirements.
- The project should have documentation, minimally for developers, and the API must be documented as well.
- The project should adhere to the same legal structure as other OpenStack projects, using the Apache License v2 and following other applicable legal rules to prevent any barriers to future use of included code or names.
To graduate to integration, similar criteria are used with more stringent evaluation. The way that these criteria might be applied to any given project of course will vary, but they set a standard to make sure that projects are ready, and have a clear process, to be included in the definition of what may live under the OpenStack name.
Comments are closed.