Re: [openstack-dev] [Openstack-operators] [nova] StarlingX diff analysis

[Flint WALRUS]

Hi matt, everyone,

I just read your analysis and would like to thank you for such work. I
really think there are numerous features included/used on this Nova rework
that would be highly beneficial for Nova and users of it.

I hope people will fairly appreciate you work.

I didn’t had time to check StarlingX code quality, how did you feel it
while you were doing your analysis?

Thanks a lot for this share.
I’ll have a closer look at it this afternoon as my company may be
interested by some features.

Kind regards,
G.
Le mar. 7 août 2018 à 00:03, Matt Riedemann  a écrit :

> In case you haven't heard, there was this StarlingX thing announced at
> the last summit. I have gone through the enormous nova diff in their
> repo and the results are in a spreadsheet [1]. Given the enormous
> spreadsheet (see a pattern?), I have further refined that into a set of
> high-level charts [2].
>
> I suspect there might be some negative reactions to even doing this type
> of analysis lest it might seem like promoting throwing a huge pile of
> code over the wall and expecting the OpenStack (or more specifically the
> nova) community to pick it up. That's not my intention at all, nor do I
> expect nova maintainers to be responsible for upstreaming any of this.
>
> This is all educational to figure out what the major differences and
> overlaps are and what could be constructively upstreamed from the
> starlingx staging repo since it's not all NFV and Edge dragons in here,
> there are some legitimate bug fixes and good ideas. I'm sharing it
> because I want to feel like my time spent on this in the last week
> wasn't all for nothing.
>
> [1]
>
> https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVzweSDZunU/edit?usp=sharing
> [2]
>
> https://docs.google.com/presentation/d/1P-__JnxCFUbSVlEoPX26Jz6VaOyNg-jZbBsmmKA2f0c/edit?usp=sharing
>
> --
>
> Thanks,
>
> Matt
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
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[[graphql] A starting point

[Flint WALRUS]

Oh! That’s its truly a sweet sweet attention, that will indeed really help
us to focus on what we have to do without having to goes through an
extensive email back and forth :-)

Thanks a lot!!
Le ven. 22 juin 2018 à 22:48, Ed Leafe  a écrit :

> On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil  wrote:
> >
> > This initial patch [1]  allows to retrieve networks, subnets.
> >
> > This is very easy, thanks to the graphene-sqlalchemy helper.
> >
> > The edges, nodes layer might be confusing at first meanwhile they make
> the Schema Relay-compliant in order to offer re-fetching, pagination
> features out of the box.
> >
> > The next priority is to set the unit test in order to implement
> mutations.
> >
> > Could someone help provide a base in order to respect Neutron test
> requirements?
>
> Glad to see some progress!
>
> We have migrated the API-SIG from Launchpad to StoryBoard [0],
> specifically so that your group has a place to record stories, tasks, etc.
> Please feel free to use this to help coordinated your work.
>
> [0] https://storyboard.openstack.org/#!/project/1039
>
>
> -- 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
>
__
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[[graphql] A starting point

[Flint WALRUS]

Hi Gilles, I just had a look at your patch, cool, thanks for the work.

ok, that good to start with a limited subsets of query types indeed, you're
right.

Ok, perfect for the patch to branch, I don't know why but I had the feeling
that you were requesting for the branch to be merged back and not for the
patch :D I just read my emails too quickly I suppose.

About your code, I feel that we should extract the schemas from the base.py
under neutron/api/graphql/schemas/ right now before the code became to
large, that would then allows for a better granularity.

Thanks.

Le ven. 22 juin 2018 à 08:42, Gilles Dubreuil  a
écrit :

>
>
> On 22/06/18 15:57, Flint WALRUS wrote:
>
> Hi everyone,
>
> Thanks for the updates and support, that appreciated.
>
> @Gilles, did you already implemented all the service types?
>
>
> We have query types for networks and subnets for now.
> Before we add more we are going to focus on oslo policies so we can access
> and modify those items in respect of the existing security approach.
> Then we will have a solid foundation to add more types.
>
>
>
> What is left to do? You already want to merge the feature branch with
> master?
>
>
> The feature branch graphql is the Proof of Concept and won't be merged to
> master until we have it full ready to share/demonstrate it to others.
> So we're pushing patches against that branch. The initial one to be
> hopefully merged soon.
>
>
>
> @tristan I’d like to work on the feature branch but I’ll wait for gilles
> answers as I don’t want to mess up having pieces of code everywhere.
>
> Thanks!
> Le ven. 22 juin 2018 à 06:44, Gilles Dubreuil  a
> écrit :
>
>>
>> On 22/06/18 09:21, Tristan Cacqueray wrote:
>>
>> Hi Flint,
>>
>> On June 21, 2018 5:32 pm, Flint WALRUS wrote:
>>
>> Hi everyone, sorry for the late answer but I’m currently trapped into a
>> cluster issue with cinder-volume that doesn’t give me that much time.
>>
>> That being said, I’ll have some times to work on this feature during the
>> summer (July/August) and so do some coding once I’ll have catched up with
>> your work.
>>
>> That's great to hear! The next step is to understand how to deal with
>> oslo policy and control objects access/modification.
>>
>> Did you created a specific tree or did you created a new graphql folder
>> within the neutron/neutron/api/ path regarding the schemas etc?
>>
>>
>> There is a feature/graphql branch were an initial patch[1] adds a new
>> neutron/api/graphql directory as well as a new test_graphql.py
>> functional tests.
>> The api-paste is also updated to expose the '/graphql' http endpoint.
>>
>> Not sure if we want to keep on updating that change, or propose further
>> code as new change on top of this skeleton?
>>
>>
>> Makes sense to merge it, I think we have the base we needed to get going.
>> I'll make it green so we can get merge it.
>>
>>
>> Regards,
>> -Tristan
>>
>>
>> Le sam. 16 juin 2018 à 08:42, Tristan Cacqueray 
>>  a
>> écrit :
>>
>> On June 15, 2018 10:42 pm, Gilles Dubreuil wrote:
>> > Hello,
>> >
>> > This initial patch [1]  allows to retrieve networks, subnets.
>> >
>> > This is very easy, thanks to the graphene-sqlalchemy helper.
>> >
>> > The edges, nodes layer might be confusing at first meanwhile they make
>> > the Schema Relay-compliant in order to offer re-fetching, pagination
>> > features out of the box.
>> >
>> > The next priority is to set the unit test in order to implement
>> mutations.
>> >
>> > Could someone help provide a base in order to respect Neutron test
>> > requirements?
>> >
>> >
>> > [1] [abandoned]
>>
>> Actually, the correct review (proposed on the feature/graphql branch)
>> is:
>>
>> [1] https://review.openstack.org/575898
>>
>> >
>> > Thanks,
>> > 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.o

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Flint WALRUS]

Hi everyone,

Thanks for the updates and support, that appreciated.

@Gilles, did you already implemented all the service types?

What is left to do? You already want to merge the feature branch with
master?

@tristan I’d like to work on the feature branch but I’ll wait for gilles
answers as I don’t want to mess up having pieces of code everywhere.

Thanks!
Le ven. 22 juin 2018 à 06:44, Gilles Dubreuil  a
écrit :

>
> On 22/06/18 09:21, Tristan Cacqueray wrote:
>
> Hi Flint,
>
> On June 21, 2018 5:32 pm, Flint WALRUS wrote:
>
> Hi everyone, sorry for the late answer but I’m currently trapped into a
> cluster issue with cinder-volume that doesn’t give me that much time.
>
> That being said, I’ll have some times to work on this feature during the
> summer (July/August) and so do some coding once I’ll have catched up with
> your work.
>
> That's great to hear! The next step is to understand how to deal with
> oslo policy and control objects access/modification.
>
> Did you created a specific tree or did you created a new graphql folder
> within the neutron/neutron/api/ path regarding the schemas etc?
>
>
> There is a feature/graphql branch were an initial patch[1] adds a new
> neutron/api/graphql directory as well as a new test_graphql.py
> functional tests.
> The api-paste is also updated to expose the '/graphql' http endpoint.
>
> Not sure if we want to keep on updating that change, or propose further
> code as new change on top of this skeleton?
>
>
> Makes sense to merge it, I think we have the base we needed to get going.
> I'll make it green so we can get merge it.
>
>
> Regards,
> -Tristan
>
>
> Le sam. 16 juin 2018 à 08:42, Tristan Cacqueray 
>  a
> écrit :
>
> On June 15, 2018 10:42 pm, Gilles Dubreuil wrote:
> > Hello,
> >
> > This initial patch [1]  allows to retrieve networks, subnets.
> >
> > This is very easy, thanks to the graphene-sqlalchemy helper.
> >
> > The edges, nodes layer might be confusing at first meanwhile they make
> > the Schema Relay-compliant in order to offer re-fetching, pagination
> > features out of the box.
> >
> > The next priority is to set the unit test in order to implement
> mutations.
> >
> > Could someone help provide a base in order to respect Neutron test
> > requirements?
> >
> >
> > [1] [abandoned]
>
> Actually, the correct review (proposed on the feature/graphql branch)
> is:
>
> [1] https://review.openstack.org/575898
>
> >
> > Thanks,
> > 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
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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[[graphql] A starting point

[Flint WALRUS]

Hi everyone, sorry for the late answer but I’m currently trapped into a
cluster issue with cinder-volume that doesn’t give me that much time.

That being said, I’ll have some times to work on this feature during the
summer (July/August) and so do some coding once I’ll have catched up with
your work.

Did you created a specific tree or did you created a new graphql folder
within the neutron/neutron/api/ path regarding the schemas etc?
Le sam. 16 juin 2018 à 08:42, Tristan Cacqueray  a
écrit :

> On June 15, 2018 10:42 pm, Gilles Dubreuil wrote:
> > Hello,
> >
> > This initial patch [1]  allows to retrieve networks, subnets.
> >
> > This is very easy, thanks to the graphene-sqlalchemy helper.
> >
> > The edges, nodes layer might be confusing at first meanwhile they make
> > the Schema Relay-compliant in order to offer re-fetching, pagination
> > features out of the box.
> >
> > The next priority is to set the unit test in order to implement
> mutations.
> >
> > Could someone help provide a base in order to respect Neutron test
> > requirements?
> >
> >
> > [1] [abandoned]
>
> Actually, the correct review (proposed on the feature/graphql branch)
> is:
>
> [1] https://review.openstack.org/575898
>
> >
> > Thanks,
> > 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

[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

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

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

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

[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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Yeah, when I said foundation I’m talking about the community.

@Gilles, count me on if you need someone to work with.
Le sam. 5 mai 2018 à 17:20, Jeremy Stanley <fu...@yuggoth.org> a écrit :

> On 2018-05-04 23:42:59 + (+0000), Flint WALRUS wrote:
> [...]
> > what operators are expecting the foundation to do with such
> > challenges.
> [...]
>
> If by "the foundation" you mean the OpenStack Foundation then this
> isn't really their remit. You need invested members of the community
> at large to join you in taking up this challenge (as you've
> correctly noted elsewhere). While the foundation and other
> leadership bodies may occasionally find successful ways to steer the
> project as a whole, the community is made up of individual entities
> (contributors and in many cases the organizations who employ them)
> who have their own goals and set their own priorities.
> --
> Jeremy Stanley
> __
> 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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

I will not attend the vancouver summit but I’ll try to attend the berlin
one as it’s closer to me.

However I’ll be happy to join the conversation and give a hand, especially
if you need an operational point of view as our Openstack usage is
constantly growing within an heterogeneous environment ranging from a
grizzly cluster (deprecating it this year) to a shiny Queens one on
multiple geographic area.

I think our setup gives us a really good point of view of what are the
Openstack PITA and what operators are expecting the foundation to do with
such challenges.
Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil <gdubr...@redhat.com> a écrit :

> Right, let's announce the Proof of Concept project as of Neutron, invite
> anyone interested and start it.
>
> There is an API SIG BoF at Vancouver, where we will announce it too. And
> for everyone who can attend, to be welcome to discuss it:
>
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
>
> Yeah, Graphene is the only one listed by GraphQL organization for Python:
> http://graphql.org/code/#python.
>
> I think we should take this discussion on the coming project thread.
>
> Thank you everyone and see you there.
>
> Cheers,
> Gilles
>
> On 04/05/18 23:16, Flint WALRUS wrote:
>
> As clarify by Gilles and Kevin we absolutely can  get GraphQL with the
> control plan API and the workers api.
>
> Ok, how do start to work on that? What’s the next step?
>
> Which server library do we want to use?
> I personally use graphene with python as it is the library listed by the
> official GraphQL website. I don’t even know if there is another library
> available indeed.
>
> Are we ok to try to use neutron as a PoC service?
>
> Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <gdubr...@redhat.com> a
> écrit :
>
>> Actually Mutations fields are only data to be displayed, if needed, by
>> the response.
>> The data changes comes with the parameters.
>> So the correct mutation syntax is:
>>
>> mutation rebootServer {
>>updateServer(id: ) {
>>  reboot(type: "HARD")
>>}
>> }
>>
>> Also the latter example would be a "data API" equivalent using CRUD
>> function like "updateServer"
>>
>> And the following example would be a "plane API" equivalent approach
>> with an action function:
>>
>> mutation hardReboot {
>>rebootServer(id: , type: "HARD")
>> }
>>
>> Sorry for the initial confusion but I think this is important because
>> GraphQL schema helps clarify data and the operations.
>>
>>
>> On 04/05/18 13:20, Gilles Dubreuil wrote:
>> >
>> > On 04/05/18 05:34, Fox, Kevin M wrote:
>> >> k8s does that I think by separating desired state from actual state
>> >> and working to bring the two inline. the same could (maybe even
>> >> should) be done to openstack. But your right, that is not a small
>> >> amount of work.
>> >
>> > K8s makes perfect sense to follow declarative approach.
>> >
>> > That said a mutation following control plane API action semantic could
>> > be very similar:
>> >
>> > mutation rebootServer {
>> >   Server(id: ) {
>> > reboot: {
>> >   type: "HARD"
>> > }
>> >   }
>> > }
>> >
>> >
>> > "rebootServer" being an alias to name the request.
>> >
>> >
>> >> Even without using GraphQL, Making the api more declarative anyway,
>> >> has advantages.
>> >
>> > +1
>> >
>> >> Thanks,
>> >> Kevin
>> >> 
>> >> From: Jay Pipes [jaypi...@gmail.com]
>> >> Sent: Thursday, May 03, 2018 10:50 AM
>> >> To: openstack-dev@lists.openstack.org
>> >> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
>> >> inception?
>> >>
>> >> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>> >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com>
>> >>> wrote:
>> >>>>> • We should get a common consensus before all projects start to
>> >>>>> implement it.
>> >>>> This is going to be raised during the API SIG weekly meeting later
>> >>>> this week.
>> >>>> API developers (at least one) from every project are strongly
>> >>>> welcomed to participate.
>> >>>> I suppose it makes 

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

As clarify by Gilles and Kevin we absolutely can  get GraphQL with the
control plan API and the workers api.

Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed by the
official GraphQL website. I don’t even know if there is another library
available indeed.

Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil  a écrit :

> Actually Mutations fields are only data to be displayed, if needed, by
> the response.
> The data changes comes with the parameters.
> So the correct mutation syntax is:
>
> mutation rebootServer {
>updateServer(id: ) {
>  reboot(type: "HARD")
>}
> }
>
> Also the latter example would be a "data API" equivalent using CRUD
> function like "updateServer"
>
> And the following example would be a "plane API" equivalent approach
> with an action function:
>
> mutation hardReboot {
>rebootServer(id: , type: "HARD")
> }
>
> Sorry for the initial confusion but I think this is important because
> GraphQL schema helps clarify data and the operations.
>
>
> On 04/05/18 13:20, Gilles Dubreuil wrote:
> >
> > On 04/05/18 05:34, Fox, Kevin M wrote:
> >> k8s does that I think by separating desired state from actual state
> >> and working to bring the two inline. the same could (maybe even
> >> should) be done to openstack. But your right, that is not a small
> >> amount of work.
> >
> > K8s makes perfect sense to follow declarative approach.
> >
> > That said a mutation following control plane API action semantic could
> > be very similar:
> >
> > mutation rebootServer {
> >   Server(id: ) {
> > reboot: {
> >   type: "HARD"
> > }
> >   }
> > }
> >
> >
> > "rebootServer" being an alias to name the request.
> >
> >
> >> Even without using GraphQL, Making the api more declarative anyway,
> >> has advantages.
> >
> > +1
> >
> >> Thanks,
> >> Kevin
> >> 
> >> From: Jay Pipes [jaypi...@gmail.com]
> >> Sent: Thursday, May 03, 2018 10:50 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
> >> inception?
> >>
> >> On 05/03/2018 12:57 PM, Ed Leafe wrote:
> >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil 
> >>> wrote:
> > • We should get a common consensus before all projects start to
> > implement it.
>  This is going to be raised during the API SIG weekly meeting later
>  this week.
>  API developers (at least one) from every project are strongly
>  welcomed to participate.
>  I suppose it makes sense for the API SIG to be the place to discuss
>  it, at least initially.
> >>> It was indeed discussed, and we think that it would be a worthwhile
> >>> experiment. But it would be a difficult, if not impossible, proposal
> >>> to have adopted OpenStack-wide without some data to back it up. So
> >>> what we thought would be a good starting point would be to have a
> >>> group of individuals interested in GraphQL form an informal team and
> >>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
> >>> Taylor suggested Neutron as an excellent candidate, as its API
> >>> exposes things at an individual table level, requiring the client to
> >>> join that information to get the answers they need.
> >>>
> >>> Once that is done, we could examine the results, and use them as the
> >>> basis for proceeding with something more comprehensive. Does that
> >>> sound like a good approach to (all of) you?
> >> Did anyone bring up the differences between control plane APIs and data
> >> APIs and the applicability of GraphQL to the latter and not the former?
> >>
> >> For example, a control plane API to reboot a server instance looks like
> >> this:
> >>
> >> POST /servers/{uuid}/action
> >> {
> >>   "reboot" : {
> >>   "type" : "HARD"
> >>   }
> >> }
> >>
> >> how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
> >> doesn't really work since the server object isn't being mutated. I mean,
> >> the state of the server will *eventually* be mutated when the reboot
> >> action starts kicking in (the above is an async operation returning a
> >> 202 Accepted). But the act of hitting POST /servers/{uuid}/action
> >> doesn't actually mutate the server's state.
> >>
> >> This is just one example of where GraphQL doesn't necessarily map well
> >> to control plane APIs that happen to be built on top of REST/HTTP [1]
> >>
> >> Bottom line for me would be what is the perceivable benefit that all of
> >> our users would receive given the (very costly) overhaul of our APIs
> >> that would likely be required.
> >>
> >> Best,
> >> -jay
> >>
> >> [0] http://graphql.org/learn/queries/#mutations
> >> [1] One could argue (and I have in the past) that POST
> >> /servers/{uuid}/action isn't a RESTful interface at all...
> >>
> >>
> 

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

It seems to be a fair way to do it. I do second the Neutron API as a good
candidate.

I’ll be happy to give a hand.

@jay I’ve already sum my points upper, but I could definitely have better
exemples if needed.

I’m operating and dealing with a large (really) Openstack platform and
GraphQL would have tremendous performances impacts for sure. But you’re
right proof have to be made.
Le jeu. 3 mai 2018 à 18:57, Ed Leafe  a écrit :

> On May 2, 2018, at 2:40 AM, Gilles Dubreuil  wrote:
> >
> >> • We should get a common consensus before all projects start to
> implement it.
> >
> > This is going to be raised during the API SIG weekly meeting later this
> week.
> > API developers (at least one) from every project are strongly welcomed
> to participate.
> > I suppose it makes sense for the API SIG to be the place to discuss it,
> at least initially.
>
> It was indeed discussed, and we think that it would be a worthwhile
> experiment. But it would be a difficult, if not impossible, proposal to
> have adopted OpenStack-wide without some data to back it up. So what we
> thought would be a good starting point would be to have a group of
> individuals interested in GraphQL form an informal team and proceed to wrap
> one OpenStack API as a proof-of-concept. Monty Taylor suggested Neutron as
> an excellent candidate, as its API exposes things at an individual table
> level, requiring the client to join that information to get the answers
> they need.
>
> Once that is done, we could examine the results, and use them as the basis
> for proceeding with something more comprehensive. Does that sound like a
> good approach to (all of) you?
>
> -- 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
>
__
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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Exactly !
Le jeu. 3 mai 2018 à 19:55, Flint WALRUS <gael.ther...@gmail.com> a écrit :

> It seems to be a fair way to do it. I do second the Neutron API as a good
> candidate.
>
> I’ll be happy to give a hand.
>
> @jay I’ve already sum my points upper, but I could definitely have better
> exemples if needed.
>
> I’m operating and dealing with a large (really) Openstack platform and
> GraphQL would have tremendous performances impacts for sure. But you’re
> right proof have to be made.
> Le jeu. 3 mai 2018 à 18:57, Ed Leafe <e...@leafe.com> a écrit :
>
>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> wrote:
>> >
>> >> • We should get a common consensus before all projects start to
>> implement it.
>> >
>> > This is going to be raised during the API SIG weekly meeting later this
>> week.
>> > API developers (at least one) from every project are strongly welcomed
>> to participate.
>> > I suppose it makes sense for the API SIG to be the place to discuss it,
>> at least initially.
>>
>> It was indeed discussed, and we think that it would be a worthwhile
>> experiment. But it would be a difficult, if not impossible, proposal to
>> have adopted OpenStack-wide without some data to back it up. So what we
>> thought would be a good starting point would be to have a group of
>> individuals interested in GraphQL form an informal team and proceed to wrap
>> one OpenStack API as a proof-of-concept. Monty Taylor suggested Neutron as
>> an excellent candidate, as its API exposes things at an individual table
>> level, requiring the client to join that information to get the answers
>> they need.
>>
>> Once that is done, we could examine the results, and use them as the
>> basis for proceeding with something more comprehensive. Does that sound
>> like a good approach to (all of) you?
>>
>> -- 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
>>
>
__
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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Hi Gilles, folks,

Nice to read such answers, I’m really thrilled by what could goes out from
this discussion.

One last thing regarding the SDK and Broker part of the discussion.

GraphQL and SDK:

Obviously as you noticed it, I was focused on the python-openstacksdk part
of things even if it apply to the autonomous Openstack4j JAVA SDK or any
other SDK for your favorite language.

I do agree with you, GraphQL being a DSL it should in a long (or maybe not
so long depending the adoption rate ;-) ) run replace the REST part of the
SDK, however, I think the client libraries (at least for the python side of
think) should be enforced by the Openstack foundation/devs as it would
avoid having devs from one project/tool that will join the big tent to use
a different library of its own and so create fragmentation and pitfalls
already mentioned upper on my previous message.

For example, if I let our devs use their own client library for both
GraphQL and workers logic I will end up with at least a dozen of different
libraries per teams and it will be a nightmare to debug, investigate,
maintain etc.

For sure as this is a personal example some could argue that we should
enforce this choice at the company level and not at the solution level, but
if everyone talk the same language its easier to share information, make
consensus around a project, ease the development process by having a clear
and consistent path (Providing a common cookiecutter for all new projects)
and would give us the ability to manage a complete project with the
Openstack client tool such as:

```openstack brick init ```

Here I choose the “brick” term as a keyword in order to avoid namespace
collisions as projects and services are already used for ops side of things.

GraphQL broker:

Ok I see what you means and I honestly love the idea as it’s an elegant way
to split responsibility while being able to scale and efficiently
distribute requests.

I think that’s the implicit idea behind swift-proxy and how (most of)
companies achieve the horizontal scaling with HAProxy as a loadbalancer in
front of classic Openstack WSGI endpoints.

As this is a builtin feature of GraphQL that would allows a way better
service discovery and routing architecture.

Kind regards,
G.

Le mer. 2 mai 2018 à 09:41, Gilles Dubreuil <gdubr...@redhat.com> a écrit :

> I fixed the GraphQL typo (my mistake) in $subject to help with future ML
> searches.
>
> Please see inline too.
>
> On 02/05/18 07:37, Flint WALRUS wrote:
>
> Ok, here are my two cents regarding GraphQL integration within Openstack
> and some thoughts around this topic.
>
> 1°/- Openstack SDK should still exist and should be in my humble opinion a
> critical focus as it allow following benefits for large and medium
> companies :
>
> • It provide a common and clean structure for Openstack developments and
> should be used either by projects or tools willing to integrate Openstack
> as it will then create some sort of standard.
>
> For instance, here in my job we have A LOT (More than 10 000 peoples
> working within around 130 teams) of teams developing over Openstack using
> the SDK as a common shared base layout.
> That allow for teams to easily share and co-develop on projects. Those
> teams are spread around the world and so need to have clean guidelines as
> it avoid them reinventing the wheel, they’re not stuck with someone else
> obscure code created by another persons on the other side of the world or
> within a different timezone.
> Additionally it streamline our support and debug processes.
>
>
> I'm assuming you're talking about the Python SDK (Shade) which would make
> sense because it's the "lingua franca" of all projects.
>
> Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely to
> replace its REST SDK on the long run. GraphQL is a DSL bypassing a SDK need
> which get replaced with GraphQL client library. Basically the change, not a
> rewrite, is inevitable. But I insist on "the long run" part, initially both
> in parallel one wrapping the other, then progressively the REST content
> moving across to GraphQL.
>
>
> • We should get a common consensus before all projects start to implement
> it.
>
>
>
> This is going to be raised during the API SIG weekly meeting later this
> week.
> API developers (at least one) from every project are strongly welcomed to
> participate.
> I suppose it makes sense for the API SIG to be the place to discuss it, at
> least initially.
>
>
>
> This point is for me the most important one as it will fix flaws we get
> currently with the rest APIs development within Openstack.
>
> First it will avoid a fresh developer to be confused by too many options.
> Honestly, I know we are open etc, but this point really need to be
> addressed as it is 

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Ok, here are my two cents regarding GraphQL integration within Openstack
and some thoughts around this topic.

1°/- Openstack SDK should still exist and should be in my humble opinion a
critical focus as it allow following benefits for large and medium
companies :

• It provide a common and clean structure for Openstack developments and
should be used either by projects or tools willing to integrate Openstack
as it will then create some sort of standard.

For instance, here in my job we have A LOT (More than 10 000 peoples
working within around 130 teams) of teams developing over Openstack using
the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those
teams are spread around the world and so need to have clean guidelines as
it avoid them reinventing the wheel, they’re not stuck with someone else
obscure code created by another persons on the other side of the world or
within a different timezone.
Additionally it streamline our support and debug processes.

• We should get a common consensus before all projects start to implement
it.

This point is for me the most important one as it will fix flaws we get
currently with the rest APIs development within Openstack.

First it will avoid a fresh developer to be confused by too many options.
Honestly, I know we are open etc, but this point really need to be
addressed as it is the main issue that I face with Openstack advocacy since
many years now.

Having too many options even if explained within the documentation daunt a
lot of people to quickly give a hand with projects.

For instance I have a workmate that is currently working on an internal
tool which ask me how should he implement its project REST interfaces.

I told him TO NOT use WSME and to stick with what have been done by a major
project. Unfortunately he choose to copy what have been done by Octavia
which is actually using... WSME...

GraphQL gives us the opportunity and ability to fix Openstack development
inconsistencies by providing and enforcing a clean guideline regarding
which library should be used and in which way.

That would also have the side effect to easy the entry level for a new
Openstack developer.

• New architecture opportunities.

For sure that will bring new architecture opportunities, but the broker
thing is not a good idea as each project should be able to be autonomous.

I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use a
RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much
debugging/investigation hell that we now plan to have a serious benchmark
and test of ZMQ.

One thing that I would love to see with GraphQL is a better distributed and
traceable model.

Anyway, I’m glad someone started this discussion as I feel it is a really
important topic that would highly help Openstack on more than just
interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil <gdubr...@redhat.com> a écrit :

>
>
> On 01/05/18 11:31, Flint WALRUS wrote:
>
> Yes, that’s was indeed the sens of my point.
>
>
> I was just enforcing it, no worries! ;)
>
>
>
> Openstack have to provide both endpoints type for a while for backward
> compatibility in order to smooth the transition.
>
> For instance, that would be a good idea to contact postman devteam once
> GraphQL will start to be integrated as it will allow a lot of ops to keep
> their day to day tools by just having to convert their existing collections
> of handful requests.
>
>
> Shouldn't we have a common consensus before any project start pushing its
> own GraphQL wheel?
>
> Also I wonder how GraphQL could open new architecture avenues for
> OpenStack.
> For example, would that make sense to also have a GraphQL broker linking
> OpenStack services?
>
>
>
>
> Or alternatively to provide a tool with similar features at least.
> Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <gdubr...@redhat.com> a
> écrit :
>
>>
>>
>> On 30/04/18 20:16, Flint WALRUS wrote:
>>
>> I would very much second that question! Indeed it have been one of my own
>> wondering since many times.
>>
>> Of course GraphQL is not intended to replace REST as is and have to live
>> in parallel
>>
>>
>> Effectively a standard initial architecture is to have GraphQL sitting
>> aside (in parallel) and wrapping REST and along the way develop GrapgQL
>> Schema.
>>
>> It's seems too early to tell but GraphQL being the next step in API
>> evolution it might ultimately replace REST.
>>
>>
>> but it would likely and highly accelerate all requests within heavily
>> loaded environments
>>
>&g

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Yes, that’s was indeed the sens of my point.

Openstack have to provide both endpoints type for a while for backward
compatibility in order to smooth the transition.

For instance, that would be a good idea to contact postman devteam once
GraphQL will start to be integrated as it will allow a lot of ops to keep
their day to day tools by just having to convert their existing collections
of handful requests.

Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <gdubr...@redhat.com> a écrit :

>
>
> On 30/04/18 20:16, Flint WALRUS wrote:
>
> I would very much second that question! Indeed it have been one of my own
> wondering since many times.
>
> Of course GraphQL is not intended to replace REST as is and have to live
> in parallel
>
>
> Effectively a standard initial architecture is to have GraphQL sitting
> aside (in parallel) and wrapping REST and along the way develop GrapgQL
> Schema.
>
> It's seems too early to tell but GraphQL being the next step in API
> evolution it might ultimately replace REST.
>
>
> but it would likely and highly accelerate all requests within heavily
> loaded environments
>
>
> +1
>
>
> .
>
> So +1 for this question.
> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil <gdubr...@redhat.com> a
> écrit :
>
>> Hi,
>>
>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>> addresses REST limitations.
>> I wonder if any project has been thinking about using GraphQL. I haven't
>> find any mention or pointers about it.
>>
>> GraphQL takes a complete different approach compared to REST. So we can
>> finally forget about REST API Description languages
>> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
>> approach which doesn't describe how to use it).
>>
>> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
>> and no-SQL DBMS and therefore have different applications, there are no
>> doubt the complexity of most OpenStack projects are good candidates for
>> GraphQL.
>>
>> Besides topics such as efficiency, decoupling, no version management
>> need there many other powerful features such as API Schema out of the
>> box and better automation down that track.
>>
>> It looks like the dream of a conduit between API services and consumers
>> might have finally come true so we could move-on an worry about other
>> things.
>>
>> So has anyone already starting looking into it?
>>
>> [1]
>>
>> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
>> [2] http://graphql.org
>>
>>
>>
>> __
>> 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

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

I would very much second that question! Indeed it have been one of my own
wondering since many times.

Of course GraphQL is not intended to replace REST as is and have to live in
parallel but it would likely and highly accelerate all requests within
heavily loaded environments.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
écrit :

> Hi,
>
> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
> addresses REST limitations.
> I wonder if any project has been thinking about using GraphQL. I haven't
> find any mention or pointers about it.
>
> GraphQL takes a complete different approach compared to REST. So we can
> finally forget about REST API Description languages
> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
> approach which doesn't describe how to use it).
>
> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
> and no-SQL DBMS and therefore have different applications, there are no
> doubt the complexity of most OpenStack projects are good candidates for
> GraphQL.
>
> Besides topics such as efficiency, decoupling, no version management
> need there many other powerful features such as API Schema out of the
> box and better automation down that track.
>
> It looks like the dream of a conduit between API services and consumers
> might have finally come true so we could move-on an worry about other
> things.
>
> So has anyone already starting looking into it?
>
> [1]
>
> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
> [2] http://graphql.org
>
>
>
> __
> 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] [kolla][vote] core nomination for caoyuan

