Thanks Andy ... that answers many of our questions.
I haven't had an opportunity to look at Easy API yet, but I don't think there
is any reason to break compatibility with the RS/OS API. Here's how I see the
flow ('Client' is the client-side command line tool):
1. Client determines Verb of Interest from command line ('create-instance',
'pause', 'add-ip', etc)
2. Client polls the server for WADL/JSON to get that Verb's expected parameter
list, URL template and Posting Method.
3. Client dynamically builds gflag/argparse configuration based on parameter
list
4. Remaining cmdline arguments are parsed and data types checked based by
argparse
5. The Verb's URL template is populated with arguments and submitted via
Posting Method (POST, GET, etc)
6. Results obtained ... Profit
Since the URL template came from the server as well as the Posting method it
should work fine with RS API. Even the little idiosyncratic quirks can be
handled.
If this is the approach easy-api is taking ... sounds like a great replacement
for python-cloudservers. Although I'm not convinced introspective approaches
won't require hacky tweaks, thus defeating the effort.
Certainly adding Yet Another API doesn't seem like a good idea given the
business advantages of maintaining compatibility with existing
clients/partners. Extending the current API offers a smoother migration path
for all.
I'm sure I'm missing something or just crazy in these assumptions.
Look forward to your feedback ... in the meanwhile I'll look at easy-api.
Cheers,
Sandy
________________________________
From: Andy Smith [andys...@gmail.com]
Sent: Wednesday, December 29, 2010 4:08 PM
To: Matt Dietz
Cc: Jesse Andrews; termie; Sandy Walsh; openstack@lists.launchpad.net
Subject: Re: Easy API
+openstack
On Wed, Dec 29, 2010 at 12:06 PM, Andy Smith
<andys...@gmail.com<mailto:andys...@gmail.com>> 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
<matt.di...@rackspace.com<mailto:matt.di...@rackspace.com>> 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 : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
