On 11/06/2015 08:44 AM, Alex Xu wrote: > > > 2015-11-06 20:59 GMT+08:00 Sean Dague <s...@dague.net > <mailto:s...@dague.net>>: > > On 11/06/2015 07:28 AM, John Garbutt wrote: > > On 6 November 2015 at 12:09, Sean Dague <s...@dague.net > <mailto:s...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev