On 11/06/2015 07:28 AM, John Garbutt wrote: > On 6 November 2015 at 12:09, Sean Dague <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 >> .......... >> } >> >> 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 __________________________________________________________________________ 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