subject:"Re\: \[openstack\-dev\] \[neutron\]\[api\]\[grapql\] Proof of Concept"

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

2018-08-24 Thread Miguel Lavalle

Gilles,

Ok. Added the patches in Gerrit to this coming Tuesday Neutron weekly
meeting agenda. I will highlight the patches during the meeting

Regards

On Thu, Aug 23, 2018 at 7:09 PM, Gilles Dubreuil 
wrote:

>
>
> On 24/08/18 04:58, Slawomir Kaplonski wrote:
>
>> Hi Miguel,
>>
>> I’m not sure but maybe You were looking for those patches:
>>
>> https://review.openstack.org/#/q/project:openstack/neutron+b
>> ranch:feature/graphql
>>
>>
> Yes that's the one, it's under Tristan Cacqueray name as he helped getting
> started.
>
> Wiadomość napisana przez Miguel Lavalle  w dniu
>>> 23.08.2018, o godz. 18:57:
>>>
>>> Hi Gilles,
>>>
>>> Ed pinged me earlier today in IRC in regards to this topic. After
>>> reading your message, I assumed that you had patches up for review in
>>> Gerrit. I looked for them, with the intent to list them in the agenda of
>>> the next Neutron team meeting, to draw attention to them. I couldn't find
>>> any, though: https://review.openstack.org/#
>>> /q/owner:%22Gilles+Dubreuil+%253Cgdubreui%2540redhat.com%253E%22
>>>
>>> So, how can we help? This is our meetings schedule:
>>> http://eavesdrop.openstack.org/#Neutron_Team_Meeting. Given that you
>>> are Down Under at UTC+10, the most convenient meeting for you is the one on
>>> Monday (even weeks), which would be Tuesday at 7am for you. Please note
>>> that we have an on demand section in our agenda:
>>> https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda. Feel
>>> free to add topics in that section when you have something to discuss with
>>> the Neutron team.
>>>
>>
> Now that we have a working base API serving GraphQL requests we need to do
> provide the data in respect of Oslo Policy and such.
>
> Thanks for the pointers, I'll add the latter to the Agenda and will be at
> next meeting.
>
>
>
>
>>> Best regards
>>>
>>> Miguel
>>>
>>> On Sun, Aug 19, 2018 at 10:57 PM, Gilles Dubreuil 
>>> wrote:
>>>
>>>
>>> On 25/07/18 23:48, Ed Leafe wrote:
>>> On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
>>> The branch is now available under feature/graphql on the neutron core
>>> repository [1].
>>> I wanted to follow up with you on this effort. I haven’t seen any
>>> activity on StoryBoard for several weeks now, and wanted to be sure that
>>> there was nothing blocking you that we could help with.
>>>
>>>
>>> -- Ed Leafe
>>>
>>>
>>>
>>> Hi Ed,
>>>
>>> Thanks for following up.
>>>
>>> There has been 2 essential counterproductive factors to the effort.
>>>
>>> The first is that I've been busy attending issues on other part of my
>>> job.
>>> The second one is the lack of response/follow-up from the Neutron core
>>> team.
>>>
>>> We have all the plumbing in place but we need to layer the data through
>>> oslo policies.
>>>
>>> Cheers,
>>> Gilles
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> —
>> Slawek Kaplonski
>> Senior software engineer
>> Red Hat
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
__
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

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

2018-08-23 Thread Gilles Dubreuil

On 24/08/18 04:58, Slawomir Kaplonski wrote:

Hi Miguel,

I’m not sure but maybe You were looking for those patches:

https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/graphql

Yes that's the one, it's under Tristan Cacqueray name as he helped
getting started.

Wiadomość napisana przez Miguel Lavalle w dniu
23.08.2018, o godz. 18:57:

Hi Gilles,

Ed pinged me earlier today in IRC in regards to this topic. After reading your
message, I assumed that you had patches up for review in Gerrit. I looked for
them, with the intent to list them in the agenda of the next Neutron team
meeting, to draw attention to them. I couldn't find any, though:
https://review.openstack.org/#/q/owner:%22Gilles+Dubreuil+%253Cgdubreui%2540redhat.com%253E%22

