[openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

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

[Akihiro Motoki]

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.

Post by Gilles Dubreuil
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

Post by Gilles Dubreuil
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 [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)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Flint WALRUS]

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.

Post by Akihiro Motoki
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.

Post by Gilles Dubreuil
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

Post by Gilles Dubreuil
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 [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)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Gilles Dubreuil]

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!

Post by Flint WALRUS
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.
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.

Post by Gilles Dubreuil
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
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)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev