The branch is now available under feature/graphql on the neutron core
repository [1].
Just to summarize our initial requirements:
- GraphQL endpoint to be added through a new WeBoB/WSGI stack
- Add graphene library [2]
- Unit tests and implementation for GraphQL schema for networks, subnets
and ports Types.
I think we should support Relay by making the Schema Relay compliant and
support Node ID, cursor connections and .
This will offer re-fetch, automated pagination and caching out of the
box and not only will show the power of GraphQL but also because on the
long run it would more likely what would be needed for complex API
structures like we have across the board.
Any thoughts?
[1] https://git.openstack.org/cgit/openstack/neutron/log/?h=feature/graphql
[2] http://graphene-python.org/
On 31/05/18 17:27, Flint WALRUS wrote:
Hi Gilles, Ed,
I’m really glad and thrilled to read such good news!
At this point it’s cool to see that many initiatives have the same
convergent needs regarding GraphQL as it will give us a good traction
from the beginning if our PoC manage to sufficiently convince our peers.
Let me know as soon as the branch have been made, I’ll work on it.
Regards,
Fl1nt.
Le jeu. 31 mai 2018 à 09:17, Gilles Dubreuil <gdubr...@redhat.com
<mailto:gdubr...@redhat.com>> a écrit :
Hi Flint,
I wish it was "my" summit ;)
In the latter case I'd make the sessions an hour and not 20 or 40
minutes, well at least for the Forum part. And I will also make
only one summit a year instead of two (which is also a feed back I
got from the Market place). I've passed that during the user
feedback session.
Sorry for not responding earlier, @elmiko is going to send the
minutes of the API SIG forum session we had.
We confirmed Neutron to be the PoC.
We are going to use a feature branch, waiting for Miguel Lavalle
to confirm the request has been acknowledge by the Infra group.
The PoC goal is to show GraphQL efficiency.
So we're going to make something straightforward, use Neutron
existing server by adding the graphQL endpoint and cover few core
items such as network, subnets and ports (for example).
Also the idea of having a central point of access for OpenStack
APIs using GrahpQL stitching and delegation is exciting for
everyone (and I had obviously same feedback off the session) and
that's something that could happen once the PoC has convinced.
During the meeting, Jiri Tomasek explained how GraphQL could help
TripleO UI. Effectively they struggle with APIs requests and had
to create a middle(ware) module in JS to do API work and
reconstruction before the Javascript client can use it. GraphQL
would simplify the process and allow to get rid of the module. He
also explained, after the meeting, how Horizon could benefit as
well, allowing to use only JS and avoid Django altogether!
I've also been told that Zuul nees GraphQL.
Well basically the question is who doesn't need it?
Cheers,
Gilles
On 31/05/18 03:34, Flint WALRUS wrote:
Hi Gilles, I hope you enjoyed your Summit!?
Did you had any interesting talk to report about our little
initiative ?
Le dim. 6 mai 2018 à 15:01, Gilles Dubreuil <gdubr...@redhat.com
<mailto:gdubr...@redhat.com>> a écrit :
Akihiro, thank you for your precious help!
Regarding the choice of Neutron as PoC, I'm sorry for not
providing much details when I said "because of its specific
data model",
effectively the original mention was "its API exposes things
at an individual table level, requiring the client to join
that information to get the answers they need".
I realize now such description probably applies to many
OpenStack APIs.
So I'm not sure what was the reason for choosing Neutron.
I suppose Nova is also a good candidate because API is quite
complex too, in a different way, and need to expose the data
API and the control API plane as we discussed.
After all Neutron is maybe not the best candidate but it
seems good enough.
And as Flint say the extension mechanism shouldn't be an issue.
So if someone believe there is a better candidate for the
PoC, please speak now.
Thanks,
Gilles
PS: Flint, Thank you for offering to be the advocate for
Berlin. That's great!
On 06/05/18 02:23, Flint WALRUS wrote:
Hi Akihiro,
Thanks a lot for this insight on how neutron behave.
We would love to get support and backing from the neutron
team in order to be able to get the best PoC possible.
Someone suggested neutron as a good choice because of it
simple database model. As GraphQL can manage your behavior
of an extension declaring its own schemes I don’t think it
would take that much time to implement it.
@Gilles, if I goes to the berlin summitt I could definitely
do the networking and relationship work needed to get
support on our PoC from different teams members. This would
help to spread the world multiple time and don’t have a long
time before someone come to talk about this subject as what
happens with the 2015 talk of the Facebook speaker.
Le sam. 5 mai 2018 à 18:05, Akihiro Motoki
<amot...@gmail.com <mailto:amot...@gmail.com>> a écrit :
Hi,
I am happy to see the effort to explore a new API mechanism.
I would like to see good progress and help effort as API
liaison from the neutron team.
> Neutron has been selected for the PoC because of its
specific data model
On the other hand, I am not sure this is the right
reason to choose 'neutron' only from this reason. I
would like to note "its specific data model" is not the
reason that makes the progress of API versioning slowest
in the OpenStack community. I believe it is worth
recognized as I would like not to block the effort due
to the neutron-specific reasons.
The most complicated point in the neutron API is that
the neutron API layer allows neutron plugins to declare
which features are supported. The neutron API is a
collection of API extensions defined in the neutron-lib
repo and each neutron plugin can declare which subset(s)
of the neutron APIs are supported. (For more detail, you
can check how the neutron API extension mechanism is
implemented). It is not defined only by the neutron API
layer. We need to communicate which API features are
supported by communicating enabled service plugins.
I am afraid that most efforts to explore a new mechanism
in neutron will be spent to address the above points
which is not directly related to GraphQL itself.
Of course, it would be great if you overcome
long-standing complicated topics as part of GraphQL
effort :)
I am happy to help the effort and understand how the
neutron API is defined.
Thanks,
Akihiro
2018年5月5日(土) 18:16 Gilles Dubreuil <gdubr...@redhat.com
<mailto:gdubr...@redhat.com>>:
Hello,
Few of us recently discussed [1] how GraphQL [2],
the next evolution
from REST, could transform OpenStack APIs for the
better.
Effectively we believe OpenStack APIs provide
perfect use cases for
GraphQL DSL approach, to bring among other
advantages, better
performance and stability, easier developments and
consumption, and with
GraphQL Schema provide automation capabilities never
achieved before.
The API SIG suggested to start an API GraphQL Proof
of Concept (PoC) to
demonstrate the capabilities before eventually
extend GraphQL to other
projects.
Neutron has been selected for the PoC because of its
specific data model.
So if you are interested, please join us.
For those who can make it, we'll also discuss this
during the SIG API
BoF at OpenStack Summit at Vancouver [3]
To learn more about GraphQL, check-out
howtographql.com <http://howtographql.com> [4].
So let's get started...
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html
[2] http://graphql.org/
[3]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
[4] https://www.howtographql.com/
Regards,
Gilles
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
