Open Stack

On 05/19/2017 01:53 PM, Sean Dague wrote:
> On 05/19/2017 02:34 PM, Dean Troyer wrote:
>> On Fri, May 19, 2017 at 1:04 PM, Sean Dague <sean at dague.net> wrote:
>>> These should be used as ways to experiment with the kinds of interfaces
>>> we want cheaply, then take them back into services (which is a more
>>> expensive process involving compatibility stories, deeper documentation,
>>> performance implications, and the like), not an end game on their own.
>>
>> I totally agree here.  But I also see the rate of progress for many
>> and varied reasons, and want to make users lives easier now.
>>
>> Have any of the lessons already learned from Shade or OSC made it into
>> services yet?  I think a few may have, "get me a network" being the
>> obvious one.  But that still took a lot of work (granted that one _is_
>> complicated).
>
> Doing hard things is hard. I don't expect changing APIs to be easy at
> this level of deployedness of OpenStack.
>
>>> You can get the behavior. It also has other behaviors. I'm not sure any
>>> user has actually argued for "please make me do more rest calls to
>>> create a server".
>>
>> Maybe not in those words, but "give me the tools to do what I need"
>> has been heard often.  Sometimes those tools are composable
>> primitives, sometimes they are helpful opinionated interfaces.  I've
>> already done the helpful opinionated stuff in OSC here (accept flavor
>> and image names when the non-unique names _do_ identify a single
>> result).  Having that control lets me give the user more options in
>> handling edge cases.
>
> Sure, it does. The fact that it makes 3 API calls every time when doing
> flavors by name (404 on the name, list all flavors, local search, get
> the flavor by real id) on mostly read only data (without any caching) is
> the kind of problem that rises from "just fix it in an upper layer". So
> it does provide an experience at a cost.

We also searching of all resources by name-or-id in shade. But it's one 
call - GET /images - and then we test to see if the given value matches 
the name field or the id field. And there is caching, so the list call 
is done once in the session.

The thing I'm the saddest about is the Nova flavor "extra_info" that one 
needs to grab for backwards compat but almost never has anything useful 
in it. This causes me to make a billion API calls for the initial flavor 
list (which is then cached of course) It would be WAY nicer if there was 
a GET /flavors/detail that would just get me the whole lot in one go, fwiw.

Dean has a harder time than I do with that one because osc interactions 
are lots of process invocations from scratch. We chatted a bit about how 
to potentially share caching things in Boston, but not sure we've come 
up with more.

> All for new and better experiences. I think that's great. Where I think
> we want to be really careful is deciding the path to creating better
> experiences is by not engaging with the services and just writing around
> it. That feedback has to come back. Those reasons have to come back, and
> we need to roll sensible improvements back into base services.
>
> If you want to go fast, go alone, if you want to go far, go together.

Couldn't agree more . I think we're getting better at that communication.

We still have a hole, which is that the path from "this is a problem and 
here's how I'm working around it" to "there are devs tasked to work on 
solving that problem" is a hard one, because while the communication 
from those of us doing client-layer stuff with the folks doing the 
servers is pretty good - the communication loop with the folks at the 
companies who are prioritizing work ... not so much. Look at the number 
of people hacking on shade or python-openstackclient or writing 
user-facing docs compared to folks adding backend features to the services.

So - yes, I totally agree. But also, we can make and are making a lot of 
progress in some areas with tiny crews. That's gonna likely be the state 
of the world for a while until we're better able to point our fingers at 
the problem and characterize it such that our friends who provide 
resources value these problems enough to fund working on them.