So, how can we help? This is our meetings schedule:
http://eavesdrop.openstack.org/#Neutron_Team_Meeting. Given that you are Down
Under at UTC+10, the most convenient meeting for you is the one on Monday (even
weeks), which would be Tuesday at 7am for you. Please note that we have an on
demand section in our agenda:
https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda. Feel free to
add topics in that section when you have something to discuss with the Neutron
team.

Now that we have a working base API serving GraphQL requests we need to
do provide the data in respect of Oslo Policy and such.

Thanks for the pointers, I'll add the latter to the Agenda and will be
at next meeting.

Best regards

Miguel

On Sun, Aug 19, 2018 at 10:57 PM, Gilles Dubreuil wrote:

On 25/07/18 23:48, Ed Leafe wrote:
On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil wrote:
The branch is now available under feature/graphql on the neutron core
repository [1].
I wanted to follow up with you on this effort. I haven’t seen any activity on
StoryBoard for several weeks now, and wanted to be sure that there was nothing
blocking you that we could help with.

-- Ed Leafe

Hi Ed,

Thanks for following up.

There has been 2 essential counterproductive factors to the effort.

The first is that I've been busy attending issues on other part of my job.
The second one is the lack of response/follow-up from the Neutron core team.

We have all the plumbing in place but we need to layer the data through oslo
policies.

Cheers,
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

—
Slawek Kaplonski
Senior software engineer
Red Hat

--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

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

2018-08-23 Thread Slawomir Kaplonski

Hi Miguel,

I’m not sure but maybe You were looking for those patches:

https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/graphql


> Wiadomość napisana przez Miguel Lavalle  w dniu 
> 23.08.2018, o godz. 18:57:
> 
> Hi Gilles,
> 
> Ed pinged me earlier today in IRC in regards to this topic. After reading 
> your message, I assumed that you had patches up for review in Gerrit. I 
> looked for them, with the intent to list them in the agenda of the next 
> Neutron team meeting, to draw attention to them. I couldn't find any, though: 
> https://review.openstack.org/#/q/owner:%22Gilles+Dubreuil+%253Cgdubreui%2540redhat.com%253E%22
> 
> So, how can we help? This is our meetings schedule: 
> http://eavesdrop.openstack.org/#Neutron_Team_Meeting. Given that you are Down 
> Under at UTC+10, the most convenient meeting for you is the one on Monday 
> (even weeks), which would be Tuesday at 7am for you. Please note that we have 
> an on demand section in our agenda: 
> https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda. Feel free 
> to add topics in that section when you have something to discuss with the 
> Neutron team.
> 
> Best regards
> 
> Miguel
> 
> On Sun, Aug 19, 2018 at 10:57 PM, Gilles Dubreuil  wrote:
> 
> 
> On 25/07/18 23:48, Ed Leafe wrote:
> On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
> The branch is now available under feature/graphql on the neutron core 
> repository [1].
> I wanted to follow up with you on this effort. I haven’t seen any activity on 
> StoryBoard for several weeks now, and wanted to be sure that there was 
> nothing blocking you that we could help with.
> 
> 
> -- Ed Leafe
> 
> 
> 
> Hi Ed,
> 
> Thanks for following up.
> 
> There has been 2 essential counterproductive factors to the effort.
> 
> The first is that I've been busy attending issues on other part of my job.
> The second one is the lack of response/follow-up from the Neutron core team.
> 
> We have all the plumbing in place but we need to layer the data through oslo 
> policies.
> 
> Cheers,
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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

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

2018-08-23 Thread Miguel Lavalle

Hi Gilles,

Ed pinged me earlier today in IRC in regards to this topic. After reading
your message, I assumed that you had patches up for review in Gerrit. I
looked for them, with the intent to list them in the agenda of the next
Neutron team meeting, to draw attention to them. I couldn't find any,
though:
https://review.openstack.org/#/q/owner:%22Gilles+Dubreuil+%253Cgdubreui%2540redhat.com%253E%22

So, how can we help? This is our meetings schedule:
http://eavesdrop.openstack.org/#Neutron_Team_Meeting. Given that you are
Down Under at UTC+10, the most convenient meeting for you is the one on
Monday (even weeks), which would be Tuesday at 7am for you. Please note
that we have an on demand section in our agenda:
https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda. Feel
free to add topics in that section when you have something to discuss with
the Neutron team.

