+openstack On Wed, Dec 29, 2010 at 12:06 PM, Andy Smith <[email protected]> wrote:
> Heya Matt, > > I was intending on writing an email to the mailing list about it (so I'll > just CC it), was just going over tone with the Anso team first since I tend > to come off a bit antagonistic. > > The short summary is that we wanted to return "hackability" to the project, > as developers the move towards API compatibility has slowly removed most of > the tools we had in place to test out new features as they were being worked > on, so in that way the reflection api, self-registration of services, > command-line tool and general simplicity (you can explain how everything > works in just a few sentences) are a solution. > > Part of that hackability also meant hackability for third-parties, we > wanted developers to be able to add functionality to Nova without having to > go through the Nova review process and even be able package that > functionality separately, this is an obvious goal for any large entity > using openstack internally where they have additional changes to make to > customize their deployment. > > Easy API makes up a good basis for extensibility of the project over time. > > The existing APIs are still necessary to serve their purpose which is > translating the intents defined by existing specifications/implementations > to tasks that make sense for Nova, and should it be desirable those > interfaces can easily be built on top of and decoupled (due to the delegated > auth pattern) from the Easy API, the EasyCloudTestCase gives a decent > example of how such a thing could be done. > > In my personal opinion I see the two existing API implementations as > 'compatibility' APIs where as Easy API is a direct API and much easier to > understand because of it. > > The relevant blueprint (read the spec, obvs): > https://blueprints.launchpad.net/nova/+spec/easy-api > > --andy > > On Wed, Dec 29, 2010 at 11:20 AM, Matt Dietz <[email protected]>wrote: > >> Hey guys, >> >> I was wondering if you could answer a few questions? I get the argument >> that EC2 and eucatools suck, and that the OS API is incomplete/unstable. >> What prompted you starting down the Easy API path? Subsequently, what issues >> are you hoping to solve with it? From what I can see, it's the >> WADL-like/reflection interface that seems to be the driving force. Is this >> correct? >> I'm curious mostly because a lot of effort has been expended with the goal >> of making the existing OS API the canonical one. I'm fine with a better >> effort, but I've been operating in accordance with the internal goal of >> making it work 100% like the Rackspace API so all existing bindings will >> "just work" if someone cares to try out Openstack. Obviously we can't >> continue working on parallel paths because we'll just end up fracturing the >> API user-base until we can decide which API is going to stick. >> I'd like to get the discussion started, and I'll be glad to take it to the >> blueprint (since I see you made one as of 18 hours ago) or IRC. >> >> Thanks, >> >> Matt >> > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
