Open Stack

On 05/20/2017 10:36 AM, Monty Taylor wrote:
> 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.

For what it's worth, there are cases where extra_specs are important to normal 
users because they constrain what image properties you are allowed to set.

Things like cpu_policy, cpu_thread_policy, memory page size, number of NUMA 
nodes, etc. can all be set in both places, and they behave differently if there 
is a mismatch between the flavor extra_spec and the image property.

Because of this I think it makes sense for a normal person to be able to look at 
flavor extra_specs so that they can create an image with suitable properties to 
be able to boot up an instance with that image on that flavor.

Chris