openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

Hi Ewan,

 

Thanks for the comments. Frankly, C/C++ as acceptable core service languages
is driven less by the languages themselves and more by the required runtime
environments necessary to package and distribute. As Thierry has pointed
out, we have shell scripts and other things written in other languages, this
is not a religious statement about language, but how best to easily package
and get wide distribution of the core components.

 

Jorge has weighed in on the RESTful motivation, I would like to see this as
a stake in the ground with exceptions and possible modification to the
approach taken up when necessary by the community and the Oversight
Committee.

 

I agree with your two bulleted points, and will update the post to include.
This overlaps to some degree some of the existing public statements on the
wiki but are important enough to re-iterate.

 

Thanks,

 

-John

 

From: Ewan Mellor [mailto:Ewan.Mellor@xxxxxxxxxxxxx] 
Sent: Friday, December 31, 2010 6:45 AM
To: John Purrier; openstack@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Openstack] [RFC] OpenStack Scope and projects

 

Why include C / C++ as "blessed" languages, when we're not using them at the
moment?  I see no reason that they should be called out any more than any
other mainstream language (and frankly, I'll be saddened if we start writing
lots of C++, at least for the current proposed projects, because I don't
think it would be appropriate).

 

Why specify that both public and private APIs must be RESTful?  I would
rather that people thought about the right interaction model for their
project, rather than being RESTful by fiat.  I think that RESTful is the
right choice for the public Nova, Glance, and Swift APIs, but it won't
always be the right model for all APIs in the future.

 

In terms of inclusion or affiliation criteria, I think we should include the
following:

 

.         The software should be designed for scale.  OpenStack technologies
and affiliates should be usable at datacenter scale, otherwise they don't
belong in this project.  We could add a stronger statement here about being
"horizontally scalable" or "designed without single points of failure", but
I'm not sure whether that's a good idea or whether it would be more
restrictive than we want.

.         The software should work with all the other existing OpenStack
components (or at least it needs to be strongly flagged if they don't).  For
example, a storage component should work with all hypervisors.  This might
be a problem for Sheepdog, which advertises itself as KVM-specific, and
while I don't want to reject affiliation just because of that, I think we
should be pushing people so that we can swap components in and out at will.
I don't want OpenStack to be a mishmash of technologies, some of which work
together, some of which don't.

 

Cheers,

 

Ewan.

 

From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of John Purrier
Sent: 30 December 2010 21:00
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: [Openstack] [RFC] OpenStack Scope and projects

 

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: