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 J. > > 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: openstack-bounces+john=openstack....@lists.launchpad.net > [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] On Behalf > Of ksan...@doubleclix.net > Sent: Tuesday, January 04, 2011 12:37 PM > To: Vishvananda Ishaya > Cc: openstack@lists.launchpad.net > 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 <vishvana...@gmail.com> > Date: Tue, January 04, 2011 9:32 am > To: Ed Leafe <e...@leafe.com> > Cc: openstack@lists.launchpad.net > > 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 > 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
