I can create wiki pages, where should they live?
John From: Andy Smith [mailto:andys...@gmail.com] Sent: Thursday, December 30, 2010 3:20 PM To: John Purrier Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [RFC] OpenStack Scope and projects 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
