Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

[Boden Russell]

On 4/21/16 1:38 PM, Joshua Harlow wrote:
> This might be harder in retrying, but I think I can help u make
> something that will work, since retrying has a way to provide a custom
> delay function.

Thanks for that. My question was if this might be useful as a new
backoff in retrying (vs a custom delay function in oslo or something).


> https://github.com/rholder/retrying/blob/master/retrying.py#L65
> 
> 'wait_exponential_max'?

When expressed in milliseconds; bingo!
Thanks for doing some of my work :)

__
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][nova][oslo] Common backoff & timeout utils

[Joshua Harlow]

Boden Russell wrote:

I haven't spent much time on this, so the answers below are a first
approximation based on a quick visual inspection (e.g. subject to change
when I get a chance to hack on some code).

On 4/21/16 12:10 PM, Salvatore Orlando wrote:

Can you share more details on the "few things we need" that
retrying is lacking?


(a) Some of our existing code uses a 'stepping' scheme (fist N attempts
with timeout T, next M attempts with timeout U, etc.). For example [1].
This could also be tackled using chaining.


This might be harder in retrying, but I think I can help u make 
something that will work, since retrying has a way to provide a custom 
delay function.



(b) It doesn't appear retrying supports capping (ceiling) exponential
sleep times as we do in [2].


https://github.com/rholder/retrying/blob/master/retrying.py#L65

'wait_exponential_max'?




Do you think oslo_messaging would be a good target? Or do you think it
should go somewhere else?


My initial thought was to implement it as a subclass of oslo_messaging's
RPCClient [3] with a nice way for consumers to configure the
backoff/retry magic. If consumers want a backing off client, then they
use the new subclass.


[1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L147
[2] https://review.openstack.org/#/c/280595/
[3]
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/client.py#L208

__
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][nova][oslo] Common backoff & timeout utils

[Boden Russell]

I haven't spent much time on this, so the answers below are a first
approximation based on a quick visual inspection (e.g. subject to change
when I get a chance to hack on some code).

On 4/21/16 12:10 PM, Salvatore Orlando wrote:
> Can you share more details on the "few things we need" that
> retrying is lacking?

(a) Some of our existing code uses a 'stepping' scheme (fist N attempts
with timeout T, next M attempts with timeout U, etc.). For example [1].
This could also be tackled using chaining.
(b) It doesn't appear retrying supports capping (ceiling) exponential
sleep times as we do in [2].

> Do you think oslo_messaging would be a good target? Or do you think it
> should go somewhere else?

My initial thought was to implement it as a subclass of oslo_messaging's
RPCClient [3] with a nice way for consumers to configure the
backoff/retry magic. If consumers want a backing off client, then they
use the new subclass.


[1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L147
[2] https://review.openstack.org/#/c/280595/
[3]
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/client.py#L208

__
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][nova][oslo] Common backoff & timeout utils

[Joshua Harlow]

Boden Russell wrote:

On 4/20/16 3:29 PM, Doug Hellmann wrote:

Yes, please, let's try to make that work and contribute upstream if we
need minor modifications, before we create something new.


We can leverage the 'retrying' module (already in global requirements).
It lacks a few things we need, but those can be implemented using its
existing "hooks" today, or, working with the module owner(s) to push a
few changes that we need (the later probably provides the "greatest good").

Assuming we'll leverage 'retrying', I was thinking the initial goals
here are:
(a) Ensure 'retrying' supports the behaviors we need for our usages in
neutron + nova (see [1] - [5] on my initial note) today. Implementation
details TBD.
(b) Implement a "Backing off RPC client" in oslo, inspired by [1].
(c) Update nova + neutron to use the "common implementation(s)" rather
than 1-offs.

This sounds fun and I'm happy to take it on. However, I probably won't
make much progress until after the summit for obvious reasons. I'll plan
to lead with code, if a RFE/spec/other is needed please let me know.



