On Dec 31, 2010, at 6:45 AM, Ewan Mellor wrote: 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).
I think the idea here is that if we have performance issues we could write extension modules in C / C++. I agree it's probably not a good idea to implement an entire service in C. 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. REST allows our services to be autonomous and loosely coupled, it also allows our customers to integrate with us easily. I think it's appropriate for our service model to use REST by default. We should consider situations where that's not the right model on a case-by-case basis. 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....@lists.launchpad.net<mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net> [mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net] On Behalf Of John Purrier Sent: 30 December 2010 21:00 To: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 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 <image001.jpg> 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: <image002.jpg> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
