openstack team mailing list archive

[Andy Smith <andyster@xxxxxxxxx>]

I would quickly say this should be on the wiki so that it can be kept up to
date as it is discussed, it is a document not an email.

On Thu, Dec 30, 2010 at 12:59 PM, John Purrier <john@xxxxxxxxxxxxx> wrote:

> 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:
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>