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