<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">The End User working group is being described at https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is establishing
the structure.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">This page covers how to get involved…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Tim<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Brad Topol [mailto:btopol@us.ibm.com]
<br>
<b>Sent:</b> 08 September 2014 19:50<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] Kilo Cycle Goals Exercise<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Monty,</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">+1!! I fully agree!! How can I help :-)? Can we dedicate some design summit sessions to this topic? Ideally, having some stakeholder driven sessions where we can hear about the user experiences
issues causing the most pain would be a good start to get this to become a focus area.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Thanks,</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Brad</span> <br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif""><br>
<br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet: <a href="mailto:btopol@us.ibm.com">btopol@us.ibm.com</a><br>
Assistant: Kendra Witherspoon (919) 254-0680</span> <br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,
</span><br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">09/07/2014 08:15 PM</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">Re: [openstack-dev] Kilo Cycle Goals Exercise</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="3" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<tt><span style="font-size:10.0pt">On 09/03/2014 08:37 AM, Joe Gordon wrote:</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> As you all know, there has recently been several very active discussions</tt><br>
<tt>> around how to improve assorted aspects of our development process. One idea</tt><br>
<tt>> that was brought up is to come up with a list of cycle goals/project</tt><br>
<tt>> priorities for Kilo [0].</tt><br>
<tt>></tt><br>
<tt>> To that end, I would like to propose an exercise as discussed in the TC</tt><br>
<tt>> meeting yesterday [1]:</tt><br>
<tt>> Have anyone interested (especially TC members) come up with a list of what</tt><br>
<tt>> they think the project wide Kilo cycle goals should be and post them on</tt><br>
<tt>> this thread by end of day Wednesday, September 10th. After which time we</tt><br>
<tt>> can begin discussing the results.</tt><br>
<tt>> The goal of this exercise is to help us see if our individual world views</tt><br>
<tt>> align with the greater community, and to get the ball rolling on a larger</tt><br>
<tt>> discussion of where as a project we should be focusing more time.</tt><br>
<br>
<tt>If I were king ...</tt><br>
<br>
<tt>1. Caring about end user experience at all</tt><br>
<br>
<tt>It's pretty clear, if you want to do things with OpenStack that are not </tt>
<br>
<tt>running your own cloud, that we collectively have not valued the class </tt><br>
<tt>of user who is "a person who wants to use the cloud". Examples of this </tt><br>
<tt>are that the other day I had to read a section of the admin guide to </tt><br>
<tt>find information about how to boot a nova instance with a cinder volume </tt>
<br>
<tt>attached all in one go. Spoiler alert, it doesn't work. Another spoiler </tt>
<br>
<tt>alert - even though the python client has an option for requesting that </tt>
<br>
<tt>a volume that is to be attached on boot be formatted in a particular </tt><br>
<tt>way, this does not work for cinder volumes, which means it does not work </tt>
<br>
<tt>for an end user - EVEN THOUGH this is a very basic thing to want.</tt><br>
<br>
<tt>Our client libraries are clearly not written with end users in mind, and </tt>
<br>
<tt>this has been the case for quite some time. However, openstacksdk is not </tt>
<br>
<tt>yet to the point of being usable for "end users" - although good work is </tt>
<br>
<tt>going on there to get it to be a basis for an end user python library.</tt><br>
<br>
<tt>We give deployers so much flexibility, that in order to write even a </tt><br>
<tt>SIMPLE program that uses OpenStack, an end user has to know generally </tt><br>
<tt>four of five pieces of information to check for that are different ways </tt>
<br>
<tt>that a deployer may have decided to do things.</tt><br>
<br>
<tt>Example:</tt><br>
<br>
<tt> - As a user, I want a compute instance that has an IP address that can </tt>
<br>
<tt>do things.</tt><br>
<br>
<tt>WELL, now you're screwed, because there is no standard way to do that. </tt><br>
<tt>You may first want to try booting your instance and then checking to see </tt>
<br>
<tt>if nova returns a network labeled "public". You may get no networks. </tt><br>
<tt>This indicates that your provider decided to deploy neutron, but as part </tt>
<br>
<tt>of your account creation did not create default networks. You now need </tt><br>
<tt>to go create a router, network and port in neutron. Now you can try </tt><br>
<tt>again. Or, you may get networks back, but neither of them are labeled </tt><br>
<tt>"public" - instead, you may get a public and a private address back in </tt><br>
<tt>the network labeled private. Or, you may only get a private network </tt><br>
<tt>back. This indicates that you may be expected to create a thing called a </tt>
<br>
<tt>"floating-ip". First, you need to verify that your provider has </tt><br>
<tt>installed the floating-ip's extension. If they have, then you can create </tt>
<br>
<tt>a floating-ip and attach it to your host. NOW - once you have those </tt><br>
<tt>things done, you need to connect to your host and verify that its </tt><br>
<tt>outbound networking has not been blocked by a thing called security </tt><br>
<tt>groups, which you also may not have been expecting to exist, but I'll </tt><br>
<tt>stop there, because the above is long enough.</tt><br>
<br>
<tt>Every. Single. One. Of. Those. Cases. is real and has occurred across </tt><br>
<tt>only the two public openstack clouds that infra uses. That means that </tt><br>
<tt>our provisioning code takes every single one of them in to account, and </tt>
<br>
<tt>anyone who writes code that wants to get a machine to use must take them </tt>
<br>
<tt>all in to account or else their code is buggy.</tt><br>
<br>
<tt>That's RIDICULOUS. So we should fix it. I'd say we should fix it by </tt><br>
<tt>removing 1000% of the choices we've given deployers in this case, but I </tt>
<br>
<tt>won't win there. So how about let's make at least one client library </tt><br>
<tt>that encodes all of the above logic behind some simple task oriented API </tt>
<br>
<tt>calls? How about we make that library not something which is just a </tt><br>
<tt>repackaging of requests that does not contain intelligent, but instead </tt><br>
<tt>something that is fundamentally usable. How about we have synchronous </tt><br>
<tt>versions of all calls that do the polling and error checking. (if you </tt><br>
<tt>attach a cinder volume to a nova instance, apparently, you need to </tt><br>
<tt>continually re-fetch the volume from cinder and check its "attachments" </tt>
<br>
<tt>property to see when the attach actually happens, because even though </tt><br>
<tt>there is a python library call to do it, it's an async operation and </tt><br>
<tt>there is no status field field to check, nor is there any indication </tt><br>
<tt>that the operation is async, so when the call returns, the volume may or </tt>
<br>
<tt>may not be attached.)</tt><br>
<br>
<tt>This client library should contain exactly ZERO admin functions, because </tt>
<br>
<tt>hopefully the number of people running OpenStack clouds will be smaller </tt>
<br>
<tt>than the number of people who are using OpenStack clouds at some point - </tt>
<br>
<tt>and exposing admin functionality to an end user who can never use it is </tt>
<br>
<tt>just mean. Especially when that functionality is something that the end </tt>
<br>
<tt>user wishes he could do (like create non-insance flavor definitions) but </tt>
<br>
<tt>never will be allowed to do (because someone somewhere thinks that </tt><br>
<tt>scheduling compute resources only be RAM size is userful)</tt><br>
<br>
<tt>If I don't do anything at all next cycle, I will see the above fixed. </tt><br>
<tt>Because it's embarrassing. Seriously. Try to use OpenStack from python </tt><br>
<tt>some time. I dare you.</tt><br>
<br>
<tt>2. Less features, more win</tt><br>
<br>
<tt>In a perfect world, I'd argue that we should merge exactly zero new </tt><br>
<tt>features in all of kilo, and instead focus on making the ones we have </tt><br>
<tt>work well. Some of making the ones we have work well may wind up feeling </tt>
<br>
<tt>just like writing features, as I imagine some of our features are </tt><br>
<tt>probably only half features in the first place.</tt><br>
<br>
<tt>3. Deleting things</tt><br>
<br>
<tt>We should delete a bunch of code. Deleting code is fun, and it makes </tt><br>
<tt>your life better, because it means you have less code. So we should </tt><br>
<tt>start doing it. In particular, we should look for places where we wrote </tt>
<br>
<tt>something as part of OpenStack because the python community did not have </tt>
<br>
<tt>a thing already, but now there is one. In those cases, we should delete </tt>
<br>
<tt>ours and use theirs. Or we should contribute to theirs if it's not quite </tt>
<br>
<tt>good enough yet. Or we should figure out how to make more of the oslo </tt><br>
<tt>libraries things that can truly target non-OpenStack things.</tt><br>
<br>
<tt>Between 2 and 3, maybe we can make a kilo release that has a net </tt><br>
<tt>negative SLOC count. But, honestly, screw 2 and 3 - let's all just work </tt>
<br>
<tt>on 1.</tt><br>
<br>
<tt>Monty</tt><br>
<br>
<tt>_______________________________________________</tt><br>
<tt>OpenStack-dev mailing list</tt><br>
<tt><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></tt><br>
</span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><span style="font-size:10.0pt">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
</span><o:p></o:p></p>
</div>
</div>
</body>
</html>