[openstack-dev] a "common" client library

Sean Dague sean at dague.net
Sat Jan 18 15:48:07 UTC 2014

On 01/18/2014 01:06 AM, Robert Collins wrote:
> On 17 January 2014 09:22, Renat Akhmerov <rakhmerov at mirantis.com> wrote:
>> Since it’s pretty easy to get lost among all the opinions I’d like to
>> clarify/ask a couple of things:
>> Keeping all the clients physically separate/combining them in to a single
>> library. Two things here:
>> In case of combining them, what exact project are we considering? If this
>> list is limited to core projects like nova and keystone what policy could we
>> have for other projects to join this list? (Incubation, graduation,
>> something else?)
>> In terms of granularity and easiness of development I’m for keeping them
>> separate but have them use the same boilerplate code, basically we need a
>> OpenStack Rest Client Framework which is flexible enough to address all the
>> needs in an abstract domain agnostic manner. I would assume that combining
>> them would be an additional organizational burden that every stakeholder
>> would have to deal with.
>> Has anyone ever considered an idea of generating a fully functional REST
>> client automatically based on an API specification (WADL could be used for
>> that)? Not sure how convenient it would be, it really depends on a
>> particular implementation, but as an idea it could be at least thought of.
>> Sounds a little bit crazy though, I recognize it :).
> Launchpadlib which builds on wadllib did *exactly* that. It worked
> fairly well with the one caveat that it fell into the ORM trap - just
> in time lookups for everything with crippling roundtrips.

-1 if the answer to anything is WADL. It's terrible, and an abandoned
sun rfc at this point. We've got some real progress in getting JSON
schema in place in Nova (for validation, but it's incremental steps, and
good ones), which I think is much more fruitful.

I also think auto generated clients have a lot of challenges in the same
way that full javascript pages in browsers have. If you screw up in a
subtle way you can just completely disable your clients from connecting
to your server entirely (or block them from using bits of the lesser
used function path because a minor bit of schema fat fingered). So
without a ton of additional verification on that path, I wouldn't want
that anywhere near openstack. Especially with vendor extensions, which
mean that enabling a network driver might break all your clients.


Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140118/ec2aaba9/attachment.pgp>

More information about the OpenStack-dev mailing list