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 [jaypi...@gmail.com]
Sent: Thursday, May 03, 2018 10:50 AM
To: openstack-dev@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 <gdubr...@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-requ...@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-requ...@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: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
