[openstack-dev] [nova][policy] Exposing hypervisor details to users

Clint Byrum clint at fewbar.com
Fri Nov 6 08:07:20 UTC 2015


Excerpts from Tony Breeds's message of 2015-11-05 22:08:59 -0800:
> Hello all,
>     I came across [1] which is notionally an ironic bug in that horizon presents
> VM operations (like suspend) to users.  Clearly these options don't make sense
> to ironic which can be confusing.
> 
> There is a horizon fix that just disables migrate/suspened and other functaions
> if the operator sets a flag say ironic is present.  Clealy this is sub optimal
> for a mixed hv environment.
> 
> The data needed (hpervisor type) is currently avilable only to admins, a quick
> hack to remove this policy restriction is functional.
> 
> There are a few ways to solve this.
> 
>  1. Change the default from "rule:admin_api" to "" (for 
>     os_compute_api:os-extended-server-attributes and
>     os_compute_api:os-hypervisors), and set a list of values we're
>     comfortbale exposing the user (hypervisor_type and
>     hypervisor_hostname).  So a user can get the hypervisor_name as part of
>     the instance deatils and get the hypervisor_type from the
>     os-hypervisors.  This would work for horizon but increases the API load
>     on nova and kinda implies that horizon would have to cache the data and
>     open-code assumptions that hypervisor_type can/can't do action $x
> 
>  2. Include the hypervisor_type with the instance data.  This would place the 
>     burdon on nova.  It makes the looking up instance details slightly more
>     complex but doesn't result in additional API queries, nor caching
>     overhead in horizon.  This has the same opencoding issues as Option 1.
> 
>  3. Define a service user and have horizon look up the hypervisors details via 
>     that role.  Has all the drawbacks as option 1 and I'm struggling to
>     think of many benefits.
> 
>  4. Create a capabilitioes API of some description, that can be queried so that
>     consumers (horizon) can known
> 

This.

A large part of why we want "clouds" and not "virtualization frontends"
is that we want to relieve the user of any need to know what hypervisor
is in use if we can. We want to provide them computers, and tools to
manage their computers. Whether they are VMs or real machines, our tools
should strive to be about the user and their workload, and not about the
operator and their technology.



More information about the OpenStack-dev mailing list