Open Stack

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 <gdubreui at 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 <amotoki at 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 <gdubreui at 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-request at 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-request at 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: gilles at redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180530/c5ed312a/attachment.html>