Open Stack

The End User working group is being described at https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is establishing the structure.

This page covers how to get involved...

Tim

From: Brad Topol [mailto:btopol at us.ibm.com]
Sent: 08 September 2014 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Kilo Cycle Goals Exercise

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<mailto:btopol at us.ibm.com>
Assistant: Kendra Witherspoon (919) 254-0680



From:        Monty Taylor <mordred at inaugust.com<mailto:mordred at inaugust.com>>
To:        "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto: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/6b6be9bf/attachment.html>