<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>