On 05/05/18 09:42, Flint WALRUS wrote:
I will not attend the vancouver summit but I’ll try to attend the
berlin one as it’s closer to me.
No worries, I hope "networking" at Vancouver will allow to grab good
support and rocket the momentum :).
Unfortunately I'm not sure to make it to Berlin time wise and distance
wise too.
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.
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.
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.
The viewpoint of consumers has been lacking. And the API SIG exists to
take it in consideration but we need more people involved.
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.
Especially such requirements touch project wide components (API) living
inside the entropy of the cloud structural complexity.
This is why there is no doubt GraphQL data model simplification can
bring only good.
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.
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.
Thanks,
Gilles
Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil <[email protected]
<mailto:[email protected]>> a écrit :
Right, let's announce the Proof of Concept project as of Neutron,
invite anyone interested and start it.
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:
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
Yeah, Graphene is the only one listed by GraphQL organization for
Python: http://graphql.org/code/#python.
I think we should take this discussion on the coming project thread.
Thank you everyone and see you there.
Cheers,
Gilles
On 04/05/18 23:16, Flint WALRUS wrote:
As clarify by Gilles and Kevin we absolutely can get GraphQL
with the control plan API and the workers api.
Ok, how do start to work on that? What’s the next step?
Which server library do we want to use?
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.
Are we ok to try to use neutron as a PoC service?
Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <[email protected]
<mailto:[email protected]>> a écrit :
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 [[email protected]
<mailto:[email protected]>]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: [email protected]
<mailto:[email protected]>
>> 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
<[email protected] <mailto:[email protected]>>
>>> 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:
>>
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
__________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: [email protected] <mailto:[email protected]>
GitHub/IRC: gildub
Mobile: +61 400 894 219
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:[email protected] <mailto:[email protected]>
GitHub/IRC: gildub
Mobile: +61 400 894 219
--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: [email protected]
GitHub/IRC: gildub
Mobile: +61 400 894 219
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
