<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1180697113;
        mso-list-template-ids:1047670938;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I totally agree with you towards the goal of “</span><span style="font-family:"Calibri",sans-serif">pure OpenStack SDKs implement the entirety of the OpenStack
 API”.</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’m wondering if we should form a Project dedicated to this task to develop and support pure-OpenStack SDK for various languages. Thoughts?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">---<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Yih
<b><u>Leong</u></b> Sun, PhD <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Senior Software Cloud Architect<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Open Source Technology Center<br>
Intel Corporation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">yih.leong.sun@intel.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">+1 503 264 0610<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="_____replyseparator"></a><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ken Perkins [mailto:ken.perkins@RACKSPACE.COM]
<br>
<b>Sent:</b> Thursday, June 16, 2016 10:08 AM<br>
<b>To:</b> user-committee <user-committee@lists.openstack.org><br>
<b>Subject:</b> [User-committee] Rackspace Strategy on SDKs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Hey all,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">I wanted to put on paper Rackspace's thoughts and plans regarding tooling for OpenStack and Rackspace clouds as
<i>we haven't been clear enough on this with the broader OpenStack community</i>. Some quick context; I'm a Dev Manager in Developer Experience, and help manage SDK development here at Rackspace.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif">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.</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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:</span><o:p></o:p></p>
</div>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style="font-family:"Calibri",sans-serif">Distance Rackspace from multi-cloud libraries</span><o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style="font-family:"Calibri",sans-serif">Clearly separate OpenStack implementations from Rackspace implementations</span><o:p></o:p></li></ol>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">I'll explain both of these opinions further to help understand the ramifications.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif">Distance Rackspace from multi-cloud libraries</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">We haven't had a ton of traction yet on this opinion, but it's one we're trying to work towards.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif">Clearly separate OpenStack implementations from Rackspace implementations</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif">Closing</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Please don't hesitate to ask questions, or raise concerns.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Ken</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">[1] <a href="https://github.com/openstacknetsdk/openstack.net">
https://github.com/openstacknetsdk/openstack.net</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">[2] <a href="https://github.com/gophercloud/gophercloud">
https://github.com/gophercloud/gophercloud</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">[3] <a href="https://github.com/php-opencloud/openstack">
https://github.com/php-opencloud/openstack</a></span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>