Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Yeah, when I said foundation I’m talking about the community.

@Gilles, count me on if you need someone to work with.
Le sam. 5 mai 2018 à 17:20, Jeremy Stanley  a écrit :

> On 2018-05-04 23:42:59 + (+), Flint WALRUS wrote:
> [...]
> > what operators are expecting the foundation to do with such
> > challenges.
> [...]
>
> If by "the foundation" you mean the OpenStack Foundation then this
> isn't really their remit. You need invested members of the community
> at large to join you in taking up this challenge (as you've
> correctly noted elsewhere). While the foundation and other
> leadership bodies may occasionally find successful ways to steer the
> project as a whole, the community is made up of individual entities
> (contributors and in many cases the organizations who employ them)
> who have their own goals and set their own priorities.
> --
> Jeremy Stanley
> __
> 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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Jeremy Stanley]

On 2018-05-04 23:42:59 + (+), Flint WALRUS wrote:
[...]
> what operators are expecting the foundation to do with such
> challenges.
[...]

If by "the foundation" you mean the OpenStack Foundation then this
isn't really their remit. You need invested members of the community
at large to join you in taking up this challenge (as you've
correctly noted elsewhere). While the foundation and other
leadership bodies may occasionally find successful ways to steer the
project as a whole, the community is made up of individual entities
(contributors and in many cases the organizations who employ them)
who have their own goals and set their own priorities.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

re
declarative anyway,
>> has advantages.
>
> +1
>
>> Thanks,
>> Kevin
>> ____
>> From: Jay Pipes [jaypi...@gmail.com
<mailto:jaypi...@gmail.com>]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev@lists.openstack.org
<mailto: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
mailto: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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>

_

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

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  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  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: ) {
>>  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: , 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: ) {
>> > 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 
>> >>> 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
>> >>>

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

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 <mailto:gdubr...@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: ) {
 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: , 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: ) {
>     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 <mailto:jaypi...@gmail.com>]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev@lists.openstack.org
<mailto: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
mailto: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
>

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

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  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: ) {
>  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: , 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: ) {
> > 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 
> >>> 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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

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: ) {
    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: , 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: ) {
    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  
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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

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: ) {
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  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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

+1 for a PoC


On 04/05/18 03:56, Flint WALRUS wrote:

Exactly !
Le jeu. 3 mai 2018 à 19:55, Flint WALRUS > a écrit :


It seems to be a fair way to do it. I do second the Neutron API as
a good candidate.

I’ll be happy to give a hand.

@jay I’ve already sum my points upper, but I could definitely have
better exemples if needed.

I’m operating and dealing with a large (really) Openstack platform
and GraphQL would have tremendous performances impacts for sure.
But you’re right proof have to be made.
Le jeu. 3 mai 2018 à 18:57, Ed Leafe mailto:e...@leafe.com>> a écrit :

On May 2, 2018, at 2:40 AM, Gilles Dubreuil
mailto: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?

-- Ed Leafe







__
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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Fox, Kevin M]

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.

Even without using GraphQL, Making the api more declarative anyway, has 
advantages.

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  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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Exactly !
Le jeu. 3 mai 2018 à 19:55, Flint WALRUS  a écrit :

> It seems to be a fair way to do it. I do second the Neutron API as a good
> candidate.
>
> I’ll be happy to give a hand.
>
> @jay I’ve already sum my points upper, but I could definitely have better
> exemples if needed.
>
> I’m operating and dealing with a large (really) Openstack platform and
> GraphQL would have tremendous performances impacts for sure. But you’re
> right proof have to be made.
> Le jeu. 3 mai 2018 à 18:57, Ed Leafe  a écrit :
>
>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil  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?
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>> 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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

It seems to be a fair way to do it. I do second the Neutron API as a good
candidate.

I’ll be happy to give a hand.

@jay I’ve already sum my points upper, but I could definitely have better
exemples if needed.

I’m operating and dealing with a large (really) Openstack platform and
GraphQL would have tremendous performances impacts for sure. But you’re
right proof have to be made.
Le jeu. 3 mai 2018 à 18:57, Ed Leafe  a écrit :

