Open Stack

Actually Mutations fields are only data to be displayed, if needed, by 
the response.
The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
   updateServer(id: <UUID>) {
     reboot(type: "HARD")
   }
}

Also the latter example would be a "data API" equivalent using CRUD 
function like "updateServer"

And the following example would be a "plane API" equivalent approach 
with an action function:

mutation hardReboot {
   rebootServer(id: <UUID>, type: "HARD")
}

Sorry for the initial confusion but I think this is important because 
GraphQL schema helps clarify data and the operations.


On 04/05/18 13:20, Gilles Dubreuil wrote:
>
> On 04/05/18 05:34, Fox, Kevin M wrote:
>> k8s does that I think by separating desired state from actual state 
>> and working to bring the two inline. the same could (maybe even 
>> should) be done to openstack. But your right, that is not a small 
>> amount of work.
>
> K8s makes perfect sense to follow declarative approach.
>
> That said a mutation following control plane API action semantic could 
> be very similar:
>
> mutation rebootServer {
>   Server(id: <UUID>) {
>     reboot: {
>       type: "HARD"
>     }
>   }
> }
>
>
> "rebootServer" being an alias to name the request.
>
>
>> Even without using GraphQL, Making the api more declarative anyway, 
>> has advantages.
>
> +1
>
>> Thanks,
>> Kevin
>> ________________________________________
>> From: Jay Pipes [jaypipes at gmail.com]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL 
>> inception?
>>
>> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubreui at redhat.com> 
>>> wrote:
>>>>> • We should get a common consensus before all projects start to 
>>>>> implement it.
>>>> This is going to be raised during the API SIG weekly meeting later 
>>>> this week.
>>>> API developers (at least one) from every project are strongly 
>>>> welcomed to participate.
>>>> I suppose it makes sense for the API SIG to be the place to discuss 
>>>> it, at least initially.
>>> It was indeed discussed, and we think that it would be a worthwhile 
>>> experiment. But it would be a difficult, if not impossible, proposal 
>>> to have adopted OpenStack-wide without some data to back it up. So 
>>> what we thought would be a good starting point would be to have a 
>>> group of individuals interested in GraphQL form an informal team and 
>>> proceed to wrap one OpenStack API as a proof-of-concept. Monty 
>>> Taylor suggested Neutron as an excellent candidate, as its API 
>>> exposes things at an individual table level, requiring the client to 
>>> join that information to get the answers they need.
>>>
>>> Once that is done, we could examine the results, and use them as the 
>>> basis for proceeding with something more comprehensive. Does that 
>>> sound like a good approach to (all of) you?
>> Did anyone bring up the differences between control plane APIs and data
>> APIs and the applicability of GraphQL to the latter and not the former?
>>
>> For example, a control plane API to reboot a server instance looks like
>> this:
>>
>> POST /servers/{uuid}/action
>> {
>>       "reboot" : {
>>           "type" : "HARD"
>>       }
>> }
>>
>> how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
>> doesn't really work since the server object isn't being mutated. I mean,
>> the state of the server will *eventually* be mutated when the reboot
>> action starts kicking in (the above is an async operation returning a
>> 202 Accepted). But the act of hitting POST /servers/{uuid}/action
>> doesn't actually mutate the server's state.
>>
>> This is just one example of where GraphQL doesn't necessarily map well
>> to control plane APIs that happen to be built on top of REST/HTTP [1]
>>
>> Bottom line for me would be what is the perceivable benefit that all of
>> our users would receive given the (very costly) overhaul of our APIs
>> that would likely be required.
>>
>> Best,
>> -jay
>>
>> [0] http://graphql.org/learn/queries/#mutations
>> [1] One could argue (and I have in the past) that POST
>> /servers/{uuid}/action isn't a RESTful interface at all...
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gilles at redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219