Re: [openstack-dev] OpenStack upstream specs - Invitation to edit

[Tomasz Pa]

Hey James,


I'am unable to open this document :(

TP (Tomasz from Intel)

On Tue, Oct 18, 2016 at 2:35 PM, James Penick (via Google Docs) <
jpen...@gmail.com> wrote:

> James Penick  has invited you to *edit* the following
> document:
> OpenStack upstream specs
> 
> Open in Docs
> 
> This email grants access to this item without logging in. Only forward it
> to people you trust.
> Google Docs: Create and edit documents online.
> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
> You have received this email because someone shared a document with you
> from Google Docs. [image: Logo for Google Docs] 
>
> __
> 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
>
>


-- 
Tomasz Paszkowski
OpenStack | Kubernetes | SDN
+48500166299
__
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] [octavia] Neutron LBaaS V2 with haproxy namespace driver HA

[Liping Mao (limao)]

Thanks Michael for the info, let me try Octavia first.

Regards,
Liping Mao

在 17/9/11 05:30，“Michael Johnson” 写入:

Hi Liping,

FYI, Neutron LBaaS is no longer part of Neutron.  Load balancing has
been consolidated under the Octavia project. I have added that tag to
the subject.

We currently do not have plans to add HA capabilities to the haproxy
namespace driver. The intention behind building the octavia driver was
to enable a scalable and HA load balancing driver.
There would be a number of complications to enabling this and given
the limitations of the haproxy namespace driver most environments with
HA requirements use the octavia driver.

Michael

On Sun, Sep 10, 2017 at 6:44 AM, Liping Mao (limao)  wrote:
> Hi Neutron LBaaS team,
>
> One quick question about HA LBaaS V2 with haproxy namespace driver(not 
Octavia).
> Do we have any plan to support Haproxy HA with Keepalived?
> (Something similar with L3 HA).
>
> I see we got some patch supported some level HA[1][2], but
> Still need sometime(Mins) to failover when the active node is down.
>
> Thanks for your help.
>
> [1]https://review.openstack.org/#/c/28/
> [2]https://review.openstack.org/#/c/327966/
>
> Regards,
> Liping Mao
>
>
> __
> 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] [tripleo] stable/pike gate is broken with containers

[Martin André]

On Sun, Sep 10, 2017 at 10:47 PM, Emilien Macchi  wrote:
> Today I found 2 issues:
>
> 1) https://bugs.launchpad.net/tripleo/+bug/1716256
>
> http://logs.openstack.org/94/500794/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/c3e3945/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_14_49_29
>
> I think we need this backport: https://review.openstack.org/#/c/502291
> but it fails here:
> http://logs.openstack.org/91/502291/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/8140294/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_19_42_16
>
> We probably missed some other backports. Can anyone familiar with this
> piece help?

I've replied to the bug, it's an issue with the python-tripleoclient
package used on the undercloud that is too old and doesn't have the
code that was merged 10 days ago in the stable/pike branch. Not sure
what is going on.

> 2) https://bugs.launchpad.net/tripleo/+bug/1716280
>
> stable/pike CI deploys Queens containers, tag is missing in Docker
> Registry. I'm cc'ing dprince because I think he has access to the
> dockerhub account, in case we need to do any change there.

Here I'm rebuilding the images for pike with the appropriate tag. Once
this is done we can use the pike tag in CI.

Martin

> Thanks for the help,
> --
> Emilien Macchi
>
> __
> 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-dev] [mistral][ptg] Mistral PTG etherpad and schedule

[Renat Akhmerov]

Welcome to the Queens PTG!

Just reminding that the Mistral PTG is at [1] and it includes the approximate 
schedule. I’m saying “approximate” because, if needed, we can change it a 
little bit if some important topics will be raised unexpectedly.  So I’d 
suggest we quickly review the entire schedule once we start our design sessions 
on Wed.

Looking forward to seeing all the team members who came! Also, not only Mistral 
team members are welcome to join. If you have something to discuss with us 
please come to our room or ping us in IRC.

[1] https://etherpad.openstack.org/p/mistral-ptg-queens

Thanks

Renat Akhmerov
@Nokia
__
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] [octavia] Neutron LBaaS V2 with haproxy namespace driver HA

[Michael Johnson]

Hi Liping,

FYI, Neutron LBaaS is no longer part of Neutron.  Load balancing has
been consolidated under the Octavia project. I have added that tag to
the subject.