> On May 2, 2018, at 2:40 AM, Gilles Dubreuil  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?
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Ed Leafe]

On May 3, 2018, at 12:50 PM, Jay Pipes  wrote:
> 
> 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.

That was our thinking: no one would agree to such an effort without first 
demonstrating some tangible results. Hence the idea for an experiment with just 
a single service, done by those interested in seeing it happen. If GraphQL can 
do what they imagine it could do, then they would be able to demonstrate the 
benefit that you (and everyone else) would want to see.


-- Ed Leafe






__
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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Jay Pipes]

On 05/03/2018 12:57 PM, Ed Leafe wrote:

On May 2, 2018, at 2:40 AM, Gilles Dubreuil  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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Ed Leafe]

On May 2, 2018, at 2:40 AM, Gilles Dubreuil  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?

-- Ed Leafe






__
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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Hi Gilles, folks,

Nice to read such answers, I’m really thrilled by what could goes out from
this discussion.

One last thing regarding the SDK and Broker part of the discussion.

GraphQL and SDK:

Obviously as you noticed it, I was focused on the python-openstacksdk part
of things even if it apply to the autonomous Openstack4j JAVA SDK or any
other SDK for your favorite language.

I do agree with you, GraphQL being a DSL it should in a long (or maybe not
so long depending the adoption rate ;-) ) run replace the REST part of the
SDK, however, I think the client libraries (at least for the python side of
think) should be enforced by the Openstack foundation/devs as it would
avoid having devs from one project/tool that will join the big tent to use
a different library of its own and so create fragmentation and pitfalls
already mentioned upper on my previous message.

For example, if I let our devs use their own client library for both
GraphQL and workers logic I will end up with at least a dozen of different
libraries per teams and it will be a nightmare to debug, investigate,
maintain etc.

For sure as this is a personal example some could argue that we should
enforce this choice at the company level and not at the solution level, but
if everyone talk the same language its easier to share information, make
consensus around a project, ease the development process by having a clear
and consistent path (Providing a common cookiecutter for all new projects)
and would give us the ability to manage a complete project with the
Openstack client tool such as:

```openstack brick init ```

Here I choose the “brick” term as a keyword in order to avoid namespace
collisions as projects and services are already used for ops side of things.

GraphQL broker:

Ok I see what you means and I honestly love the idea as it’s an elegant way
to split responsibility while being able to scale and efficiently
distribute requests.

I think that’s the implicit idea behind swift-proxy and how (most of)
companies achieve the horizontal scaling with HAProxy as a loadbalancer in
front of classic Openstack WSGI endpoints.

As this is a builtin feature of GraphQL that would allows a way better
service discovery and routing architecture.

Kind regards,
G.

Le mer. 2 mai 2018 à 09:41, Gilles Dubreuil  a écrit :

> I fixed the GraphQL typo (my mistake) in $subject to help with future ML
> searches.
>
> Please see inline too.
>
> On 02/05/18 07:37, Flint WALRUS wrote:
>
> Ok, here are my two cents regarding GraphQL integration within Openstack
> and some thoughts around this topic.
>
> 1°/- Openstack SDK should still exist and should be in my humble opinion a
> critical focus as it allow following benefits for large and medium
> companies :
>
> • It provide a common and clean structure for Openstack developments and
> should be used either by projects or tools willing to integrate Openstack
> as it will then create some sort of standard.
>
> For instance, here in my job we have A LOT (More than 10 000 peoples
> working within around 130 teams) of teams developing over Openstack using
> the SDK as a common shared base layout.
> That allow for teams to easily share and co-develop on projects. Those
> teams are spread around the world and so need to have clean guidelines as
> it avoid them reinventing the wheel, they’re not stuck with someone else
> obscure code created by another persons on the other side of the world or
> within a different timezone.
> Additionally it streamline our support and debug processes.
>
>
> I'm assuming you're talking about the Python SDK (Shade) which would make
> sense because it's the "lingua franca" of all projects.
>
> Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely to
> replace its REST SDK on the long run. GraphQL is a DSL bypassing a SDK need
> which get replaced with GraphQL client library. Basically the change, not a
> rewrite, is inevitable. But I insist on "the long run" part, initially both
> in parallel one wrapping the other, then progressively the REST content
> moving across to GraphQL.
>
>
> • 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.
>
>
>
> This point is for me the most important one as it will fix flaws we get
> currently with the rest APIs development within Openstack.
>
> First it will avoid a fresh developer to be confused by too many options.
> Honestly, I know we are open etc, but this point really need to be
> addressed as it is the main issue that I face with Openstack advocacy since
> many years now.
>
> Having too many options even if explained within the documentation daunt a
> lot of people to quickly give a hand with projects.
>
> For instance I have a workm

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

