I will not attend the vancouver summit but I’ll try to attend the berlin one as it’s closer to me.<br><br>However I’ll be happy to join the conversation and give a hand, especially if you need an operational point of view as our Openstack usage is constantly growing within an heterogeneous environment ranging from a grizzly cluster (deprecating it this year) to a shiny Queens one on multiple geographic area.<br><br>I think our setup gives us a really good point of view of what are the Openstack PITA and what operators are expecting the foundation to do with such challenges.<br><div class="gmail_quote"><div dir="ltr">Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil <<a href="mailto:gdubreui@redhat.com">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>Right, let's announce the Proof of Concept project as of Neutron,
      invite anyone interested and start it.</p>
    <p>There is an API SIG BoF at Vancouver, where we will announce it
      too. And for everyone who can attend, to be welcome to discuss it:<br>
<a class="m_4438341384216175053moz-txt-link-freetext" href="https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session" target="_blank">https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session</a></p>
    <p>Yeah, Graphene is the only one listed by GraphQL organization for
      Python: <a class="m_4438341384216175053moz-txt-link-freetext" href="http://graphql.org/code/#python" target="_blank">http://graphql.org/code/#python</a>. <br>
    </p>
    <p>I think we should take this discussion on the coming project
      thread.<br>
    </p>
    <p>Thank you everyone and see you there.</p>
    <p>Cheers,<br>
      Gilles<br>
    </p></div><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="m_4438341384216175053moz-cite-prefix">On 04/05/18 23:16, Flint WALRUS wrote:<br>
    </div>
    <blockquote type="cite">
      <div>
        <div dir="auto">As clarify by Gilles and Kevin we absolutely can
           get GraphQL with the control plan API and the workers api.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Ok, how do start to work on that? What’s the
          next step?</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Which server library do we want to use?</div>
        <div dir="auto">I personally use graphene with python as it is
          the library listed by the official GraphQL website. I don’t
          even know if there is another library available indeed.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Are we ok to try to use neutron as a PoC
          service?</div>
        <br>
      </div>
      <div>
        <div class="gmail_quote">
          <div>Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <<a href="mailto:gdubreui@redhat.com" target="_blank">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">Actually
            Mutations fields are only data to be displayed, if needed,
            by <br>
            the response.<br>
            The data changes comes with the parameters.<br>
            So the correct mutation syntax is:<br>
            <br>
            mutation rebootServer {<br>
               updateServer(id: <UUID>) {<br>
                 reboot(type: "HARD")<br>
               }<br>
            }<br>
            <br>
            Also the latter example would be a "data API" equivalent
            using CRUD <br>
            function like "updateServer"<br>
            <br>
            And the following example would be a "plane API" equivalent
            approach <br>
            with an action function:<br>
            <br>
            mutation hardReboot {<br>
               rebootServer(id: <UUID>, type: "HARD")<br>
            }<br>
            <br>
            Sorry for the initial confusion but I think this is
            important because <br>
            GraphQL schema helps clarify data and the operations.<br>
            <br>
            <br>
            On 04/05/18 13:20, Gilles Dubreuil wrote:<br>
            ><br>
            > On 04/05/18 05:34, Fox, Kevin M wrote:<br>
            >> k8s does that I think by separating desired state
            from actual state <br>
            >> and working to bring the two inline. the same could
            (maybe even <br>
            >> should) be done to openstack. But your right, that
            is not a small <br>
            >> amount of work.<br>
            ><br>
            > K8s makes perfect sense to follow declarative approach.<br>
            ><br>
            > That said a mutation following control plane API action
            semantic could <br>
            > be very similar:<br>
            ><br>
            > mutation rebootServer {<br>
            >   Server(id: <UUID>) {<br>
            >     reboot: {<br>
            >       type: "HARD"<br>
            >     }<br>
            >   }<br>
            > }<br>
            ><br>
            ><br>
            > "rebootServer" being an alias to name the request.<br>
            ><br>
            ><br>
            >> Even without using GraphQL, Making the api more
            declarative anyway, <br>
            >> has advantages.<br>
            ><br>
            > +1<br>
            ><br>
            >> Thanks,<br>
            >> Kevin<br>
            >> ________________________________________<br>
            >> From: Jay Pipes [<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>]<br>
            >> Sent: Thursday, May 03, 2018 10:50 AM<br>
            >> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
            >> Subject: Re: [openstack-dev] [api] REST limitations
            and GraghQL <br>
            >> inception?<br>
            >><br>
            >> On 05/03/2018 12:57 PM, Ed Leafe wrote:<br>
            >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil
            <<a href="mailto:gdubreui@redhat.com" target="_blank">gdubreui@redhat.com</a>> <br>
            >>> wrote:<br>
            >>>>> • We should get a common consensus
            before all projects start to <br>
            >>>>> implement it.<br>
            >>>> This is going to be raised during the API
            SIG weekly meeting later <br>
            >>>> this week.<br>
            >>>> API developers (at least one) from every
            project are strongly <br>
            >>>> welcomed to participate.<br>
            >>>> I suppose it makes sense for the API SIG to
            be the place to discuss <br>
            >>>> it, at least initially.<br>
            >>> It was indeed discussed, and we think that it
            would be a worthwhile <br>
            >>> experiment. But it would be a difficult, if not
            impossible, proposal <br>
            >>> to have adopted OpenStack-wide without some
            data to back it up. So <br>
            >>> what we thought would be a good starting point
            would be to have a <br>
            >>> group of individuals interested in GraphQL form
            an informal team and <br>
            >>> proceed to wrap one OpenStack API as a
            proof-of-concept. Monty <br>
            >>> Taylor suggested Neutron as an excellent
            candidate, as its API <br>
            >>> exposes things at an individual table level,
            requiring the client to <br>
            >>> join that information to get the answers they
            need.<br>
            >>><br>
            >>> Once that is done, we could examine the
            results, and use them as the <br>
            >>> basis for proceeding with something more
            comprehensive. Does that <br>
            >>> sound like a good approach to (all of) you?<br>
            >> Did anyone bring up the differences between control
            plane APIs and data<br>
            >> APIs and the applicability of GraphQL to the latter
            and not the former?<br>
            >><br>
            >> For example, a control plane API to reboot a server
            instance looks like<br>
            >> this:<br>
            >><br>
            >> POST /servers/{uuid}/action<br>
            >> {<br>
            >>       "reboot" : {<br>
            >>           "type" : "HARD"<br>
            >>       }<br>
            >> }<br>
            >><br>
            >> how does that map to GraphQL? Via GraphQL's
            "mutations" [0]? That<br>
            >> doesn't really work since the server object isn't
            being mutated. I mean,<br>
            >> the state of the server will *eventually* be
            mutated when the reboot<br>
            >> action starts kicking in (the above is an async
            operation returning a<br>
            >> 202 Accepted). But the act of hitting POST
            /servers/{uuid}/action<br>
            >> doesn't actually mutate the server's state.<br>
            >><br>
            >> This is just one example of where GraphQL doesn't
            necessarily map well<br>
            >> to control plane APIs that happen to be built on
            top of REST/HTTP [1]<br>
            >><br>
            >> Bottom line for me would be what is the perceivable
            benefit that all of<br>
            >> our users would receive given the (very costly)
            overhaul of our APIs<br>
            >> that would likely be required.<br>
            >><br>
            >> Best,<br>
            >> -jay<br>
            >><br>
            >> [0] <a href="http://graphql.org/learn/queries/#mutations" rel="noreferrer" target="_blank">http://graphql.org/learn/queries/#mutations</a><br>
            >> [1] One could argue (and I have in the past) that
            POST<br>
            >> /servers/{uuid}/action isn't a RESTful interface at
            all...<br>
            >><br>
            >>
__________________________________________________________________________
            <br>
            >><br>
            >> OpenStack Development Mailing List (not for usage
            questions)<br>
            >> Unsubscribe: <br>
            >> <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>
            >><br>
            >>
__________________________________________________________________________
            <br>
            >><br>
            >> OpenStack Development Mailing List (not for usage
            questions)<br>
            >> Unsubscribe: <br>
            >> <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>
            ><br>
            <br>
            -- <br>
            Gilles Dubreuil<br>
            Senior Software Engineer - Red Hat - Openstack DFG
            Integration<br>
            Email: <a href="mailto:gilles@redhat.com" target="_blank">gilles@redhat.com</a><br>
            GitHub/IRC: gildub<br>
            Mobile: +61 400 894 219<br>
            <br>
            <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>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="m_4438341384216175053moz-signature" cols="72">-- 
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: <a class="m_4438341384216175053moz-txt-link-abbreviated" href="mailto:gilles@redhat.com" target="_blank">gilles@redhat.com</a>
GitHub/IRC: gildub
Mobile: +61 400 894 219 

</pre>
  </div></blockquote></div>