Open Stack

On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
> 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
> 
>  5. Some other way for users to know what kind of hypervisor they're on, Perhaps
>     there is an established image property that would work here?
> 
> If we're okay with exposing the hypervisor_type to users, then #2 is pretty
> quick and easy, and could be done in Mitaka.  Option 4 is probably the best
> long term solution but I think is best done in 'N' as it needs lots of
> discussion.

I think that exposing hypervisor_type is very much the *wrong* approach
to this problem. The set of allowed actions varies based on much more than
just the hypervisor_type. The hypervisor version may affect it, as may
the hypervisor architecture, and even the version of Nova. If horizon
restricted its actions based on hypevisor_type alone, then it is going
to inevitably prevent the user from performing otherwise valid actions
in a number of scenarios.

IMHO, a capabilities based approach is the only viable solution to
this kind of problem.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|