<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 04/12/2015 04:21, Alex Xu a écrit :<br>
    </div>
    <blockquote
cite="mid:CAH7mGatWRY0DQ+DqEVkF_VPZEeM55fCz+x0h6v+z9XgcKW529Q@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">2015-12-02 23:12 GMT+08:00 Sylvain
            Bauza <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=""><br>
                <br>
                Le 02/12/2015 15:23, Sean Dague a écrit :<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  We have previously agreed that scheduler hints in Nova
                  are an open ended<br>
                  thing. It's expected for sites to have additional
                  scheduler filters<br>
                  which expose new hints. The way we handle that with
                  our strict<br>
                  jsonschema is that we allow additional properties -<br>
                  <a moz-do-not-send="true"
href="https://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/api/openstack/compute/schemas/scheduler_hints.py#L65"
                    rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/api/openstack/compute/schemas/scheduler_hints.py#L65</a><br>
                  <br>
                  This means that if you specify some garbage hint, you
                  don't get feedback<br>
                  that it was garbage in your environment. That lost a
                  couple of days<br>
                  building multinode tests in the gate. Having gotten
                  used to the hints<br>
                  that "you've given us bad stuff", this was a stark
                  change back to the<br>
                  old world.<br>
                  <br>
                  Would it be possible to make it so that the schema
                  could be explicitly<br>
                  extended (instead of implicitly extended). So that
                  additional<br>
                  properties=False, but a mechanism for a scheduler
                  filter to register<br>
                  it's jsonschema in?<br>
                </blockquote>
                <br>
              </span>
              I'm pretty +1 for that because we want to have in-tree
              filters clear for the UX they provide when asking for
              scheduler hints.<br>
            </blockquote>
            <div><br>
            </div>
            <div>+1 also, and we should have capability API for
              discovering what hints supported by current deployment.</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
              For the moment, it's possible to have 2 different filters
              asking for the same hint without providing a way to
              explain the semantics so I would want to make sure that
              one in-tree filter could just have the same behaviour for
              *all the OpenStack deployments.*<br>
              <br>
              That said, I remember some discussion we had about that in
              the past, and the implementation details we discussed
              about having the Nova API knowing the list of filters and
              fitering by those.<br>
              To be clear, I want to make sure that we could not leak
              the deployment by providing a 401 if a filter is not
              deployed, but rather just make sure that all our in-tree
              filters are like checked, even if they aren't deployed.<br>
            </blockquote>
            <div><br>
            </div>
            <div>There isn't any other Nova API return 401. So if you
              return 401, then everybody will know that is the only 401
              in the nova, so I think there isn't any different. As we
              have capability API, it's fine let the user to know what
              is supported in the deployment.</div>
            <div> </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Sorry, I made a mistake by providing a wrong HTTP code for when the
    validation returns a ValidationError (due to the JSON schema not
    matched by the request).<br>
    Here, my point is that if we enforce a per-enabled-filter basis for
    checking whether the hint should be enforced, it would mean that as
    an hacker, I could have some way to know what filters are enabled,
    or as an user, I could have different behaviours depending on the
    deployment.<br>
    <br>
    Let me give you an example: say that I'm not enabling the
    SameHostFilter which exposes the 'same_host' hint.<br>
    <br>
    For that specific cloud, if we allow to deny a request which could
    provide the 'same-host' hint (because the filter is not loaded by
    the 'scheduler_default_filters' option), it would make a difference
    with another cloud which enables SameHostFilter (because the request
    would pass).<br>
    <br>
    So, I'm maybe nitpicking, but I want to make clear that we shouldn't
    introspect the state of the filter, and just consider a static JSON
    schema (as we have today) which would reference all the hints,
    whether the corresponding filter is enabled or not.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAH7mGatWRY0DQ+DqEVkF_VPZEeM55fCz+x0h6v+z9XgcKW529Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
              That leaves the out-of-tree discussion about custom
              filters and how we could have a consistent behaviour given
              that. Should we accept something in a specific deployment
              while another deployment could 401 against it ? Mmm, bad
              to me IMHO.<br>
            </blockquote>
            <div><br>
            </div>
            <div>We can have code to check the out-of-tree filters
              didn't expose any same hints with in-tree filter.</div>
            <div> </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Sure, and thank you for that, that was missing in the past. That
    said, there are still some interoperability concerns, let me explain
    : as a cloud operator, I'm now providing a custom filter (say
    MyAwesomeFilter) which does the lookup for an hint called
    'my_awesome_hint'.<br>
    <br>
    If we enforce a strict validation (and not allow to accept any hint)
    it would mean that this cloud would accept a request with
    'my_awesome_hint' while another cloud which wouldn't be running
    MyAwesomeFilter would then deny the same request.<br>
    <br>
    Hope I better explained my concerns,<br>
    -Sylvain<br>
    <br>
    <blockquote
cite="mid:CAH7mGatWRY0DQ+DqEVkF_VPZEeM55fCz+x0h6v+z9XgcKW529Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
              <br>
              -Sylvain<br>
              <br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                        -Sean<br>
                <br>
              </blockquote>
              <div class="HOEnZb">
                <div class="h5">
                  <br>
                  <br>
__________________________________________________________________________<br>
                  OpenStack Development Mailing List (not for usage
                  questions)<br>
                  Unsubscribe: <a moz-do-not-send="true"
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 moz-do-not-send="true"
                    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>
      </div>
      <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>