Open Stack

On 6 November 2015 at 12:09, Sean Dague <sean at dague.net> wrote:
> On 11/06/2015 04:49 AM, Daniel P. Berrange 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.
>
> Right, we just had a super long conversation about this in #openstack-qa
> yesterday with mordred, jroll, and deva around what it's going to take
> to get upgrade tests passing with ironic.
>
> Capabilities is the right approach, because it means we're future
> proofing our interface by telling users what they can do, not some
> arbitrary string that they need to cary around a separate library to
> figure those things out.
>
> It seems like capabilities need to exist on flavor, and by proxy instance.
>
> GET /flavors/bm.large/capabilities
>
> {
>      "actions": {
>          'pause': False,
>          'unpause': False,
>          'rebuild': True
>          ..........
>       }
>
> A starting point would definitely be the set of actions that you can
> send to the flavor/instance. There may be features beyond that we'd like
> to classify as capabilities, but actions would be a very concrete and
> attainable starting point. With microversions we don't have to solve
> this all at once, start with a concrete thing and move forward.
>
> Sending an action that was "False" for the instance/flavor would return
> a 400 BadRequest high up at the API level, much like input validation
> via jsonschema.

+1

>From memory we couldn't quite decide on the granularity of that
actions list, but we can work through that in a spec.

> This is nothing new, we've talked about it in the abstract in the Nova
> space for a while. We've yet had anyone really take this on. If you
> wanted to run with a spec and code, it would be welcome.

+1

I would love for it to eventually also reflect policy (per flavor
policy) in that list of available actions. That might be one way to
get something quickly, while working on a more automatic solution.

Not to delay that work, but there are related ideas around grouping
flavors, into flavor classes, so you attach policy to the class rather
than every single flavor. I think that would help make this easier to
administer, in the long term.

Thanks,
John