[Flint WALRUS]

+1
Le lun. 12 mars 2018 à 10:09, Marcin Juszkiewicz <
marcin.juszkiew...@linaro.org> a écrit :

> W dniu 12.03.2018 o 03:06, Jeffrey Zhang pisze:
> > It is my pleasure to nominate caoyuan for kolla core team.
>
> +1
>
> __
> 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] Pros and Cons of face-to-face meetings

[Flint WALRUS]

To simply answer the question:

Yes I have experience about this specific matter of things as I’m now
working with the exact setup for more than 5 years. I’m even exclusively
working remotely with some studios of my employer.

It’s not that expensive as long as you get correct rules, hardware and the
stream owner physically on the room to act as a conductor.

Remember that the 4th mantra of the Openstack project HAVE to be respected
if we really want to get people to join us and share. They need to feel at
home in order to contribute as they have to feel useful to really be
interested to participate. Additionally, Openstack being way more vast than
let say Kubernetes it NEED such extra care in order to keep its community
strong and passionate at a point where they will naturally advocate and
work on it.

That’s indeed my first year of participating into the Openstack community
even if I’m working on Openstack since the Essex version because I didn’t
felt skilled and included enough until now.

Why did I change my mind? Because of the sidney summit and presentation of
these Open rules plus my communication with you people over irc/emails etc.
Le jeu. 8 mars 2018 à 21:06, Anita Kuno  a écrit :

