Open Stack

Amen to this!

I've always felt bad that before yahoo tries to include a new feature in its openstack cloud/s we have to figure out how much the feature is a land-mine, how much of it works, how much of it doesn't and so-on. That type of investigation imho shouldn't really be needed and the fact that it is makes me want more and more a stability cycle or two (or three).

More and more recently I've be thinking that we have spent way to much on drivers and features and not enough on our own 'infrastructure'. 

While of course there is a balance, it just seems like the balance currently isn't right (IMHO).

Maybe we should start asking ourselves why it is so much easier to add a driver vs. do a cross-project functionality like gantt (or centralized quota management or other...) that removes some of those land-mines. When it becomes easier to land gantt vs a new driver then I think we might be in a better place. After all, our infrastructure is what makes the project a long-term success and not adding new drivers.

Just my 2 cents,

Josh

On Sep 7, 2014, at 5:14 PM, Monty Taylor <mordred at inaugust.com> wrote:

> 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