<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">Le 06/11/2015 07:08, Tony Breeds a
      écrit :<br>
    </div>
    <blockquote cite="mid:20151106060859.GE8816@thor.bakeyournoodle.com"
      type="cite">
      <pre wrap="">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.
</pre>
    </blockquote>
    <br>
    I'm pretty opposed to giving hypervisor details to end-users for
    many reasons (security flaw, cloud abstractional model and API not
    being a discovery tool are my first top things coming in mind).<br>
    <br>
    I'd rather prefer to see Horizon as an admin able to get the
    specific bits about the driver and only show to the user what the
    driver can support.<br>
    <br>
    That's also IMHO a bit tied to the Hypervisor Support Matrix [1] 
    and from a better and more maintenable standpoint, the Feature
    Classification effort [2] because it would ensure that the
    'capabilities' API that you mention is accurate and up-to-date.<br>
    <br>
    -Sylvain<br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="http://docs.openstack.org/developer/nova/support-matrix.html">http://docs.openstack.org/developer/nova/support-matrix.html</a><br>
    [2]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/215664/4/doc/source/feature_classification.rst,cm">https://review.openstack.org/#/c/215664/4/doc/source/feature_classification.rst,cm</a><br>
    <blockquote cite="mid:20151106060859.GE8816@thor.bakeyournoodle.com"
      type="cite">
      <pre wrap="">
Yours Tony.

[1] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/nova/+bug/1483639">https://bugs.launchpad.net/nova/+bug/1483639</a>
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>