<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-05-18 19:58 GMT+08:00 Nadathur, Sundar <span dir="ltr"><<a href="mailto:sundar.nadathur@intel.com" target="_blank">sundar.nadathur@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Hi Matt,<br>
    </p><span class="">
    <div class="m_-5435092536792298706moz-cite-prefix">On 5/17/2018 3:18 PM, Matt Riedemann
      wrote:<br>
    </div>
    <blockquote type="cite">On
      5/17/2018 3:36 PM, Nadathur, Sundar wrote:
      <br>
      <blockquote type="cite">This applies only to the resources that
        Nova handles, IIUC, which does not handle accelerators. The
        generic method that Alex talks about is obviously preferable
        but, if that is not available in Rocky, is the filter an option?
        <br>
      </blockquote>
      <br>
      If nova isn't creating accelerator resources managed by cyborg, I
      have no idea why nova would be doing quota checks on those types
      of resources. And no, I don't think adding a scheduler filter to
      nova for checking accelerator quota is something we'd add either.
      I'm not sure that would even make sense - the quota for the
      resource is per tenant, not per host is it? The scheduler filters
      work on a per-host basis.
      <br>
    </blockquote></span>
    Can we not extend BaseFilter.filter_all() to get all the hosts in a
    filter? <br>
             
    <a class="m_-5435092536792298706moz-txt-link-freetext" href="https://github.com/openstack/nova/blob/master/nova/filters.py#L36" target="_blank">https://github.com/openstack/<wbr>nova/blob/master/nova/filters.<wbr>py#L36</a> <br>
    <br>
    I should have made it clearer that this putative filter will be
    out-of-tree, and needed only till better solutions become available.
    <span class=""><blockquote type="cite">
      <br>
      Like any other resource in openstack, the project that manages
      that resource should be in charge of enforcing quota limits for
      it.
      <br>
    </blockquote></span>
    Agreed. Not sure how other projects handle it, but here's the
    situation for Cyborg. A request may get scheduled on a compute node
    with no intervention by Cyborg. So, the earliest check that can be
    made today is in the selected compute node. A simple approach can
    result in quota violations as in this example.<br>
    <blockquote>Say there are 5 devices in a cluster. A tenant has a
      quota of 4 and is currently using 3. That leaves 2 unused devices,
      of which the tenant is permitted to use only one. But he may
      submit two concurrent requests, and they may land on two different
      compute nodes. The Cyborg agent in each node will see the current
      tenant usage as 3 and let the request go through, resulting in
      quota violation.<br></blockquote></div></blockquote><div>That's a bed design if <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Cyborg agent in each node let the<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>request go through. </span></span></div><div>And the current Cyborg quota design does not have this issue.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><blockquote>
    </blockquote>
    To prevent this, we need some kind of atomic update , like
    SQLAlchemy's with_lockmode():<br>
        
<a class="m_-5435092536792298706moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#Pessimistic_Locking_-_SELECT_FOR_UPDATE" target="_blank">https://wiki.openstack.org/<wbr>wiki/OpenStack_and_SQLAlchemy#<wbr>Pessimistic_Locking_-_SELECT_<wbr>FOR_UPDATE</a>
    <br>
    That seems to have issues, as documented in the link above. Also,
    since every compute node does that, it would also serialize the
    bringup of all instances with accelerators, across the cluster.<br>
    <br>
    If there is a better solution, I'll be happy to hear it.<br>
    <br>
    Thanks,<br>
    Sundar<br>
    <br>
    <br>
    <br>
    <br>
  </div>

<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>