Totally agree with you Jorge, although I don't like the term "Dev APIs" (since developers who consume the service will interact with the Public APIs). I propose we call them Internal APIs.
Erik From: Jorge Williams <[email protected]<mailto:[email protected]>> Date: Wed, 5 Jan 2011 05:00:56 +0000 To: "<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[email protected]>> Cc: "<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[email protected]>> Subject: Re: [Openstack] [RFC] OpenStack API I think I agree with most of what you're saying, but bringing in the discussion in "the scope and projects thread" I would summarize things a little differently: "OpenStack APIs" 1. Each core project will expose one or more HTTP/RESTful interfaces for the purpose interacting with the outside world. 2. These REST interfaces may be consumed by the public (Public API), or operators (Management API). Orchestration and higher level systems should also consume these APIs. 3. Projects may also expose notification interfaces. These should also be based on HTTP/REST (Atom/PubSubHubBub). 4. The REST APIs will have a minimum set of standards and capabilities -- they will all be versioned, they should all be extensible, and support rate limiting, etc, etc. "Dev APIs" 5. Additionally, there may exist DevAPIs, these APIs are targeted exclusively to project developers 6. DevAPIs help developers build OpenStack components 7. They need not be RESTful (though they can be), they might leverage other protocols, they may be python based, whatever. 8. DevAPIs should not be exposed outside a project's boundary. For example, if nova needs to interact with swift, it should interact with swift via the OpenStack API, never the DevAPI, that's for swift devs only. -jOrGe W. On Jan 4, 2011, at 4:29 PM, <[email protected]<mailto:[email protected]>> wrote: Looks like we are converging. Summarizing: 1. OpenStack API is the Management & Control Plane for a Cloud Infrastructure built using OpenStack components. 2. It will be used by cloud service consumers & operators to build higher level systems. 3. It is REST-ful 4. It will have a programming model appropriate for the audience and their use cases 5. It will be version-ed 6. It is a lightweight framework and will have capabilities for service components to expose feature sets via declarative sets 7. (my proposal) It will be JSON/HTTP 8. (my proposal) We should have appropriate media types for the OpenStack API services (I have done it for CDMI, so have an idea how it could look like, if we decide to go this route) 9. We could propose a first iteration at the next summit 10. A first client implementation could be a CLI for an OpenStack Cloud system BTW, this is a little different than what is proposed on the OpenStack Framework Model thread. Cheers <k/> P.S : Do we already have a blueprint for this ? -------- Original Message -------- Subject: Re: [Openstack] [RFC] OpenStack API From: Jorge Williams <[email protected]<mailto:[email protected]>> Date: Tue, January 04, 2011 1:39 pm To: Vishvananda Ishaya <[email protected]<mailto:[email protected]>> Cc: "<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[email protected]>> I also agree. Just to be clear thought, we should make a distinction between internal API (devAPI) that's used by the developers of that particular service and the management API that may be used by an operator of a service OR by an orchestration service and is a proper "OpenStack API" with versioning etc. -jOrGe W. On Jan 4, 2011, at 1:05 PM, Vishvananda Ishaya wrote: Agreed, This seems like a clear distinction. On Jan 4, 2011, at 11:02 AM, John Purrier wrote: Good points, I just deleted my post as you made my points :). The “devAPI” is valuable for developers/contributors to the OpenStack services for all of the reasons Vishy stated in terms of immediacy, access, and easy evolution. This should be internal to the project. Having a CLI to drive this is a good thing. The “OpenStack API” is targeted at developers that consume the published services (such as provisioning VM’s, Virtual Volumes, Virtual Images, Virtual Networks, and Object Storage). These can also be thought of as OpenStack application developers and sysadmins. Having a CLI that can be scripted against is a good thing. For this audience there is likely a requirement in the API stack for orchestration, transactions, and concurrency that will not be exposed through a low level devAPI. -John From: [email protected]<mailto:openstack-bounces+[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Tuesday, January 04, 2011 12:37 PM To: Vishvananda Ishaya Cc: [email protected]<mailto:[email protected]> Subject: Re: [Openstack] [RFC] OpenStack API Good point - this was my concern on "REST API for developers" in the other thread. Relative stability, versioning, published API and programming models that need to be supported and deprecated systemically and so forth. Plus evolutionay concerns like extensibility, feature velocity, ... Before we even think of devAPi vs internal API, we need to be crisp and clear on "For Whom the APIs toll" ... a) Developers who develop service components <- Need access to all internals and will use python b) Cloud Platform developers who develop granular services based on the service components <- Are these the clients we are talking about ? Do they need a concise programming model and REST API ? If so, what would these actors do ? If there are two distinct constituents, with clear cut requirements and interfaces, we can work through programming models and appropriate APIs. Cheers <k/> -------- Original Message -------- Subject: Re: [Openstack] [RFC] OpenStack API From: Vishvananda Ishaya <[email protected]<mailto:[email protected]>> Date: Tue, January 04, 2011 9:32 am To: Ed Leafe <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Sure. DevAPI perhaps? Another point that might help clarify: Each component of Nova exposes an "api" to the other components in the system via python methods. You could refer to these as the "internal api" for that component. Both the OS api and the EC2 api use this internal api, for example, when they are running instance related commands. DevAPI (ReflectionAPI/EasyAPI) takes the "internal api" from all of the components and sews them up into a rest interface so they can be accessed via the cli. I think this is the "best" way for developers to prototype components and interact with the system. This is probably not the best way for clients to access the system. The "official" api exposed to clients needs to be a bit more rigorous with versioning, etc. and can lag behind the internal/dev api. The Openstack/Rackspace can continue to be the current versioned official api. I think this division gives both developers and end users their optimal use case. Vish On Jan 4, 2011, at 5:57 AM, Ed Leafe wrote: > On Jan 3, 2011, at 8:32 PM, Vishvananda Ishaya wrote: > >> I feel very strongly that we need to keep the code easy to extend and >> prototype, without forcing developers to go through the process of api specs >> and versioning. I don't think this is going to happen through the >> OpenStack/Rackspace api, due to the reasons outlined above. The idea of >> EasyAPI is simply to expose the existing apis that we have for each >> component for easy consumption. This allows us to have a simple command line >> utility to interact with the code we write for each component separately. > > Is there any chance that you could change the name to something that sounds a > little less judgmental? I.e., if it's not EasyAPI, it must be DifficultAPI! > Maybe ReflectionAPI or something that describes the approach and not an > opinion. > > > > -- Ed Leafe > > > _______________________________________________ Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached orembedded 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 [email protected]<mailto:[email protected]>, and delete the original message. Your cooperation is appreciated. ________________________________ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
