Open Stack

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.

	-Sean

-- 
Sean Dague
http://dague.net