We currently do not have plans to add HA capabilities to the haproxy
namespace driver. The intention behind building the octavia driver was
to enable a scalable and HA load balancing driver.
There would be a number of complications to enabling this and given
the limitations of the haproxy namespace driver most environments with
HA requirements use the octavia driver.

Michael

On Sun, Sep 10, 2017 at 6:44 AM, Liping Mao (limao)  wrote:
> Hi Neutron LBaaS team,
>
> One quick question about HA LBaaS V2 with haproxy namespace driver(not 
> Octavia).
> Do we have any plan to support Haproxy HA with Keepalived?
> (Something similar with L3 HA).
>
> I see we got some patch supported some level HA[1][2], but
> Still need sometime(Mins) to failover when the active node is down.
>
> Thanks for your help.
>
> [1]https://review.openstack.org/#/c/28/
> [2]https://review.openstack.org/#/c/327966/
>
> Regards,
> Liping Mao
>
>
> __
> 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-dev] [tripleo] stable/pike gate is broken with containers

[Emilien Macchi]

Today I found 2 issues:

1) https://bugs.launchpad.net/tripleo/+bug/1716256

http://logs.openstack.org/94/500794/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/c3e3945/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_14_49_29

I think we need this backport: https://review.openstack.org/#/c/502291
but it fails here:
http://logs.openstack.org/91/502291/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/8140294/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_19_42_16

We probably missed some other backports. Can anyone familiar with this
piece help?


2) https://bugs.launchpad.net/tripleo/+bug/1716280

stable/pike CI deploys Queens containers, tag is missing in Docker
Registry. I'm cc'ing dprince because I think he has access to the
dockerhub account, in case we need to do any change there.

Thanks for the help,
-- 
Emilien Macchi

__
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] [interop][refstack] proposal for extending published and submitted info

[Arkady.Kanevsky]

Fellow interop members,
I would like to request we consider adding information on what was tested for 
interop.
Specifically, if you are listed in distros and appliances it would be good to 
be able to specify what underlying HW was used for interop testing.
I do not propose that as the requirement for submission but ability for 
submitters to specify it if they want to.
Why?
1. HW vendors have something to list in the submission.
2. If you have openstack solutions with multiple options for distros, common 
for HW vendors, it allows them to provide multiple submissions and entries at 
marketplace.
3. It provides helpful information for Consumers of openstack when they use 
marketplace data for their decision making. Especially when they choose both HW 
and distro for their decision making.

I will be happy to generate blueprint if the team warrants it.
Thanks,
Arkady
__
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] [trove]how to save time of creating instance?

[Amrith Kumar]

The amount of time taken to create a trove instance (or cluster) is largely
related to how long it takes to create a nova instance of the same size.
So, how long does it take to create a nova instance of the same size on
your system?

Does your trove image install the database statically into the image, or
will it install the database on the fly?


-amrith


2017-09-06 0:01 GMT-07:00 王俊 :

> Hi:
>
> it will take 8 minutes to create a mysql instance, and will take 16
> minutes to create mysql cluster, which have one master and one slave
>
> 保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
>
> __
> 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-dev] [policy] [all] policy in code schedule and room

[Lance Bragstad]

Hey all,

The schedule [0] has been updated with room information for the
policy-in-code effort. We'll be in Grays Peak on Level 3 on Monday and
Tuesday to help projects with the Queens goal [1].


[0] https://etherpad.openstack.org/p/policy-queens-ptg
[1] https://governance.openstack.org/tc/goals/queens/policy-in-code.html




signature.asc
Description: OpenPGP digital 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] [keystone] Queens PTG Planning

[Lance Bragstad]

Looks like we'll be in Telluride B, Atrium Level. I've updated the room
information in the etherpad [0].

[0] https://etherpad.openstack.org/p/keystone-queens-ptg


