Open Stack

On 11/06/2015 07:28 AM, John Garbutt wrote:
> 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.

My suggestion is that phase 1 is the list of ACTIONS you can POST to
/servers/UUID/action. That is already a fixed size list and is a
definitive concept today.

	-Sean

-- 
Sean Dague
http://dague.net