Open Stack

I totally agree with you towards the goal of “pure OpenStack SDKs implement the entirety of the OpenStack API”.

The development of pure-OpenStack SDK is critical for the success of OpenStack adoption and it is great to hear from Rackspace for the effort in many (OpenStack.Net, GO, PhP) and Michael (HPE) on JavaScript.

I’m wondering if we should form a Project dedicated to this task to develop and support pure-OpenStack SDK for various languages. Thoughts?

Thanks!


---
Yih Leong Sun, PhD
Senior Software Cloud Architect
Open Source Technology Center
Intel Corporation
yih.leong.sun at intel.com
+1 503 264 0610



From: Ken Perkins [mailto:ken.perkins at RACKSPACE.COM]
Sent: Thursday, June 16, 2016 10:08 AM
To: user-committee <user-committee at lists.openstack.org>
Subject: [User-committee] Rackspace Strategy on SDKs

Hey all,

I wanted to put on paper Rackspace's thoughts and plans regarding tooling for OpenStack and Rackspace clouds as we haven't been clear enough on this with the broader OpenStack community. Some quick context; I'm a Dev Manager in Developer Experience, and help manage SDK development here at Rackspace.

tl;dr: Rackspace's strategy is to build Rackspace SDKs based on pure Openstack SDKs, and avoid least-common-denominator multi-cloud libraries as much as possible in order to provide an excellent user experience.

If we go back in time, Rackspace endorsed a number of multi-cloud libraries for Rackspace customers, in addition to some in-house developed dual OpenStack/Rackspace SDKs. Fog, jclouds, and pkgcloud were all multi-cloud, while pyrax, openstack.net, php-opencloud, and gophercloud were all developed in-house with a mix of OpenStack and Rackspace capabilities.

When we looked at this holistically, it became clear this was an exceptionally confusing story for a customer trying to use these tools; it was equally bad for both Rackspace customers and Openstack customers. As a result of this we formed two opinions that have helped shape our strategy:

  1.  Distance Rackspace from multi-cloud libraries
  2.  Clearly separate OpenStack implementations from Rackspace implementations
I'll explain both of these opinions further to help understand the ramifications.

Distance Rackspace from multi-cloud libraries

Pointing users (regardless of whether they are OpenStack or Rackspace) at a multi-cloud library will never be as consistent of an experience as it would be to native tooling. There are a number of examples of why: the inability to consistently release tooling updates coordinated with major releases, inconsistency of documentation across different sdks, or existence of confusing abstractions across types of clouds. All of these can inhibit adoption and create confusion for the users who do try and use these tools.

Further, we believe that that core benefit of multi-cloud doesn't bear out in reality. There are so many differences between major cloud providers (AWS, OpenStack, Google, etc) that portability of tooling is the least of your concerns in actually migrating, and we don't believe that federating applications across clouds is sufficient justification to make the experience worse in the default case.

We haven't had a ton of traction yet on this opinion, but it's one we're trying to work towards.

Clearly separate OpenStack implementations from Rackspace implementations

In a number of our tools, the OpenStack implementation is a peer in the SDK to the Rackspace implementation. This creates a natural tension between the pure OpenStack implementation and the Rackspace one. If it's Rackspace controlled, (i.e. under our GitHub organization) does that mean we're not receptive to changes from others? How do we add maintainers when it's under our GitHub Orgs? Further, the documentation for these tools may have biases that need not be present.

To that end, we felt extracting the OpenStack capabilities and moving this code into a pure OpenStack library was a must do. We've already started this for a number of our projects: Openstack.net [1] is almost pure OpenStack now, and is in its own GitHub org. Similarly, we're working on Go [2] and PHP [3], and hope to get Ruby split out soon as well. Our python efforts are even more formalized; We contribute development resources to the python-openstacksdk project which is a python SDK within OpenStack. We want to do this for Javascript as well, but perhaps Michael Krotscheck's efforts for a Javascript SDK should be the basis for this rather than our own initiatives.

We still have more work to do here, but the goal is to have pure OpenStack SDKs implement the entirety of the OpenStack API, and then have Rackspace SDKs that separately add on top of the OpenStack SDK as appropriate for our API surface.

Closing

None of this is perfect; rather, it reflects our current thinking and how we're acting. Having a great experience for OpenStack developers can only be great for OpenStack and that aligns with our needs to serve our own customers.

Please don't hesitate to ask questions, or raise concerns.

Ken

[1] https://github.com/openstacknetsdk/openstack.net
[2] https://github.com/gophercloud/gophercloud
[3] https://github.com/php-opencloud/openstack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20160616/548f94da/attachment.html>