Open Stack

On 6 November 2015 at 09:49, Daniel P. Berrange <berrange at 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