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

2018-05-05 Thread 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  a écrit :

> On 2018-05-04 23:42:59 + (+), 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?

2018-05-05 Thread Jeremy Stanley
On 2018-05-04 23:42:59 + (+), 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


signature.asc
Description: PGP signature
__
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?

2018-05-05 Thread Gilles Dubreuil



On 05/05/18 09:42, Flint WALRUS wrote:
I will not attend the vancouver summit but I’ll try to attend the 
berlin one as it’s closer to me.


No worries, I hope "networking" at Vancouver will allow to grab good 
support and rocket the momentum :).
Unfortunately I'm not sure to make it to Berlin time wise and distance 
wise too.




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.


Flint, I think that's an invaluable experience. Thank you for bringing 
in and also what you've expressed is very important too. I believe there 
are needs to be addressed.
The viewpoint of consumers has been lacking. And the API SIG exists to 
take it in consideration but we need more people involved.
It seems the ransom of the success hitting as now a critical mass of 
supporters is needed to be able to get any requirement accepted.
Especially such requirements touch project wide components (API) living 
inside the entropy of the cloud structural complexity.
This is why there is no doubt GraphQL data model simplification can 
bring only good.


From my side, I'm not core, just been consuming OpenStack APIs for SDKs 
for the last 2 years and I feel we're stalling.


So I'm more than happy to help and get more involved but we're going to 
need neutron core and other APIs core members believers.


Thanks,
Gilles


Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil > 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 > 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
>> 
>> 

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

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


Re: [openstack-dev] [kolla-ansible] Configure OpenStack services to use Rabbit HA queues

2018-05-05 Thread vladislav . belogrudov

thanks Jeffrey


On 05/05/2018 03:03 AM, Jeffrey Zhang wrote:

Hi vladispay,

I guess you are talking rabbit_ha_queues options. It is already marked 
as deprecated[0].


    cfg.BoolOpt('rabbit_ha_queues',
                default=False,
deprecated_group='DEFAULT',
                help='Try to use HA queues in RabbitMQ (x-ha-policy: 
all). '

                'If you change this option, you must wipe the RabbitMQ '
                'database. In RabbitMQ 3.0, queue mirroring is no longer '
                'controlled by the x-ha-policy argument when declaring a '
                'queue. If you just want to make sure that all queues 
(except '
                'those with auto-generated names) are mirrored across 
all '

                'nodes, run: '
                """\"rabbitmqctl set_policy HA '^(?!amq\.).*' """
                """'{"ha-mode": "all"}' \),

In kolla, we configure a global ha-mode policy through its 
definition.json file in rabbitmq, please check[1]


[0] 
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L165-L176 

[1] 
https://github.com/openstack/kolla-ansible/blob/d2d9c6622888416ad2e748706fd237f8588e993a/ansible/roles/rabbitmq/templates/definitions.json.j2#L20 



On Sat, May 5, 2018 at 12:58 AM, > wrote:


Hi,

is there a reason we don't configure services for rabbitmq ha
queues like it is suggested in [0] ?
Rabbitmq itself has ha policy 'on' via one of its templates.

Thanks,
Vladislav Belogrudov

[0]
https://docs.openstack.org/ha-guide/shared-messaging.html#rabbitmq-services



__
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





--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 


__
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