On 6 November 2015 at 14:09, Sean Dague <s...@dague.net> wrote: > 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.
+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 __________________________________________________________________________ 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