<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body 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="moz-txt-link-freetext" href="https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session">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="moz-txt-link-freetext" href="http://graphql.org/code/#python">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>
<br>
<div class="moz-cite-prefix">On 04/05/18 23:16, Flint WALRUS wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAG+53ubuOn4mas40+aA6odaTFLECscnLh_JienDMaWm_W3t1Jg@mail.gmail.com">
<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"
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">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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" 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>
>><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" 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>
><br>
<br>
-- <br>
Gilles Dubreuil<br>
Senior Software Engineer - Red Hat - Openstack DFG
Integration<br>
Email: <a href="mailto:gilles@redhat.com" target="_blank"
moz-do-not-send="true">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" 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>
<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>