Open Stack

On 05/19/2017 03:13 PM, Monty Taylor wrote:
> 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.

Quick follow up on this one.

It was "extra_specs" I was thinking about - not "extra_info"

It used to be in the flavor as part of an extension (with a longer name) 
- we fetch them in shade for backwards compat with the past when they 
were just there. However, I've also learned from a follow up in IRC that 
these aren't really things that were intended for me.

So I'll re-frame this point slightly ...

As a user it's often quite difficult to tell what general intent is 
related to use of resources - whether they are intended for general 
users, or whether they are intended for admins. I guess a lot, and 
sometimes I get it right, and sometimes I don't. I know, I know - policy 
makes it so that different cloud deployers can have _vastly_ different 
opinions on this. But a clear intent from us (greatly helped, btw, by 
putting default policy in code) of "this call, this resource, this field 
is intended for normal users, but this one is intended for admin users" 
would have certainly helped me many times in the past.

Thanks for the IRC chat!

> 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.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev