On Feb 11, 2014, at 3:30 PM, Jesse Noller jesse.nol...@rackspace.com wrote:
I did propose in the original thread that we join efforts: in fact, we
already have a fully functioning, unified SDK that *could* be checked in
today - but without discussing the APIs, design and other items with the
On Feb 12, 2014, at 9:07 AM, Ed Leafe e...@openstack.org wrote:
On Feb 11, 2014, at 3:30 PM, Jesse Noller jesse.nol...@rackspace.com wrote:
I did propose in the original thread that we join efforts: in fact, we
already have a fully functioning, unified SDK that *could* be checked in
I would like to point out that the unified SDK has a different target
audience from the existing clients. Application developers who want to work
with OpenStack APIs are far different from those who are trying to build
OpenStack.
For example, application developers don't know what keystone, nova,
On Wed, Feb 12, 2014 at 10:36 AM, Matthew Farina m...@mattfarina.com wrote:
I would like to point out that the unified SDK has a different target
audience from the existing clients. Application developers who want to work
with OpenStack APIs are far different from those who are trying to build
As I said last week; we’re ready to kickoff and have regular meetings for the
“unified python SDK” project. The initial meeting is scheduled on the wiki:
https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting
Date/Time: Feb. 19th - 19:00 UTC / 1pm CST
IRC channel:
Jesse,
Why not next approach:
1) Switch all clients to apiclient[1] (internal unification)
2) Unify API of all clients (external unification)
3) Unify work with keystone
4) Graduate apiclient
5) Switch all clients to apiclient lib
6) Make one simple plugable mechanism. e.g. subclass based factory
On Feb 11, 2014, at 3:02 PM, Boris Pavlovic bpavlo...@mirantis.com wrote:
Jesse,
Why not next approach:
1) Switch all clients to apiclient[1] (internal unification)
This was discussed several weeks ago here:
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024441.html
This
