Latest revision as of 10:04, 24 January 2017

{{{header}}}

{{{body}}}

Governance/Proposed/2011 Charter and Scope

Time: <<DateTime(2011-01-14T14:43:59-0500)>>

Drafter: JohnPurrier

Drafters Email: <<MailTo(john AT openstack DOT org)>>

Status: Proposed to the POC

OpenStack 2011 Charter and Scope

This is a proposal for defining 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? It drives conversations about what to implement (priorities), how to implement (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.

This has been reviewed by the community and updated from feedback on the OpenStack mailing list.

It is expected that over time the OpenStack project will expand to include other elements critical to cloud deployments, these elements will be discussed via the community and considered by the POC.

Key concepts

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

Cloud Compute and Automation Infrastructure

­Virtual Machine Provisioning and Management (Nova)<
>
Virtual Image Management and Tools (Glance)<
>
Virtual Volume Provisioning and Management (currently part of Nova)<
>
Virtual Network Provisioning and Management (currently part of Nova)<
>

Large Scale Data Storage and Manipulation

Highly Available Object Storage (Swift)<
>

The core projects are under project and governance control of the OpenStack open source project. This is intended to be a stake in the ground; additional projects may be added to OpenStack through consideration by the Project Policy Board (PPB). These core components will make up the OpenStack distribution packages that can be picked up by downstream distributions (such as Ubuntu). In addition to pushing OpenStack through established distributions the project will also make direct downloads available that may include distribution targeted packages and source packages that are OS and distribution agnostic.

In order to ensure that there is ubiquitous distribution of the core OpenStack projects the development languages/environments and libraries must be widely and freely available. (Specific languages/runtimes that are ubiquitously available can be proposed and will be considered by the PPB).

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 public RESTful management API that is optionally protected via ACL/permissions.
• Optionally, a notification interface, such as pub/sub
• An extension interface to allow specific service behaviors to be plugged in

attachment:ServiceFramework.jpg

Within the OpenStack software projects, there may be multiple implementations of core components (e.g. networking models and components).

In addition, OpenStack core projects should generally meet criteria that makes them relevant for the overall project mission:

• The software should be designed for scale. OpenStack technologies should be usable at datacenter scale
• The software should work with the other existing OpenStack components or needs to be strongly flagged if it does not. For example, a storage component should work with all hypervisors. For the most part, the software should be developed so that users can swap components in and out at will.

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 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 may not necessarily be exposed to OpenStack clients directly. For instance, the programming model for Nova may present a singular API endpoint, but also expose multiple service operations such as Virtual Images or Virtual Volumes. 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.

Affiliated services

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). However, any project that aspires to, or may become, a core service in the future should conform to the standard OpenStack development, project management, and governance processes. This allows easy transition from “affiliated” to “core” project status.
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. Projects may propose that they be hosted and linked to the core OpenStack projects, this will be evaluated by the POC.
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.

attachment:CharterDiagram.pdf