Open Stack

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 <gdubreui at redhat.com> 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 <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]
>> >> 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
>>
>>
>> __________________________________________________________________________
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180504/8d107b7b/attachment.html>