Open Stack

On 6 November 2015 at 14:09, Sean Dague <sean at dague.net> wrote:
> On 11/06/2015 08:44 AM, Alex Xu wrote:
>>
>>
>> 2015-11-06 20:59 GMT+08:00 Sean Dague <sean at dague.net
>> <mailto:sean at dague.net>>:
>>
>>     On 11/06/2015 07:28 AM, John Garbutt wrote:
>>     > On 6 November 2015 at 12:09, Sean Dague <sean at dague.net
>>     <mailto: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
>>     >>          ..........
>>     >>       }
>>     >>
>>
>>
>> Does this need admin to set the capabilities? If yes, that looks like
>> pain to admin to set capabilities for all the flavors. This should be
>> the capabilities the instance required. And hypervisor should report
>> their capabilities, and reflect to instance.
>
> No, in version 1 there should be some mechanism that pulls this up from
> the drivers. In a single hypervisor cloud, that's easy. In a multi
> hypervisor cloud, some invention will be needed.
>
> But solve the easy case first, it makes life better for a lot of users.

+1 for solving the easy case first.

We could/should write up the full horror story, but lets not get
bogged down too much on that.

Thanks.
John