> On 2018-03-08 02:18 PM, Tim Bell wrote:
> > Fully agree with Doug. At CERN, we use video conferencing for 100s,
> sometimes >1000 participants for the LHC experiments, the trick we've found
> is to fully embrace the chat channels (so remote non-native English
> speakers can provide input) and chairs/vectors who can summarise the remote
> questions constructively, with appropriate priority.
> >
> > This is actually very close to the etherpad approach, we benefit from
> the local bandwidth if available but do not exclude those who do not have
> it (or the language skills to do it in real time).
>
> Just expanding on the phrase 'the etherpad approach' one instance on the
> Friday saw some infra team members discussing the gerrit upgrade in
> person and one infra team member (snowed in at the same hotel as Doug)
> following along on the etherpad as it was updated and weighing in on the
> updates (either via the etherpad or irc, I'm not sure, my laptop was not
> open).
>
> So again echoing the chorus, there are possibilities, but those
> possibilities require effort and usually prior knowledge of participants
> and their habits.
>
> Thank you,
> Anita
>
> >
> > Tim
> >
> > -Original Message-
> > From: Doug Hellmann 
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> > Date: Thursday, 8 March 2018 at 20:00
> > To: openstack-dev 
> > Subject: Re: [openstack-dev] Pros and Cons of face-to-face meetings
> >
> >  Excerpts from Jeremy Stanley's message of 2018-03-08 18:34:51 +:
> >  > On 2018-03-08 12:16:18 -0600 (-0600), Jay S Bryant wrote:
> >  > [...]
> >  > > Cinder has been doing this for many years and it has worked
> >  > > relatively well. It requires a good remote speaker and it also
> >  > > requires the people in the room to be sensitive to the needs of
> >  > > those who are remote. I.E. planning topics at a time appropriate
> >  > > for the remote attendees, ensuring everyone speaks up, etc. If
> >  > > everyone, however, works to be inclusive with remote
> participants
> >  > > it works well.
> >  > >
> >  > > We have even managed to make this work between separate
> mid-cycles
> >  > > (Cinder and Nova) in the past before we did PTGs.
> >  > [...]
> >  >
> >  > I've seen it work okay when the number of remote participants is
> >  > small and all are relatively known to the in-person participants.
> >  > Even so, bridging Doug into the TC discussion at the PTG was
> >  > challenging for all participants.
> >
> >  I agree, and I'll point out I was just across town (snowed in at a
> >  different hotel).
> >
> >  The conversation the previous day with just the 5-6 people on the
> >  release team worked a little bit better, but was still challenging
> >  at times because of audio quality issues.
> >
> >  So, yes, this can be made to work. It's not trivial, though, and
> >  the degree to which it works depends a lot on the participants on
> >  both sides of the connection. I would not expect us to be very
> >  productive with a large number of people trying to be active in the
> >  conversation remotely.
> >
> >  Doug
> >
> >
> __
> >  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 

