Open Stack

> On Jun 25, 2020, at 10:43 AM, Sean Mooney <smooney at redhat.com> wrote:
> 
> On Thu, 2020-06-25 at 08:50 -0500, Monty Taylor wrote:
>>> I’ll get up a patch in just a sec.
>> 
>> https://review.opendev.org/738026 Provide hypervisor_hostname in Hypervisor object
>> 
>> Should do the trick.
>> 
>>> 
>>>> 
>>>> im not sure  if ths is something that can be fix and how widespread the problemn is but really the upstream names
>>>> from
>>>> the api responce should also work IMO and this seams like an sdk bug to me.
>> 
>> In this case it’s pretty easy and seems like a good idea to provide both.
>> 
>> That said - there are MANY places in SDK where we rename upstream names. Sometimes it’s because upstream names are
>> impossible to represent in attribute names ("os-extended-volumes:volumes_attached”)  Sometimes it’s because of
>> confusing REST naming inconsistencies (hostId vs host_status). Sometimes it’s just to keep things consistent across
>> services for SDK users (boolean flags are all verb-prefixed, so it’s is_locked and has_config_drive)
>> 
>> In general, the SDK has an API. It goes well out of its way to make sure that api works across releases and across
>> services. That API may not always match the REST API for a given version of a different service, and not matching is
>> frequently a conscious choice.
>> 
>> But that’s just for context - in this case I think it’s more than reasonable to provide hypervisor_hostname on the
>> Hypervisor resource object.
> 
> ya i was expecting that to be the case. i was debating internal if it would make sense to alter the __getitem__ fucntion

I am certain that everyone would love reviewing more magic in getitem :)

> so that if it does not find the atibute directly on the reouse it waould fall back to looking it up in the body ectra.
> that said i see the other point of view that you want to provide a consitent api so maybe instead of 
> just raising an generic AtributeError we coudl raise a subclass of that which had a more descriptive massage
> to make peopel aware of it.

Ooh - that’s an excellent idea!

> even without looking at the sdk closely before i found it really easy to more or less figured out why that error
> happened. so with a little python knolage and knowing what repo to look at it was not hard to figure out what
> was going on even with the generic message but other might find it useful.
> 
>