<div dir="ltr">+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.</div><div class="gmail_extra"><br><div class="gmail_quote">On 6 November 2015 at 23:09, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:<br>
> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:<br>
>> Hello all,<br>
>>     I came across [1] which is notionally an ironic bug in that horizon presents<br>
>> VM operations (like suspend) to users.  Clearly these options don't make sense<br>
>> to ironic which can be confusing.<br>
>><br>
>> There is a horizon fix that just disables migrate/suspened and other functaions<br>
>> if the operator sets a flag say ironic is present.  Clealy this is sub optimal<br>
>> for a mixed hv environment.<br>
>><br>
>> The data needed (hpervisor type) is currently avilable only to admins, a quick<br>
>> hack to remove this policy restriction is functional.<br>
>><br>
>> There are a few ways to solve this.<br>
>><br>
>>  1. Change the default from "rule:admin_api" to "" (for<br>
>>     os_compute_api:os-extended-server-attributes and<br>
>>     os_compute_api:os-hypervisors), and set a list of values we're<br>
>>     comfortbale exposing the user (hypervisor_type and<br>
>>     hypervisor_hostname).  So a user can get the hypervisor_name as part of<br>
>>     the instance deatils and get the hypervisor_type from the<br>
>>     os-hypervisors.  This would work for horizon but increases the API load<br>
>>     on nova and kinda implies that horizon would have to cache the data and<br>
>>     open-code assumptions that hypervisor_type can/can't do action $x<br>
>><br>
>>  2. Include the hypervisor_type with the instance data.  This would place the<br>
>>     burdon on nova.  It makes the looking up instance details slightly more<br>
>>     complex but doesn't result in additional API queries, nor caching<br>
>>     overhead in horizon.  This has the same opencoding issues as Option 1.<br>
>><br>
>>  3. Define a service user and have horizon look up the hypervisors details via<br>
>>     that role.  Has all the drawbacks as option 1 and I'm struggling to<br>
>>     think of many benefits.<br>
>><br>
>>  4. Create a capabilitioes API of some description, that can be queried so that<br>
>>     consumers (horizon) can known<br>
>><br>
>>  5. Some other way for users to know what kind of hypervisor they're on, Perhaps<br>
>>     there is an established image property that would work here?<br>
>><br>
>> If we're okay with exposing the hypervisor_type to users, then #2 is pretty<br>
>> quick and easy, and could be done in Mitaka.  Option 4 is probably the best<br>
>> long term solution but I think is best done in 'N' as it needs lots of<br>
>> discussion.<br>
><br>
> I think that exposing hypervisor_type is very much the *wrong* approach<br>
> to this problem. The set of allowed actions varies based on much more than<br>
> just the hypervisor_type. The hypervisor version may affect it, as may<br>
> the hypervisor architecture, and even the version of Nova. If horizon<br>
> restricted its actions based on hypevisor_type alone, then it is going<br>
> to inevitably prevent the user from performing otherwise valid actions<br>
> in a number of scenarios.<br>
><br>
> IMHO, a capabilities based approach is the only viable solution to<br>
> this kind of problem.<br>
<br>
</div></div>Right, we just had a super long conversation about this in #openstack-qa<br>
yesterday with mordred, jroll, and deva around what it's going to take<br>
to get upgrade tests passing with ironic.<br>
<br>
Capabilities is the right approach, because it means we're future<br>
proofing our interface by telling users what they can do, not some<br>
arbitrary string that they need to cary around a separate library to<br>
figure those things out.<br>
<br>
It seems like capabilities need to exist on flavor, and by proxy instance.<br>
<br>
GET /flavors/bm.large/capabilities<br>
<br>
{<br>
     "actions": {<br>
         'pause': False,<br>
         'unpause': False,<br>
         'rebuild': True<br>
         ..........<br>
      }<br>
<br>
A starting point would definitely be the set of actions that you can<br>
send to the flavor/instance. There may be features beyond that we'd like<br>
to classify as capabilities, but actions would be a very concrete and<br>
attainable starting point. With microversions we don't have to solve<br>
this all at once, start with a concrete thing and move forward.<br>
<br>
Sending an action that was "False" for the instance/flavor would return<br>
a 400 BadRequest high up at the API level, much like input validation<br>
via jsonschema.<br>
<br>
This is nothing new, we've talked about it in the abstract in the Nova<br>
space for a while. We've yet had anyone really take this on. If you<br>
wanted to run with a spec and code, it would be welcome.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>