On 08/24/2017 02:25 PM, Lance Bragstad wrote:
> I've worked the topics into a schedule [0]. Monday and Tuesday are
> pretty general, but contain topics we need to discuss with other
> projects. I've left these time slots flexible for now and I'll start
> another thread to include other projects. Wednesday and Thursday are
> mostly project-specific keystone topics we can hash out in our room. The
> last day is pretty open, but I expect to push topics to Friday
> throughout the week if they need more discussion. After all that we do
> have a couple time slots open on Wednesday and Thursday if we missed
> something.
>
> I've also bootstrapped Etherpads for all topics and linked to them from
> the main etherpad. Each has some basic context, at least enough to kick
> start a conversation. If I missed details for a specific topic, please
> feel free to elaborate. If you see something you have an interest in, or
> want to drive, please add your name to the top of the Etherpad as a
> champion, moderator, or scribe (see definitions in the main schedule).
>
> Let me know if you see any issues or conflicts.
>
> Thanks,
>
> Lance
>
> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>
>
> On 07/27/2017 12:21 PM, Lance Bragstad wrote:
>> I've added a section to the etherpad [0] for attendees. We need to start
>> getting an idea of how many people plan on attending the PTG (for
>> scheduling purposes). Please add your name and IRC nick to the list.
>>
>> Thanks
>>
>> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>>
>>
>> On 07/05/2017 11:22 AM, Lance Bragstad wrote:
>>> Hey all,
>>>
>>> I've started an etherpad [0] for us to collect topics and ideas for the
>>> PTG in September. I hope to follow the same planning format as last
>>> time. Everyone has the opportunity to add topics to the agenda and after
>>> some time we'll group related topics and start building a formal schedule.
>>>
>>> The etherpad has two lists. One for project-specific topics and one for
>>> cross-project topics. As soon as we firm up the things we need to
>>> collaborate on with other projects, I'll start coordinating with other
>>> teams. These were the sessions we had to work around last time due to
>>> schedules. We can sprinkle the project related topics in to fill the gaps.
>>>
>>> Let me know if you have any questions.
>>>
>>> Thanks!
>>>
>>>
>>> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>>>
>>>
>




signature.asc
Description: OpenPGP digital 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] [keystone] [nova] [neutron] [cinder] [ironic] [glance] [swift] Baremetal/VM SIG PTG Schedule/Etherpad

[Lance Bragstad]

Looks like the Baremetal/VM SIG (#compute) will meet in Ballroom B,
Banquet Level. I've updated the etherpad with the room information [0].

[0] https://etherpad.openstack.org/p/queens-PTG-vmbm


On 09/07/2017 10:01 AM, Lance Bragstad wrote:
> I spoke with John a bit today in IRC and we have a rough schedule worked
> out for the Baremetal/VM SIG. All the sessions/ideas/carry-over topics
> from Boston have been filtered into a schedule and is available in the
> etherpad [0].
>
> Each entry should have a "lead" to drive the discussion and a "goal" to
> work towards. I took a stab at listing leads and goals accordingly, but
> if you're more familiar with the topics, please adjust as necessary. If
> you noticed a conflict with another session, feel free to respond here,
> leave a comment in the etherpad, or ping me on IRC. I know it's a bit
> late, but I'd like to have the schedule pretty well set by the weekend.
>
> Thanks!
>
>
> [0] https://etherpad.openstack.org/p/queens-PTG-vmbm
>
> On 08/24/2017 03:34 PM, Lance Bragstad wrote:
>> Hi all,
>>
>> Keystone has a few cross-project topics we'd like to share with a wider
>> group, like the Baremetal/VM SIG. As a result, I attempted to dust off
>> some of the Baremetal/VM sessions [0][1] from Boston and port the
>> popular topics over to the etherpad for the PTG [2]. Maybe it will kick
>> start some discussions before we get there?
>>
>> John has more insight into this than I do, but I'm curious if we plan to
>> have a rough schedule for Monday and Tuesday? I'm happy to help
>> coordinate or shuffle bits for the baremetal/VM group if ideas come up here.
>>
>>
>> [0] https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal
>> [1] https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
>> [2] https://etherpad.openstack.org/p/queens-PTG-vmbm
>>
>




signature.asc
Description: OpenPGP digital 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

[openstack-dev] [tripleo] TripleO Pike RC2 has been released

[Emilien Macchi]

We released TripleO Pike RC2 today!

Here are some numbers:
6 blueprints implemented (from FFE)
70 bugs fixed

The release team will propose the final release based on this RC2 tag
during the next days.
We'll continue to work on Pike stabilization and doing bugfix backports.
A new tag will be pushed to newton / ocata / pike every two weeks for
now, which should help downstream releases as well.

It has been a real pleasure for me to be PTL of TripleO during 2
cycles, I would like to thank everyone for the hard work and patience
in difficult times. We have a bunch of challenges ahead but our team
is awesome so I have no doubt we'll continue to succeed.

Thanks, and enjoy the PTG for the lucky attendees!
-- 
Emilien Macchi

__
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] [all] Cinder V1 API Removal

[Dean Troyer]

[followup...]

