On Sep 5, 2014, at 10:21 AM, Brian Curtin <br...@python.org> wrote:

> Hi all,
> Between recent IRC meetings and the mid-cycle operators meetup, we've
> heard things ranging from "is the SDK project still around" to "I
> can't wait for this." I'm Brian Curtin from Rackspace and I'd like to
> tell you what the python-openstacksdk [0][1] project has been up to
> lately.
> After initial discussions, meetings [2], and a coordination session in
> Atlanta, a group of us decided to kick off a project to offer a
> complete Software Development Kit for those creating and building on
> top of OpenStack. This project aims to offer a one-stop-shop to
> interact with all of the parts of an OpenStack cloud, either writing
> code against a consistent set of APIs, or by using command line tools
> implemented on those APIs [3], with concise documentation and examples
> that end-users can leverage.
> From a vendor perspective, it doesn't make sense for all of us to have
> our own SDKs written against the same APIs. Additionally, every
> service having their own client/CLI presents a fragmented view to
> consumers and introduces difficulties once users move beyond
> involvement with one or two services. Beyond the varying dependencies
> and the sheer number of moving parts involved, user experience is not
> as welcoming and great as it should be.
> We first built transport and session layers based on python-requests
> and Jamie Lennox's Keystone client authentication plugins (minus
> compatibility cruft). The service resources are represented in a base
> resource class, and we've implemented resources for interacting with
> Identity, Object-Store, Compute, Image, Database, Network, and
> Orchestration APIs. Expanding or adding support for new services is
> straightforward, but we're thinking about the rest of the picture
> before building out too far.
> This resource layer may be slightly raw if you're looking at it as a
> consumer, and not likely what you'd want in a full scale application.
> Now that we have these resources exposed to work with, we're looking
> upward to think about how an end-user would want to interact with a
> service. We're also moving downward and looking at what we want to
> provide to command line interfaces, such as easier access to the
> JSON/dicts (as prodded by Dean :).
> Overall, we're moving along nicely. While we're thinking about these
> high-level/end-user views, I'd love to know if anyone has any thoughts
> there. For example, what would the ideal interface to your favorite
> service look like? As things are hacked out, we'll share them and
> gather as much input as we can from this community as well as the
> users.
> If you're interested in getting involved or have any questions or
> comments, we meet on Tuesdays at 1900 UTC in #openstack-meeting-3, and
> all of us hang out in #openstack-sdks on Freenode.
> As for who's involved, we're on stackalytics [4], but recently it has
> been Terry Howe (HP), Jamie Lennox (Red Hat), Dean Troyer (Nebula),
> Steve Lewis (Rackspace), and myself.
> Thanks for your time
> [0] https://github.com/stackforge/python-openstacksdk
> [1] https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK
> [2] http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/
> [3] OpenStackClient is planning to switch to using the Python SDK
> after the interfaces have stabilized.
> [4] 
> http://stackalytics.com/?project_type=stackforge&module=python-openstacksdk&release=all

I’m glad to hear the project is still moving along — I didn’t mean to give the 
impression that it might not be, just that I hadn’t been able to follow as 
closely as I’d liked so I wasn’t sure where things stood. I hope to be more 
involved for Kilo.


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to