Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

I pushed https://review.openstack.org/#/c/425023 as one of approaches. On Wed, Jan 25, 2017 at 10:29 AM Anna Taraday <akamyshnik...@mirantis.com> wrote: > Thanks for bringing this up! > > I was assuming that from Ocata everyone should switch from usage 'old' > TunnelTypeDri

Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

Thanks for bringing this up! I was assuming that from Ocata everyone should switch from usage 'old' TunnelTypeDriver to updated one. Revering both back to session means reverting all refactor and this is not in line with enginefacade work and as I remember some of OVO patches we waiting for this

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

ms > > On Tue, Jan 24, 2017 at 10:33 AM, Anna Taraday > <akamyshnik...@mirantis.com> wrote: > > Nope, this won't be necessary. > > > > 0.8.10 - allows us to create pk on alembic_version table automatically, > but > > only for new deployments. > >

Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

OK, this makes sense. Thanks for clarification! On Wed, Jan 25, 2017 at 10:50 PM Ihar Hrachyshka <ihrac...@redhat.com> wrote: > On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday > <akamyshnik...@mirantis.com> wrote: > > Thanks for bringing this up! > > > > I w

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

+1 On Sun, Feb 19, 2017 at 11:03 AM Takashi Yamamoto wrote: > +1 > > 2017/02/18 4:21 "Kevin Benton" : > > Hi all, > > I'm organizing a Neutron social event for Thursday evening in Atlanta > somewhere near the venue for dinner/drinks. If you're

[openstack-dev] [Neutron] Alternative approaches for L3 HA

Hello everyone! In Juno in Neutron was implemented L3 HA feature based on Keepalived (VRRP). During next cycles it was improved, we performed scale testing [1] to find weak places and tried to fix them. The only alternative for L3 HA with VRRP is router rescheduling performed by Neutron server,

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

this email to understand whether community have interest in something like this, so that it will be worth doing. On Tue, Feb 14, 2017 at 10:20 PM Assaf Muller <as...@redhat.com> wrote: On Fri, Feb 10, 2017 at 12:27 PM, Anna Taraday <akamyshnik...@mirantis.com> wrote: > Hello everyo

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

In etcd for each HA router we can store key which will identify which agent is active. L3 agents will "watch" this key. All these tools have leader election mechanism which can be used to get agent which is active for current HA router. On Mon, Feb 13, 2017 at 7:02 AM zhi

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

ity of the control plane (etcd cluster or any other KV store) then > an operator would have to account for extra failure scenarios for the KV > store which would affect multiple routers than the outage of a single L3 > node which is the case we usually have to account now. > &g

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

If OS wants support Galera, it needs to comply with the Galera > >>> > requirements. > >>> > > >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka < > ihrac...@redhat.com> > >>> > wrote: > >>> >> > >&g

[openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

Hello everyone! Guys in our team faced an issue when they try to run alembic migrations on Galera with ENFORCING mode. [1] This was an issue with Alembic [2], which was quickly fixed by Mike Bayer (many thanks!) and new version of alembic was resealed [3]. The global requirements are updated

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

> Don't you still need alembic>=0.8.10 to be present? > > -- Dims > > On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday > <akamyshnik...@mirantis.com> wrote: > > We do not backport db changes, but if the existing migration does not > work > > in certa

Re: [openstack-dev] Fwd: Questions regardin https://review.openstack.org/#/c/289595/11/tools/database-migration-from-v1-to-v2.py

Hi! I guess you hit https://bugs.launchpad.net/neutron/+bug/1503342, seems we need to reopen it. I can only suggest to create migration manually "neutron-db-manage --config-file /etc/neutron/neutron.conf revision -m "description of revision" --contact/expand. Then you will see path to file

Re: [openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

Henry, thanks for taking care of this! In my opinion, it is just safe to use raw values in migration, because migration is a strict point in time. I remember how many patches I send in havana in Neutron for fixing synchronization issues. Usage constants everywhere can be good in this case, but

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Very nice place, I'd love to come :) +1 On Mon, Oct 17, 2016 at 11:18 AM wrote: > Hello, > > +1 > > -- > Sławek Kapłoński > sla...@kaplonski.pl > > > W dniu 14.10.2016 20:30, Miguel Lavalle napisał(a): > > > Dear Neutrinos, > > > > I am organizing a social event for the

[openstack-dev] [Neutron][networking-*] Refactor of segments db

Hello everyone! I'm working on implementation new engine facade in Neutron. [1] We have a number of functions that expect to get session as one the arguments. Passing session is not correct and this prevents of usage new enginefacade which expect context to be passed and session to be injected in

Re: [openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

wrote: > Henry Gessau <hen...@gessau.net> wrote: > > > Anna Taraday <akamyshnik...@mirantis.com> wrote: > >> Henry, thanks for taking care of this! > >> > >> In my opinion, it is just safe to use raw values in migration, because > >> migration

Re: [openstack-dev] [neutron] Stepping down as testing lieutenant and from the core & drivers teams

It was real pleasure to work with you! Thank you for your guidance and comments, we will miss that :( Wish you all the best! On Tue, Nov 29, 2016 at 9:55 AM Vikram Choudhary < vikram.choudh...@huawei.com> wrote: > Hi Assaf, > > Wish you all the best for your future endeavor! > > Thanks > Vikram

[openstack-dev] [Neutron][networking-*] Refactor ml2/db file

Hello everyone! I'm working on implementation new engine facade in Neutron. [1] I wrote before about refactoring segments db code, along with that refactor of ml2/db.py [2] is also required (to pass context instead of session). I proposed patch for Neutron and affected projects(networking-cisco,

Re: [openstack-dev] [Neutron][networking-*] Refactor ml2/db file

https://review.openstack.org/#/c/404714/ [2] - https://review.openstack.org/#/q/topic:refactor_ml2db On Fri, Dec 9, 2016 at 1:49 PM Anna Taraday <akamyshnik...@mirantis.com> wrote: > Hello everyone! > I'm working on implementation new engine facade in Neutron. [1] I wrote > before about refacto

Re: [openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

+topic:refactor_ml2db Happy holidays for everyone! On Thu, Dec 22, 2016 at 7:36 AM Russell Bryant <rbry...@redhat.com> wrote: > > On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday <akamyshnik...@mirantis.com > > wrote: > > Hello everyone! > > I've got two chang

[openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

Hello everyone! I've got two changes with refactor of TypeDriver [1] and segments db [2] which is needed for implementation new engine facade [3]. Reviewers of networking-cisco, networking-arista, networking-nec

Re: [openstack-dev] [neutron] Engine facade

Hi! I'm a little confused change https://review.openstack.org/#/c/452539/ is about switching for new facade, does the master branch fails the same? On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton wrote: > Yes, sorry my bad for not adding it - >

Re: [openstack-dev] [neutron] Engine facade

eleting DB entries under transaction also broke Thanks Gary *From: *Anna Taraday <akamyshnik...@mirantis.com> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org> *Date: *Monday, April 3, 2017 at 11:53 AM *To: *OpenStack List <openstack-dev@lists.openstack.org> *Subject: *R

Re: [openstack-dev] [neutron] stepping down from neutron core team

Thanks a lot for all that you've done! Wish you all the best! On Fri, Apr 28, 2017 at 1:04 PM Miguel Angel Ajo Pelayo wrote: > > Hi everybody, > > Some of you already know, but I wanted to make it official. > > Recently I moved to work on the networking-ovn

Re: [openstack-dev] [Neutron] stepping down from core

Rossella, It is pleasure to know you and your contribution for Neutron is remarkable :) I wish you all the best! On Fri, May 5, 2017 at 6:28 AM Edgar Magana wrote: > Que??? Estás bien? > Me ha sorprendido tu email. > > Sent from my iPhone > > > On May 4, 2017, at 6:55

Re: [openstack-dev] [neutron] Neutron L3 agent/Keepalived

Please, file a bug about that on https://bugs.launchpad.net/neutron/+bugs with tag "l3-ha". On Thu, Nov 30, 2017 at 6:00 AM Ajay Kalambur (akalambu) wrote: > I noticed that this happens when the router HA interface shows status: > Down what can cause the ha interface to do

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

+1 ! Well deserved! On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton wrote: > +1 > > > > Welcome to the team! > > > > *From: *Miguel Lavalle > *Reply-To: *OpenStack List > *Date: *Wednesday, November 29, 2017 at 9:21 PM >

Re: [openstack-dev] [neutron][stable] Stepping down from core

Ihar, Neutron can not be what it is without all your work! Thank you and wish you all the best! On Wed, Jun 6, 2018 at 11:22 AM Andreas Scheuring < scheu...@linux.vnet.ibm.com> wrote: > Hi Ihar, it was always a pleasure learning from and working with you. Wish > you all the best for your new

Re: [openstack-dev] [neutron] Stepping down from core

Armando, you made Neutron what it is now. Thank you for all your work and wish you all the best! On Sun, Dec 24, 2017 at 4:16 PM reedip banerjee wrote: > Hi Armando, > Its not easy to hear this news. > But all the best of luck to you Armando for your future endeavors. > >

[openstack-dev] [Octavia] Multinode setup

Hello everyone! I'm looking into how to run Octavia services (controller worker, housekeeper, health manager) on several network nodes and get confused with setup guide [1]. Is there any special config option for such case? (controller_ip_port_list probably) What manuals/docs/examples do we have