I'm fine with either RFE/spec/code, whatever makes u happy. I'd rather 
have a contributor work in a way that makes them feel happy, then force 
a process that makes them feel unhappy, especially IMHO for something 
like this.



Additional comments welcomed.


Thanks

[1] https://review.openstack.org/#/c/280595

__
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][nova][oslo] Common backoff & timeout utils

[Joshua Harlow]

Salvatore Orlando wrote:


On 21 April 2016 at 16:54, Boden Russell > wrote:

On 4/20/16 3:29 PM, Doug Hellmann wrote:
>  Yes, please, let's try to make that work and contribute upstream if we
>  need minor modifications, before we create something new.

We can leverage the 'retrying' module (already in global requirements).
It lacks a few things we need, but those can be implemented using its
existing "hooks" today, or, working with the module owner(s) to push a
few changes that we need (the later probably provides the "greatest
good").


Retrying (even if mostly a 1-man effort) already has a history of
contribution from different sources, including a few OpenStack
contributors as well.
It hasn't had many commits in the past 12 months, but this does not mean
new PRs won't be accepted.
Starting a new library for something like this really feels like NIH.



Yes please (as a person that has contributed to that library); I know 
the retrying library isn't perfect, but let's IMHO do our due diligence 
there before we go off and make something else. I know that's not always 
an easy proposition (or sometimes even the shortest path) but  think it 
is our responsibility to at least try (the library isn't that huge, and 
it is pretty targeted at doing a small thing, so its not like there is a 
massive amount of code or a massive amount of history...)



As for hooks vs contributions this really depends on what you need to
add. Can you share more details on the "few things we need" that
retrying is lacking?
(and I apologise if you shared them earlier in this thread - I did not
read all of it)


Assuming we'll leverage 'retrying', I was thinking the initial goals
here are:
(a) Ensure 'retrying' supports the behaviors we need for our usages in
neutron + nova (see [1] - [5] on my initial note) today. Implementation
details TBD.
(b) Implement a "Backing off RPC client" in oslo, inspired by [1].


Do you think oslo_messaging would be a good target? Or do you think it
should go somewhere else?

(c) Update nova + neutron to use the "common implementation(s)" rather
than 1-offs.

This sounds fun and I'm happy to take it on. However, I probably won't

make much progress until after the summit for obvious reasons. I'll plan
to lead with code, if a RFE/spec/other is needed please let me know.


Additional comments welcomed.


Thanks

[1] https://review.openstack.org/#/c/280595

__
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][nova][oslo] Common backoff & timeout utils

[Salvatore Orlando]

On 21 April 2016 at 16:54, Boden Russell  wrote:

> On 4/20/16 3:29 PM, Doug Hellmann wrote:
> > Yes, please, let's try to make that work and contribute upstream if we
> > need minor modifications, before we create something new.
>
> We can leverage the 'retrying' module (already in global requirements).
> It lacks a few things we need, but those can be implemented using its
> existing "hooks" today, or, working with the module owner(s) to push a
> few changes that we need (the later probably provides the "greatest good").
>

Retrying (even if mostly a 1-man effort) already has a history of
contribution from different sources, including a few OpenStack contributors
as well.
It hasn't had many commits in the past 12 months, but this does not mean
new PRs won't be accepted.
Starting a new library for something like this really feels like NIH.

As for hooks vs contributions this really depends on what you need to add.
Can you share more details on the "few things we need" that retrying is
lacking?
(and I apologise if you shared them earlier in this thread - I did not read
all of it)


>
> Assuming we'll leverage 'retrying', I was thinking the initial goals
> here are:
> (a) Ensure 'retrying' supports the behaviors we need for our usages in
> neutron + nova (see [1] - [5] on my initial note) today. Implementation
> details TBD.
> (b) Implement a "Backing off RPC client" in oslo, inspired by [1].
>

Do you think oslo_messaging would be a good target? Or do you think it
should go somewhere else?


> (c) Update nova + neutron to use the "common implementation(s)" rather
> than 1-offs.
>
> This sounds fun and I'm happy to take it on. However, I probably won't

