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 :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev