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
--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:gil...@redhat.com <mailto:gil...@redhat.com>
GitHub/IRC: gildub
Mobile: +61 400 894 219
--
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
