<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 05/05/18 09:42, Flint WALRUS wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAG+53uaMFxwrkaRUM4VigFazvxr71GzaG6GVYx8DptFgeZMzTQ@mail.gmail.com">I
will not attend the vancouver summit but I’ll try to attend the
berlin one as it’s closer to me.<br>
</blockquote>
<br>
No worries, I hope "networking" at Vancouver will allow to grab good
support and rocket the momentum :).<br>
Unfortunately I'm not sure to make it to Berlin time wise and
distance wise too. <br>
<br>
<blockquote type="cite"
cite="mid:CAG+53uaMFxwrkaRUM4VigFazvxr71GzaG6GVYx8DptFgeZMzTQ@mail.gmail.com"><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>
</blockquote>
<br>
Flint, I think that's an invaluable experience. Thank you for
bringing in and also what you've expressed is very important too. I
believe there are needs to be addressed. <br>
The viewpoint of consumers has been lacking. And the API SIG exists
to take it in consideration but we need more people involved.<br>
It seems the ransom of the success hitting as now a critical mass of
supporters is needed to be able to get any requirement accepted.<br>
Especially such requirements touch project wide components (API)
living inside the entropy of the cloud structural complexity.<br>
This is why there is no doubt GraphQL data model simplification can
bring only good.<br>
<br>
From my side, I'm not core, just been consuming OpenStack APIs for
SDKs for the last 2 years and I feel we're stalling.<br>
<br>
So I'm more than happy to help and get more involved but we're going
to need neutron core and other APIs core members believers.<br>
<br>
Thanks,<br>
Gilles<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAG+53uaMFxwrkaRUM4VigFazvxr71GzaG6GVYx8DptFgeZMzTQ@mail.gmail.com">
<div class="gmail_quote">
<div dir="ltr">Le sam. 5 mai 2018 à 01:18, 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>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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
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="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" 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>