Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180505/8a050877/attachment.html>