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