On 6 November 2015 at 09:49, Daniel P. Berrange <berra...@redhat.com> wrote: > 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.
+1 to capabilities approach. This also feels very related to the policy discovery piece we have debated previously. Thanks, John __________________________________________________________________________ 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