<font size=2 face="sans-serif">Monty,</font>
<br>
<br><font size=2 face="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.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
<br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Kendra Witherspoon (919) 254-0680</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Monty Taylor <mordred@inaugust.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">09/07/2014 08:15 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
Kilo Cycle Goals Exercise</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 09/03/2014 08:37 AM, Joe Gordon wrote:<br>
> As you all know, there has recently been several very active discussions<br>
> around how to improve assorted aspects of our development process.
One idea<br>
> that was brought up is to come up with a list of cycle goals/project<br>
> priorities for Kilo [0].<br>
><br>
> To that end, I would like to propose an exercise as discussed in the
TC<br>
> meeting yesterday [1]:<br>
> Have anyone interested (especially TC members) come up with a list
of what<br>
> they think the project wide Kilo cycle goals should be and post them
on<br>
> this thread by end of day Wednesday, September 10th. After which time
we<br>
> can begin discussing the results.<br>
> The goal of this exercise is to help us see if our individual world
views<br>
> align with the greater community, and to get the ball rolling on a
larger<br>
> discussion of where as a project we should be focusing more time.<br>
<br>
If I were king ...<br>
<br>
1. Caring about end user experience at all<br>
<br>
It's pretty clear, if you want to do things with OpenStack that are not
<br>
running your own cloud, that we collectively have not valued the class
<br>
of user who is "a person who wants to use the cloud". Examples
of this <br>
are that the other day I had to read a section of the admin guide to <br>
find information about how to boot a nova instance with a cinder volume
<br>
attached all in one go. Spoiler alert, it doesn't work. Another spoiler
<br>
alert - even though the python client has an option for requesting that
<br>
a volume that is to be attached on boot be formatted in a particular <br>
way, this does not work for cinder volumes, which means it does not work
<br>
for an end user - EVEN THOUGH this is a very basic thing to want.<br>
<br>
Our client libraries are clearly not written with end users in mind, and
<br>
this has been the case for quite some time. However, openstacksdk is not
<br>
yet to the point of being usable for "end users" - although good
work is <br>
going on there to get it to be a basis for an end user python library.<br>
<br>
We give deployers so much flexibility, that in order to write even a <br>
SIMPLE program that uses OpenStack, an end user has to know generally <br>
four of five pieces of information to check for that are different ways
<br>
that a deployer may have decided to do things.<br>
<br>
Example:<br>
<br>
  - As a user, I want a compute instance that has an IP address that
can <br>
do things.<br>
<br>
WELL, now you're screwed, because there is no standard way to do that.
<br>
You may first want to try booting your instance and then checking to see
<br>
if nova returns a network labeled "public". You may get no networks.
<br>
This indicates that your provider decided to deploy neutron, but as part
<br>
of your account creation did not create default networks. You now need
<br>
to go create a router, network and port in neutron. Now you can try <br>
again. Or, you may get networks back, but neither of them are labeled <br>
"public" - instead, you may get a public and a private address
back in <br>
the network labeled private. Or, you may only get a private network <br>
back. This indicates that you may be expected to create a thing called
a <br>
"floating-ip". First, you need to verify that your provider has
<br>
installed the floating-ip's extension. If they have, then you can create
<br>
a floating-ip and attach it to your host. NOW - once you have those <br>
things done, you need to connect to your host and verify that its <br>
outbound networking has not been blocked by a thing called security <br>
groups, which you also may not have been expecting to exist, but I'll <br>
stop there, because the above is long enough.<br>
<br>
Every. Single. One. Of. Those. Cases. is real and has occurred across <br>
only the two public openstack clouds that infra uses. That means that <br>
our provisioning code takes every single one of them in to account, and
<br>
anyone who writes code that wants to get a machine to use must take them
<br>
all in to account or else their code is buggy.<br>
<br>
That's RIDICULOUS. So we should fix it. I'd say we should fix it by <br>
removing 1000% of the choices we've given deployers in this case, but I
<br>
won't win there. So how about let's make at least one client library <br>
that encodes all of the above logic behind some simple task oriented API
<br>
calls? How about we make that library not something which is just a <br>
repackaging of requests that does not contain intelligent, but instead
<br>
something that is fundamentally usable. How about we have synchronous <br>
versions of all calls that do the polling and error checking. (if you <br>
attach a cinder volume to a nova instance, apparently, you need to <br>
continually re-fetch the volume from cinder and check its "attachments"
<br>
property to see when the attach actually happens, because even though <br>
there is a python library call to do it, it's an async operation and <br>
there is no status field field to check, nor is there any indication <br>
that the operation is async, so when the call returns, the volume may or
<br>
may not be attached.)<br>
<br>
This client library should contain exactly ZERO admin functions, because
<br>
hopefully the number of people running OpenStack clouds will be smaller
<br>
than the number of people who are using OpenStack clouds at some point
- <br>
and exposing admin functionality to an end user who can never use it is
<br>
just mean. Especially when that functionality is something that the end
<br>
user wishes he could do (like create non-insance flavor definitions) but
<br>
never will be allowed to do (because someone somewhere thinks that <br>
scheduling compute resources only be RAM size is userful)<br>
<br>
If I don't do anything at all next cycle, I will see the above fixed. <br>
Because it's embarrassing. Seriously. Try to use OpenStack from python
<br>
some time. I dare you.<br>
<br>
2. Less features, more win<br>
<br>
In a perfect world, I'd argue that we should merge exactly zero new <br>
features in all of kilo, and instead focus on making the ones we have <br>
work well. Some of making the ones we have work well may wind up feeling
<br>
just like writing features, as I imagine some of our features are <br>
probably only half features in the first place.<br>
<br>
3. Deleting things<br>
<br>
We should delete a bunch of code. Deleting code is fun, and it makes <br>
your life better, because it means you have less code. So we should <br>
start doing it. In particular, we should look for places where we wrote
<br>
something as part of OpenStack because the python community did not have
<br>
a thing already, but now there is one. In those cases, we should delete
<br>
ours and use theirs. Or we should contribute to theirs if it's not quite
<br>
good enough yet. Or we should figure out how to make more of the oslo <br>
libraries things that can truly target non-OpenStack things.<br>
<br>
Between 2 and 3, maybe we can make a kilo release that has a net <br>
negative SLOC count. But, honestly, screw 2 and 3 - let's all just work
<br>
on 1.<br>
<br>
Monty<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>