make much progress until after the summit for obvious reasons. I'll plan
> to lead with code, if a RFE/spec/other is needed please let me know.


> Additional comments welcomed.
>
>
> Thanks
>
> [1] https://review.openstack.org/#/c/280595
>
> __
> 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][nova][oslo] Common backoff & timeout utils

[Boden Russell]

On 4/20/16 3:29 PM, Doug Hellmann wrote:
> Yes, please, let's try to make that work and contribute upstream if we
> need minor modifications, before we create something new.

We can leverage the 'retrying' module (already in global requirements).
It lacks a few things we need, but those can be implemented using its
existing "hooks" today, or, working with the module owner(s) to push a
few changes that we need (the later probably provides the "greatest good").

Assuming we'll leverage 'retrying', I was thinking the initial goals
here are:
(a) Ensure 'retrying' supports the behaviors we need for our usages in
neutron + nova (see [1] - [5] on my initial note) today. Implementation
details TBD.
(b) Implement a "Backing off RPC client" in oslo, inspired by [1].
(c) Update nova + neutron to use the "common implementation(s)" rather
than 1-offs.

This sounds fun and I'm happy to take it on. However, I probably won't
make much progress until after the summit for obvious reasons. I'll plan
to lead with code, if a RFE/spec/other is needed please let me know.

Additional comments welcomed.


Thanks

[1] https://review.openstack.org/#/c/280595

__
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][nova][oslo] Common backoff & timeout utils

[Ben Nemec]

FWIW, we were using retrying in oslo.concurrency at one point:
https://review.openstack.org/#/c/130872

It looks like that got removed somewhere in the move to fasteners though.

On 04/20/2016 04:29 PM, Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2016-04-20 22:16:10 +0100:
>>
>> Will the already existing retrying[1] do the job or is it missing
>> features (the namespacing thing seems like it could be an issue)
>> or perhaps too generic?
>>
>> [1] https://pypi.python.org/pypi/retrying
>>
> 
> Yes, please, let's try to make that work and contribute upstream if we
> need minor modifications, before we create something new.
> 
> 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 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][nova][oslo] Common backoff & timeout utils

[Brant Knudson]

On Wed, Apr 20, 2016 at 3:10 PM, Boden Russell  wrote:

> Today there are a number of places in nova, neutron and perhaps
> elsewhere that employ backoff + timeout strategies (see [1] - [4]).
> While we are working towards a unified approach in neutron for RPC [5],
> it appears such logic could benefit the greater community as a reusable
> oslo implementation.
>
> IMHO such an oslo implementation could:
> - Enable backoff/timeout irrespective of client/transport. This would
> allow the utils to be used with various clients (HTTP, AMQP RPC, etc.).
> - Support namespacing as inspired by the existing neutron patch [5].
> - In the future, perhaps, allow multiple (pluggable) backoff strategies
> to be used (e.g. configurable backoff).
>
> Anyone adverse to me crafting an initial oslo patch to kick-off the
> details on this one?
>
>
> Thanks
>
>
> [1]
> https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L162
> [2]
>
> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/scheduler/utils.py#L356
> [3]
>
> https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb31317ba469a58/neutron/agent/l3/agent.py#L224
> [4]
>
> https://github.com/openstack/neutron/blob/42c6f05f2904cd4c01bcd3f79b1966489f5ad3c1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L189
> [5] https://review.openstack.org/#/c/280595/
>
>
oslo.utils has a decorator that will retry after a delay -
http://docs.openstack.org/developer/oslo.utils/api/excutils.html#oslo_utils.excutils.forever_retry_uncaught_exceptions
, which doesn't do backoff would be easy enough to add. Alternatively, if
an existing library works better, maybe the oslo utility should be
deprecated.

- Brant
__
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][nova][oslo] Common backoff & timeout utils

[Joshua Harlow]

Feel free to take the following (if its similar to what u are thinking)

