I will not attend the vancouver summit but I’ll try to attend the berlin one as it’s closer to me.
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. Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil <[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]> 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]] >> >> Sent: Thursday, May 03, 2018 10:50 AM >> >> To: [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]> >> >>> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> __________________________________________________________________________ >> >> >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> >> [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] >> 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 >> > > -- > 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