I fixed the GraphQL typo (my mistake) in $subject to help with future ML 
searches.


Please see inline too.


On 02/05/18 07:37, Flint WALRUS wrote:
Ok, here are my two cents regarding GraphQL integration within 
Openstack and some thoughts around this topic.


1°/- Openstack SDK should still exist and should be in my humble 
opinion a critical focus as it allow following benefits for large and 
medium companies :


• It provide a common and clean structure for Openstack developments 
and should be used either by projects or tools willing to integrate 
Openstack as it will then create some sort of standard.


For instance, here in my job we have A LOT (More than 10 000 peoples 
working within around 130 teams) of teams developing over Openstack 
using the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those 
teams are spread around the world and so need to have clean guidelines 
as it avoid them reinventing the wheel, they’re not stuck with someone 
else obscure code created by another persons on the other side of the 
world or within a different timezone.

Additionally it streamline our support and debug processes.


I'm assuming you're talking about the Python SDK (Shade) which would 
make sense because it's the "lingua franca" of all projects.


Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely 
to replace its REST SDK on the long run. GraphQL is a DSL bypassing a 
SDK need which get replaced with GraphQL client library. Basically the 
change, not a rewrite, is inevitable. But I insist on "the long run" 
part, initially both in parallel one wrapping the other, then 
progressively the REST content moving across to GraphQL.




• 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.





This point is for me the most important one as it will fix flaws we 
get currently with the rest APIs development within Openstack.


First it will avoid a fresh developer to be confused by too many 
options. Honestly, I know we are open etc, but this point really need 
to be addressed as it is the main issue that I face with Openstack 
advocacy since many years now.


Having too many options even if explained within the documentation 
daunt a lot of people to quickly give a hand with projects.


For instance I have a workmate that is currently working on an 
internal tool which ask me how should he implement its project REST 
interfaces.


I told him TO NOT use WSME and to stick with what have been done by a 
major project. Unfortunately he choose to copy what have been done by 
Octavia which is actually using... WSME...


GraphQL gives us the opportunity and ability to fix Openstack 
development inconsistencies by providing and enforcing a clean 
guideline regarding which library should be used and in which way.


That would also have the side effect to easy the entry level for a new 
Openstack developer.


I couldn't agree more!



• New architecture opportunities.

For sure that will bring new architecture opportunities, but the 
broker thing is not a good idea as each project should be able to be 
autonomous.


I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use 
a RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and 
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much 
debugging/investigation hell that we now plan to have a serious 
benchmark and test of ZMQ.


One thing that I would love to see with GraphQL is a better 
distributed and traceable model.




Exactly and the term broker I used is far from ideal,  I meant it in the 
context of a broker pattern providing distributed API service. GraphQL 
has "stiching" capabilities allowing to forward request to diverse 
GraphQL service, kind of a proxy, ideally such service to be distributed 
itself.


The idea behind is a GraphQL proxy offering a single point of entry for 
OpenStack entire stack and of course leaving complete autonomy to the 
all services.


https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405

Anyway, I’m glad someone started this discussion as I feel it is a 
really important topic that would highly help Openstack on more than 
just interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil > a écrit :




On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)




Openstack have to provide both endpoints type for a while for
backward compatibility in order to smooth the transition.