Python OpenStack SDK does not return Hypervisor hostname

Sean Mooney smooney at redhat.com
Thu Jun 25 15:43:47 UTC 2020


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
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.

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.




More information about the openstack-discuss mailing list