<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Flint,</p>
    <p>I wish it was "my" summit ;)<br>
      In the latter case I'd make the sessions an hour and not 20 or 40
      minutes, well at least for the Forum part. And I will also make
      only one summit a year instead of two (which is also a feed back I
      got from the Market place). I've passed that during the user
      feedback session.<br>
    </p>
    Sorry for not responding earlier, @elmiko is going to send the
    minutes of the API SIG forum session we had.<br>
    <br>
    We confirmed Neutron to be the PoC. <br>
    We are going to use a feature branch, waiting for Miguel Lavalle to
    confirm the request has been acknowledge by the Infra group.<br>
    The PoC goal is to show GraphQL efficiency. <br>
    So we're going to make something straightforward, use Neutron
    existing server by  adding the graphQL endpoint and cover few core
    items such as network, subnets and ports (for example). <br>
    <br>
    Also the idea of having a central point of access for OpenStack APIs
    using GrahpQL stitching and delegation is exciting for everyone (and
    I had obviously same feedback off the session) and that's something
    that could happen once the PoC has convinced. <br>
    <br>
    During the meeting, Jiri Tomasek explained how GraphQL could help
    TripleO UI. Effectively they struggle with APIs requests and had to
    create a middle(ware) module in JS to do API work and reconstruction
    before the Javascript client can use it. GraphQL would simplify the
    process and allow to get rid of the module. He also explained, after
    the meeting, how Horizon could benefit as well, allowing to use only
    JS and avoid Django altogether!<br>
    <br>
    I've also been told that Zuul nees GraphQL.<br>
    <br>
    Well basically the question is who doesn't need it?<br>
    <br>
    Cheers,<br>
    Gilles<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 31/05/18 03:34, Flint WALRUS wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAG+53uastmM6oEQHen--YZG8ZDoauQ2Xh3AjjpJfp+yKfpD5_g@mail.gmail.com">Hi
      Gilles, I hope you enjoyed your Summit!?<br>
      <br>
      Did you had any interesting talk to report about our little
      initiative ?<br>
      <div class="gmail_quote">
        <div dir="ltr">Le dim. 6 mai 2018 à 15:01, Gilles Dubreuil <<a
            href="mailto:gdubreui@redhat.com" moz-do-not-send="true">gdubreui@redhat.com</a>>
          a écrit :<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text="#000000" bgcolor="#FFFFFF">
            <p><br>
            </p>
            <p>Akihiro, thank you for your precious help!<br>
            </p>
            <p>Regarding the choice of Neutron as PoC, I'm sorry for not
              providing much details when I said "because of its
              specific data model",<span
style="color:rgb(34,34,34);font-family:sans-serif;font-size:14px;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><br>
              effectively the original mention was  "its API exposes
              things at an individual table level, requiring the client
              to join that information to get the answers they need".<br>
              I realize now such description probably applies to many
              OpenStack APIs.<br>
              So I'm not sure what was the reason for choosing Neutron.
              <br>
              I suppose Nova is also a good candidate because API is
              quite complex too, in a different way, and need to expose
              the data API and the control API plane as we discussed.<br>
            </p>
            <p>After all Neutron is maybe not the best candidate but it
              seems good enough. <br>
            </p>
            <p>And as Flint say the extension mechanism shouldn't be an
              issue.</p>
            <p>So if someone believe there is a better candidate for the
              PoC, please speak now.</p>
            <p>Thanks,<br>
              Gilles</p>
            <p>PS: Flint,  Thank you for offering to be the advocate for
              Berlin. That's great!<br>
            </p>
          </div>
          <div text="#000000" bgcolor="#FFFFFF">
            <p><br>
            </p>
            <div class="m_2732130774180494018moz-cite-prefix">On
              06/05/18 02:23, Flint WALRUS wrote:<br>
            </div>
            <blockquote type="cite">
              <div>Hi Akihiro,<br>
                <br>
                Thanks a lot for this insight on how neutron behave.<br>
                <br>
                We would love to get support and backing from the
                neutron team in order to be able to get the best PoC
                possible.<br>
                <br>
                <div dir="auto">Someone suggested neutron as a good
                  choice because of it simple database model. As GraphQL
                  can manage your behavior of an extension declaring its
                  own schemes I don’t think it would take that much time
                  to implement it.</div>
              </div>
              <div dir="auto"><br>
              </div>
              <div dir="auto">@Gilles, if I goes to the berlin summitt I
                could definitely do the networking and relationship work
                needed to get support on our PoC from different teams
                members. This would help to spread the world multiple
                time and don’t have a long time before someone come to
                talk about this subject as what happens with the 2015
                talk of the Facebook speaker.</div>
              <div><br>
                <div class="gmail_quote">
                  <div>Le sam. 5 mai 2018 à 18:05, Akihiro Motoki <<a
                      href="mailto:amotoki@gmail.com" target="_blank"
                      moz-do-not-send="true">amotoki@gmail.com</a>> a
                    écrit :<br>
                  </div>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <div>Hi,
                      <div><br>
                      </div>
                      <div>I am happy to see the effort to explore a new
                        API mechanism.</div>
                      <div>I would like to see good progress and help
                        effort as API liaison from the neutron team.</div>
                    </div>
                    <div>
                      <div><br>
                      </div>
                      <div>> <span
