Open Stack

Monty,

+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.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Monty Taylor <mordred at inaugust.com>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>, 
Date:   09/07/2014 08:15 PM
Subject:        Re: [openstack-dev] Kilo Cycle Goals Exercise



On 09/03/2014 08:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One 
idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> Have anyone interested (especially TC members) come up with a list of 
what
> they think the project wide Kilo cycle goals should be and post them on
> this thread by end of day Wednesday, September 10th. After which time we
> can begin discussing the results.
> The goal of this exercise is to help us see if our individual world 
views
> align with the greater community, and to get the ball rolling on a 
larger
> discussion of where as a project we should be focusing more time.

If I were king ...

1. Caring about end user experience at all

It's pretty clear, if you want to do things with OpenStack that are not 
running your own cloud, that we collectively have not valued the class 
of user who is "a person who wants to use the cloud". Examples of this 
are that the other day I had to read a section of the admin guide to 
find information about how to boot a nova instance with a cinder volume 
attached all in one go. Spoiler alert, it doesn't work. Another spoiler 
alert - even though the python client has an option for requesting that 
a volume that is to be attached on boot be formatted in a particular 
way, this does not work for cinder volumes, which means it does not work 
for an end user - EVEN THOUGH this is a very basic thing to want.

Our client libraries are clearly not written with end users in mind, and 
this has been the case for quite some time. However, openstacksdk is not 
yet to the point of being usable for "end users" - although good work is 
going on there to get it to be a basis for an end user python library.

We give deployers so much flexibility, that in order to write even a 
SIMPLE program that uses OpenStack, an end user has to know generally 
four of five pieces of information to check for that are different ways 
that a deployer may have decided to do things.

Example:

  - As a user, I want a compute instance that has an IP address that can 
do things.

WELL, now you're screwed, because there is no standard way to do that. 
You may first want to try booting your instance and then checking to see 
if nova returns a network labeled "public". You may get no networks. 
This indicates that your provider decided to deploy neutron, but as part 
of your account creation did not create default networks. You now need 
to go create a router, network and port in neutron. Now you can try 
again. Or, you may get networks back, but neither of them are labeled 
"public" - instead, you may get a public and a private address back in 
the network labeled private. Or, you may only get a private network 
back. This indicates that you may be expected to create a thing called a 
"floating-ip". First, you need to verify that your provider has 
installed the floating-ip's extension. If they have, then you can create 
a floating-ip and attach it to your host. NOW - once you have those 
things done, you need to connect to your host and verify that its 
outbound networking has not been blocked by a thing called security 
groups, which you also may not have been expecting to exist, but I'll 
stop there, because the above is long enough.

Every. Single. One. Of. Those. Cases. is real and has occurred across 
only the two public openstack clouds that infra uses. That means that 
our provisioning code takes every single one of them in to account, and 
anyone who writes code that wants to get a machine to use must take them 
all in to account or else their code is buggy.

That's RIDICULOUS. So we should fix it. I'd say we should fix it by 
removing 1000% of the choices we've given deployers in this case, but I 
won't win there. So how about let's make at least one client library 
that encodes all of the above logic behind some simple task oriented API 
calls? How about we make that library not something which is just a 
repackaging of requests that does not contain intelligent, but instead 
something that is fundamentally usable. How about we have synchronous 
versions of all calls that do the polling and error checking. (if you 
attach a cinder volume to a nova instance, apparently, you need to 
continually re-fetch the volume from cinder and check its "attachments" 
property to see when the attach actually happens, because even though 
there is a python library call to do it, it's an async operation and 
there is no status field field to check, nor is there any indication 
that the operation is async, so when the call returns, the volume may or 
may not be attached.)

This client library should contain exactly ZERO admin functions, because 
hopefully the number of people running OpenStack clouds will be smaller 
than the number of people who are using OpenStack clouds at some point - 
and exposing admin functionality to an end user who can never use it is 
just mean. Especially when that functionality is something that the end 
user wishes he could do (like create non-insance flavor definitions) but 
never will be allowed to do (because someone somewhere thinks that 
scheduling compute resources only be RAM size is userful)

If I don't do anything at all next cycle, I will see the above fixed. 
Because it's embarrassing. Seriously. Try to use OpenStack from python 
some time. I dare you.

2. Less features, more win

In a perfect world, I'd argue that we should merge exactly zero new 
features in all of kilo, and instead focus on making the ones we have 
work well. Some of making the ones we have work well may wind up feeling 
just like writing features, as I imagine some of our features are 
probably only half features in the first place.

3. Deleting things

We should delete a bunch of code. Deleting code is fun, and it makes 
your life better, because it means you have less code. So we should 
start doing it. In particular, we should look for places where we wrote 
something as part of OpenStack because the python community did not have 
a thing already, but now there is one. In those cases, we should delete 
ours and use theirs. Or we should contribute to theirs if it's not quite 
good enough yet. Or we should figure out how to make more of the oslo 
libraries things that can truly target non-OpenStack things.

Between 2 and 3, maybe we can make a kilo release that has a net 
negative SLOC count. But, honestly, screw 2 and 3 - let's all just work 
on 1.

Monty

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140908/af33e6cc/attachment.html>