Re: [openstack-dev] Pros and Cons of face-to-face meetings

[Flint WALRUS]

Pretty easy, put the PTG online with a livestream on
YouTube/Hangout/whatever platform that will then be saved and could even be
watched later on!

It’s just a matter of some hardware and a decent internet bandwidth that’s
already available to almost every places where a PTG took place.

Problem solved.

PS: Even if I second your thoughts about the fact that some can make it to
a physical meeting for some reason (And I’m one of them), your email sounds
a little bit aggressive. Miss some smiley ? ;-)
Le jeu. 8 mars 2018 à 15:04, Jens Harbott  a écrit :

> With the current PTG just finished and seeing discussions happen about
> the format of the next[0], it seems that the advantages of these seem
> to be pretty clear to most, so let me use the occasion to remind
> everyone of the disadvantages.
>
> Every meeting that is happening is excluding those contributors that
> can not attend it. And with that it is violating the fourth Open
> principle[1], having a community that is open to everyone. If you are
> wondering whom this would affect, here's a non-exclusive (sic) list of
> valid reasons not to attend physical meetings:
>
> - Health issues
> - Privilege issues (like not getting visa or travel permits)
> - Caretaking responsibilities (children, other family, animals, plants)
> - Environmental concerns
>
> So when you are considering whether it is worth the money and effort
> to organise PTGs or similar events, I'd like you also to consider
> those being excluded by such activities. It is not without a reason
> that IRC and emails have been settled upon as preferred means of
> communication. I'm not saying that physical meetings should be dropped
> altogether, but maybe more effort can be placed into providing means
> of remote participation, which might at least reduce some effects.
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html
> [1] https://governance.openstack.org/tc/reference/opens.html
>
> __
> 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