openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

I would like to present for discussion a statement on the scope and projects
that are considered core to OpenStack in the short term (2011).
Additionally, this is a proposal to "formalize" how OpenStack includes and
associates projects that are closely tied to the project but not part of the
core.

 

Why is this important to discuss? I believe it drives conversations about
what to implement (priorities), how to implement (in Python in the core,
through an extension mechanism, or via a published API). It is also
important that the community is relatively on the same page about what
OpenStack is, and what is outside the charter.

 

Once the community has reached consensus the Project Oversight Board should
review and publish as part of the overall project charter.

 

Key concepts (proposed):

 

OpenStack is scoped in the short term (ie. today and through 2011) to the
following core components (note this is subject to modification by the
Project Oversight Committee):

 

.         Cloud and Automation Infrastructure (Nova)

-   Virtual Machine Provisioning and Management (Compute)

-   Virtual Image Management and Tools (Glance)

-   Virtual Volume Provisioning and Management (Block Storage)

-   Virtual Network Provisioning and Management (Network)

 

.         Large Scale Data Storage and Processing (Swift)

-   Highly Available Object Storage

 

The core projects are under project and governance control of the OpenStack
open source project. These components will make up the OpenStack
distribution packages that can be picked up by downstream distributions
(such as Ubuntu). In order to ensure that there is ubiquitous distribution
of the core OpenStack projects the development languages/environments will
be limited to C, C++, and Python (other languages/runtimes that are
ubiquitously available times might be considered by the POC in the future).

 

OpenStack core projects will be presented as a series of services and will
follow a common and agreed to service architecture. This will include:

 

.         A public RESTful API

.         A private RESTful management API

.         Optionally, a pub/sub notification interface

.         An extension interface to allow specific service behaviors to be
plugged in

 



 

Proprietary or open source modules may be plugged into the extension
interface to provide deployment specific features and functionality. For
example: OpenStack will provide a general interface for elastic block
storage to the Compute nodes. A vendor, contractor, or hoster may plug a
specific implementation of block storage under the service, i.e. proprietary
interface to NetApp storage, and interface to Sheepdog block storage, etc.

 

These extension modules have no defined OpenStack requirements, save they
conform to the defined extension interface for the service. Language
selection, distribution models, source license, etc. are all defined and
controlled by the implementer(s).

 

Note that the "public" service API's are not necessarily exposed to
OpenStack developers directly. For instance, the programming model for Nova
will present a singular API endpoint, yet may expose Virtual Image or
Virtual Volume operations. This aggregation of API functionality should be
consistent across the OpenStack projects to allow a consistent programming
model and, ultimately, is under the direction of the POC.

 

In addition, there will be a concept of "affiliated" or "compatible"
services for OpenStack that live outside of the core projects. These will
generally be cloud services that extend the functionality of the base (core)
OpenStack distribution. It is encouraged that these services be built using
the same core service architectural concepts. Since these projects live
outside of the core OpenStack projects they have the following
characteristics:

 

1.       They are not subject to the OpenStack governance model or process.
The governance will be the responsibility of the contributor(s).

2.       The responsibility for distribution will be on the contributor(s).
These are optional OpenStack projects and may or may not be picked up by the
downstream distributions.

3.       OpenStack does not impose any language or runtime constraints on
these services. The contributors need to weigh their runtime environment
requirements against ease of development and desired ubiquity of
distribution and deployment.

 

Examples of potential services include Database, Platform, Monitoring, etc.
implementations.

 

A graphical view: