+1 this would definitely be the best approach from Horizon's perspective since we can cache the capabilities per-flavour. Having to request capabilities per-instance would be an unreasonable burden on the poor users of Horizon.
On 6 November 2015 at 23: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. > > This is nothing new, we've talked about it in the abstract in the Nova > space for a while. We've yet had anyone really take this on. If you > wanted to run with a spec and code, it would be welcome. > > -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 >
__________________________________________________________________________ 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