On Sat, Sep 9, 2017 at 4:51 PM, Dean Troyer  wrote:
> [0] https://review.openstack.org/#/c/485232

I rebased this one to see where we stand with just removing the
'volume' service type.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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] [tripleo] tripleo-puppet-elements 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for tripleo-puppet-elements for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-puppet-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-puppet-elements/log/?h=stable/pike

Release notes for tripleo-puppet-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-puppet-elements/




__
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] [tripleo] tripleo-image-elements 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for tripleo-image-elements for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-image-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-image-elements/log/?h=stable/pike

Release notes for tripleo-image-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-image-elements/




__
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] [tripleo] tripleo-heat-templates 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for tripleo-heat-templates for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-heat-templates/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-heat-templates/log/?h=stable/pike

Release notes for tripleo-heat-templates can be found at:

http://docs.openstack.org/releasenotes/tripleo-heat-templates/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/tripleo

and tag it *pike-rc-potential* to bring it to the tripleo-heat-templates
release crew's attention.


__
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] Neutron LBaaS V2 with haproxy namespace driver HA

[Liping Mao (limao)]

Hi Neutron LBaaS team,

One quick question about HA LBaaS V2 with haproxy namespace driver(not Octavia).
Do we have any plan to support Haproxy HA with Keepalived? 
(Something similar with L3 HA).

I see we got some patch supported some level HA[1][2], but
Still need sometime(Mins) to failover when the active node is down.

Thanks for your help.

[1]https://review.openstack.org/#/c/28/
[2]https://review.openstack.org/#/c/327966/

Regards,
Liping Mao


__
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][oslo.db] db retry madness

[Michel Peterson]

Thanks for this most interesting and informative exchange.

On Fri, Sep 8, 2017 at 5:20 PM, Michael Bayer  wrote:
> On Fri, Sep 8, 2017 at 8:53 AM, Kevin Benton  wrote:
> > Since the goal of that patch is to deal with deadlocks, the retry can't
> > happen down at that level, it will need to be somewhere further up the call
> > stack since the deadlock will put the session in a rollback state.
>
>
> OK when I was talking to Michel about this, I first mentioned that to
> get retry within this in-a-transaction block would require adding a
> savepoint to the mix, but he seemed to indicate that the method can
> also run by itself, but since there's no session.begin() there then
> that matches with my initial impression that the retry has to be at
> the level which the transaction starts, and that's not here.


I think there is also a deal of madness on how things are implemented
in this particular project. I'll review the way it's handled and
adjust accordingly, and then implement the right retries in the
correct places. I think my strategy will be to first start with using
a decorator based on wrap_db_retry to fix the bug. After that I'll
start, in another set of patches, the migration from the "legacy"
pattern to the "new" enginefacade. What do you think? Or given that
enginefacade already diminishes the possibilities of deadlocks I
should already start with the migration to enginefacade and then with
that already in place

> > For the functions being called outside of an active session, they should
> > switch to accepting a context to handle the enginefacade switch.

ACK.

> >>  3a.  Is this a temporary measure to work around legacy patterns?
> >
> > Yes. When that went in we had very little adoption of the enginefacade. Even
> > now we haven't fully completed the transition so checking for is_active
> > covers the old code paths.
>
> OK, so this is where they are still calling session.begin()
> themselves.Are all these session.begin() calls in projects under
> the "openstack" umbrella so I can use codesearch ?

So, to make sure I understand correctly. With enginefacade instead of
calling session.begin() to handle the transactions, when using
'reader' o 'writer' we are already inside a transaction, right? If
that's correct, no matter if decorating or using a context manager, in
both cases the transaction lives for the context of the decorated
function or the with-stmt context, right?

> > As we continue migrating to the enginefacade, the cases where you can get a
> > reference to a session that actually has 'is_active==False' are going to
> > keep dwindling. Once we complete the switch and remove the legacy session
> > constructor, the decorator will just be adjusted to check if there is a
> > session attached to the context to determine if retries are safe since
> > is_active will always be True.

Therefore, on implementation of enginefacade retry_if_session_inactive
is rendered useless and because of the deepcopy retry_db_errors in our
usecase is already useless. As a result we are better off with using
wrap_db_retry to create a decorator parametrised according to our
needs (ie: max retries, exception checker, etc), right? And for
exception checker I should use the is_retriable from neutron-lib
instead of the neutron db api, right? (it's a shame that MAX_RETRIES
is not also on neutron-lib and only in neutron)

Thanks to you both.

__
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