https://github.com/openstack/anvil/blob/master/anvil/utils.py#L90

IMHO though if its a decorator, the retrying library can already perform 
this:


https://pypi.python.org/pypi/retrying

And a couple of the oslo-cores (jd, me) have contributed to that library 
and can explain how to use it...


Overall though, let's see an initial patch and I guess we can see where 
this goes and how much something like it may already exist elsewhere...


-Josh

Amrith Kumar wrote:

Boden,

Are you thinking of implementing something which would perform exponentially 
backed off calls to some arbitrary function till that method returns with 
something other than a timeout?

I think that would be very versatile, and useful in a wide variety of places.

Thanks,

-amrith


-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: Wednesday, April 20, 2016 4:45 PM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][nova][oslo] Common backoff&
timeout utils

Sounds good to me Boden.

-- Dims

On Wed, Apr 20, 2016 at 4:10 PM, Boden Russell<boden...@gmail.com>  wrote:

Today there are a number of places in nova, neutron and perhaps
elsewhere that employ backoff + timeout strategies (see [1] - [4]).
While we are working towards a unified approach in neutron for RPC
[5], it appears such logic could benefit the greater community as a
reusable oslo implementation.

IMHO such an oslo implementation could:
- Enable backoff/timeout irrespective of client/transport. This would
allow the utils to be used with various clients (HTTP, AMQP RPC, etc.).
- Support namespacing as inspired by the existing neutron patch [5].
- In the future, perhaps, allow multiple (pluggable) backoff
strategies to be used (e.g. configurable backoff).

Anyone adverse to me crafting an initial oslo patch to kick-off the
details on this one?


Thanks


[1]
https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L1
62
[2]
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c9
7dc1d065b/nova/scheduler/utils.py#L356
[3]
https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb3
1317ba469a58/neutron/agent/l3/agent.py#L224
[4]
https://github.com/openstack/neutron/blob/42c6f05f2904cd4c01bcd3f79b19
66489f5ad3c1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neu
tron_agent.py#L189 [5] https://review.openstack.org/#/c/280595/

__
 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



--
Davanum Srinivas :: https://twitter.com/dims

__
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][nova][oslo] Common backoff & timeout utils

[Doug Hellmann]

Excerpts from Chris Dent's message of 2016-04-20 22:16:10 +0100:
> 
> Will the already existing retrying[1] do the job or is it missing
> features (the namespacing thing seems like it could be an issue)
> or perhaps too generic?
> 
> [1] https://pypi.python.org/pypi/retrying
> 

Yes, please, let's try to make that work and contribute upstream if we
need minor modifications, before we create something new.

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

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

[Chris Dent]

Will the already existing retrying[1] do the job or is it missing
features (the namespacing thing seems like it could be an issue)
or perhaps too generic?

[1] https://pypi.python.org/pypi/retrying

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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][nova][oslo] Common backoff & timeout utils

[Amrith Kumar]

Boden,

Are you thinking of implementing something which would perform exponentially 
backed off calls to some arbitrary function till that method returns with 
something other than a timeout?

I think that would be very versatile, and useful in a wide variety of places.

Thanks,

-amrith

> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: Wednesday, April 20, 2016 4:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][nova][oslo] Common backoff &
> timeout utils
> 
> Sounds good to me Boden.
> 
> -- Dims
> 
> On Wed, Apr 20, 2016 at 4:10 PM, Boden Russell <boden...@gmail.com> wrote:
> > Today there are a number of places in nova, neutron and perhaps
> > elsewhere that employ backoff + timeout strategies (see [1] - [4]).
> > While we are working towards a unified approach in neutron for RPC
> > [5], it appears such logic could benefit the greater community as a
> > reusable oslo implementation.
> >
> > IMHO such an oslo implementation could:
> > - Enable backoff/timeout irrespective of client/transport. This would
> > allow the utils to be used with various clients (HTTP, AMQP RPC, etc.).
> > - Support namespacing as inspired by the existing neutron patch [5].
> > - In the future, perhaps, allow multiple (pluggable) backoff
> > strategies to be used (e.g. configurable backoff).
> >
> > Anyone adverse to me crafting an initial oslo patch to kick-off the
> > details on this one?
> >
> >
> > Thanks
> >
> >
> > [1]
> > https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L1
> > 62
> > [2]
> > https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c9
> > 7dc1d065b/nova/scheduler/utils.py#L356
> > [3]
> > https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb3
> > 1317ba469a58/neutron/agent/l3/agent.py#L224
> > [4]
> > https://github.com/openstack/neutron/blob/42c6f05f2904cd4c01bcd3f79b19
> > 66489f5ad3c1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neu
> > tron_agent.py#L189 [5] https://review.openstack.org/#/c/280595/
> >
> > __
> >  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
> 
> 
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> 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][nova][oslo] Common backoff & timeout utils

[Kevin L. Mitchell]

On Wed, 2016-04-20 at 14:10 -0600, Boden Russell wrote:
> Anyone adverse to me crafting an initial oslo patch to kick-off the
> details on this one?

Have you evaluated any existing solutions in this space?  A quick search
on PyPi turns up "backoff", which seems to provide several backoff
strategies.  Of course, it's a decorator-based backoff implementation,
whereas I tend to implement iterator-based solutions, but there may
already be a solution in that space as well…
-- 
Kevin L. Mitchell 


signature.asc
Description: This is a digitally signed message part
__
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][nova][oslo] Common backoff & timeout utils

[Davanum Srinivas]

Sounds good to me Boden.

-- Dims

On Wed, Apr 20, 2016 at 4:10 PM, Boden Russell  wrote:
> Today there are a number of places in nova, neutron and perhaps
> elsewhere that employ backoff + timeout strategies (see [1] - [4]).
> While we are working towards a unified approach in neutron for RPC [5],
> it appears such logic could benefit the greater community as a reusable
> oslo implementation.
>
> IMHO such an oslo implementation could:
> - Enable backoff/timeout irrespective of client/transport. This would
> allow the utils to be used with various clients (HTTP, AMQP RPC, etc.).
> - Support namespacing as inspired by the existing neutron patch [5].
> - In the future, perhaps, allow multiple (pluggable) backoff strategies
> to be used (e.g. configurable backoff).
>
> Anyone adverse to me crafting an initial oslo patch to kick-off the
> details on this one?
>
>
> Thanks
>
>
> [1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L162
> [2]
> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/scheduler/utils.py#L356
> [3]
> https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb31317ba469a58/neutron/agent/l3/agent.py#L224
> [4]
> https://github.com/openstack/neutron/blob/42c6f05f2904cd4c01bcd3f79b1966489f5ad3c1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L189
> [5] https://review.openstack.org/#/c/280595/
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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-dev] [neutron][nova][oslo] Common backoff & timeout utils

[Boden Russell]

Today there are a number of places in nova, neutron and perhaps
elsewhere that employ backoff + timeout strategies (see [1] - [4]).
While we are working towards a unified approach in neutron for RPC [5],
it appears such logic could benefit the greater community as a reusable
oslo implementation.

IMHO such an oslo implementation could:
- Enable backoff/timeout irrespective of client/transport. This would
allow the utils to be used with various clients (HTTP, AMQP RPC, etc.).
- Support namespacing as inspired by the existing neutron patch [5].
- In the future, perhaps, allow multiple (pluggable) backoff strategies
to be used (e.g. configurable backoff).

Anyone adverse to me crafting an initial oslo patch to kick-off the
details on this one?


Thanks


[1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L162
[2]
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/scheduler/utils.py#L356
[3]
https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb31317ba469a58/neutron/agent/l3/agent.py#L224
[4]
https://github.com/openstack/neutron/blob/42c6f05f2904cd4c01bcd3f79b1966489f5ad3c1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L189
[5] https://review.openstack.org/#/c/280595/

__
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