Best regards

Miguel

On Sun, Aug 19, 2018 at 10:57 PM, Gilles Dubreuil 
wrote:

>
>
> On 25/07/18 23:48, Ed Leafe wrote:
>
>> On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
>>
>>> The branch is now available under feature/graphql on the neutron core
>>> repository [1].
>>>
>> I wanted to follow up with you on this effort. I haven’t seen any
>> activity on StoryBoard for several weeks now, and wanted to be sure that
>> there was nothing blocking you that we could help with.
>>
>>
>> -- Ed Leafe
>>
>>
>>
>> Hi Ed,
>
> Thanks for following up.
>
> There has been 2 essential counterproductive factors to the effort.
>
> The first is that I've been busy attending issues on other part of my job.
> The second one is the lack of response/follow-up from the Neutron core
> team.
>
> We have all the plumbing in place but we need to layer the data through
> oslo policies.
>
> Cheers,
> 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

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

2018-08-19 Thread Gilles Dubreuil




On 25/07/18 23:48, Ed Leafe wrote:

On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:

The branch is now available under feature/graphql on the neutron core 
repository [1].

I wanted to follow up with you on this effort. I haven’t seen any activity on 
StoryBoard for several weeks now, and wanted to be sure that there was nothing 
blocking you that we could help with.


-- Ed Leafe




Hi Ed,

Thanks for following up.

There has been 2 essential counterproductive factors to the effort.

The first is that I've been busy attending issues on other part of my job.
The second one is the lack of response/follow-up from the Neutron core team.

We have all the plumbing in place but we need to layer the data through 
oslo policies.


Cheers,
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

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

2018-07-25 Thread Ed Leafe

On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
> 
> The branch is now available under feature/graphql on the neutron core 
> repository [1].

I wanted to follow up with you on this effort. I haven’t seen any activity on 
StoryBoard for several weeks now, and wanted to be sure that there was nothing 
blocking you that we could help with.

-- Ed Leafe

__
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

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

2018-06-06 Thread Gilles Dubreuil

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

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

2018-05-31 Thread Flint WALRUS

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

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

2018-05-31 Thread Gilles Dubreuil




On 31/05/18 13:08, Ed Leafe wrote:

On May 6, 2018, at 8:01 AM, Gilles Dubreuil  wrote:


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.

Blame Monty!

It was Monty who suggested Neutron due to his particular experience working 
with the API. Since none of the rest of us in the API-SIG had any better 
suggestions, that was what we passed on to you. But I think that any target 
that demonstrates the advantages to be had by adopting GraphQL is fine. So if 
the team working on this think they can create a more impressive PoC with 
another API, the API-SIG will support that.


-- Ed Leafe





Well after being explained the story of the duck versus the duck parts 
(liver, heart, etc) it makes sense. With Neutron the API provides lots 
of parts but consumers have to put the part together to get the whole.


So Neutron is a good candidate as GraphQL will be able to show how it 
can fetch several parts at once (maybe not the whole beast since the PoC 
will cover only a fraction of the API).


And as you said as any API it should allow for GraphQL to show it's 
performance anyway.


So I believe we're good.

Cheers,
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

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

2018-05-31 Thread Gilles Dubreuil


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

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

2018-05-30 Thread Ed Leafe

On May 6, 2018, at 8:01 AM, Gilles Dubreuil  wrote:

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

Blame Monty!

It was Monty who suggested Neutron due to his particular experience working 
with the API. Since none of the rest of us in the API-SIG had any better 
suggestions, that was what we passed on to you. But I think that any target 
that demonstrates the advantages to be had by adopting GraphQL is fine. So if 
the team working on this think they can create a more impressive PoC with 
another API, the API-SIG will support that.

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
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

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

2018-05-30 Thread Flint WALRUS

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

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

2018-05-06 Thread 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!

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

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/

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

2018-05-05 Thread 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.

Le sam. 5 mai 2018 à 18:05, Akihiro Motoki  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 :
>
>> 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
>
__
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

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

2018-05-05 Thread 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.

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15 matches

Site Navigation

Mail list logo

Footer information