style="color:rgb(34,34,34);font-family:sans-serif;font-size:14px;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">Neutron
                          has been selected for the PoC because of its
                          specific data model</span></div>
                      <div><br>
                      </div>
                    </div>
                    <div>
                      <div>On the other hand, I am not sure this is the
                        right reason to choose 'neutron' only from this
                        reason. I would like to note "its specific data
                        model" is not the reason that makes the progress
                        of API versioning slowest in the OpenStack
                        community. I believe it is worth recognized as I
                        would like not to block the effort due to the
                        neutron-specific reasons.</div>
                      <div>The most complicated point in the neutron API
                        is that the neutron API layer allows neutron
                        plugins to declare which features are supported.
                        The neutron API is a collection of API
                        extensions defined in the neutron-lib repo and
                        each neutron plugin can declare which subset(s)
                        of the neutron APIs are supported. (For more
                        detail, you can check how the neutron API
                        extension mechanism is implemented). It is not
                        defined only by the neutron API layer. We need
                        to communicate which API features are supported
                        by communicating enabled service plugins.</div>
                      <div><br>
                      </div>
                      <div>I am afraid that most efforts to explore a
                        new mechanism in neutron will be spent to
                        address the above points which is not directly
                        related to GraphQL itself.<br>
                      </div>
                      <div>Of course, it would be great if you overcome
                        long-standing complicated topics as part of
                        GraphQL effort :)<br>
                      </div>
                      <div><br>
                      </div>
                      <div>I am happy to help the effort and understand
                        how the neutron API is defined.</div>
                      <div><br>
                      </div>
                      <div>Thanks,</div>
                      <div>Akihiro</div>
                      <div><br>
                      </div>
                    </div>
                    <br>
                    <div class="gmail_quote">
                      <div>2018年5月5日(土) 18:16 Gilles Dubreuil <<a
                          href="mailto:gdubreui@redhat.com"
                          target="_blank" moz-do-not-send="true">gdubreui@redhat.com</a>>:<br>
                      </div>
                    </div>
                    <div class="gmail_quote">
                      <blockquote class="gmail_quote" style="margin:0 0
                        0 .8ex;border-left:1px #ccc
                        solid;padding-left:1ex">Hello,<br>
                        <br>
                        Few of us recently discussed [1] how GraphQL
                        [2], the next evolution <br>
                        from REST, could transform OpenStack APIs for
                        the better.<br>
                        Effectively we believe OpenStack APIs provide
                        perfect use cases for <br>
                        GraphQL DSL approach, to bring among other
                        advantages, better <br>
                        performance and stability, easier developments
                        and consumption, and with <br>
                        GraphQL Schema provide automation capabilities
                        never achieved before.<br>
                        <br>
                        The API SIG suggested to start an API GraphQL
                        Proof of Concept (PoC) to <br>
                        demonstrate the capabilities before eventually
                        extend GraphQL to other <br>
                        projects.<br>
                        Neutron has been selected for the PoC because of
                        its specific data model.<br>
                        <br>
                        So if you are interested, please join us.<br>
                        For those who can make it, we'll also discuss
                        this during the SIG API <br>
                        BoF at OpenStack Summit at Vancouver [3]<br>
                        <br>
                        To learn more about GraphQL, check-out <a
                          href="http://howtographql.com"
                          rel="noreferrer" target="_blank"
                          moz-do-not-send="true">howtographql.com</a>
                        [4].<br>
                        <br>
                        So let's get started...<br>
                        <br>
                        <br>
                        [1] <a
href="http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html"
                          rel="noreferrer" target="_blank"
                          moz-do-not-send="true">http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html</a><br>
                        [2] <a href="http://graphql.org/"
                          rel="noreferrer" target="_blank"
                          moz-do-not-send="true">http://graphql.org/</a><br>
                        [3] <br>
                        <a
href="https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session"
                          rel="noreferrer" target="_blank"
                          moz-do-not-send="true">https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session</a><br>
                        [4] <a href="https://www.howtographql.com/"
                          rel="noreferrer" target="_blank"
                          moz-do-not-send="true">https://www.howtographql.com/</a><br>
                        <br>
                        Regards,<br>
                        Gilles<br>
                        <br>
                        <br>
                        <br>
                      </blockquote>
                    </div>
                    <div class="gmail_quote">
                      <blockquote class="gmail_quote" style="margin:0 0
                        0 .8ex;border-left:1px #ccc
                        solid;padding-left:1ex">
__________________________________________________________________________<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"
                          moz-do-not-send="true">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"
                          moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                      </blockquote>
                    </div>
__________________________________________________________________________<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"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                  </blockquote>
                </div>
              </div>
            </blockquote>
            <br>
          </div>
          <div text="#000000" bgcolor="#FFFFFF">
            <pre class="m_2732130774180494018moz-signature" cols="72">-- 
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: <a class="m_2732130774180494018moz-txt-link-abbreviated" href="mailto:gilles@redhat.com" target="_blank" moz-do-not-send="true">gilles@redhat.com</a>
GitHub/IRC: gildub
Mobile: +61 400 894 219 

</pre>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: <a class="moz-txt-link-abbreviated" href="mailto:gilles@redhat.com">gilles@redhat.com</a>
GitHub/IRC: gildub
Mobile: +61 400 894 219 

</pre>
  </body>
</html>