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

Hi neutrinos and all, As some of you've already noticed, the last several months I was scaling down my involvement in Neutron and, more generally, OpenStack. I am at a point where I feel confident my disappearance won't disturb the project, and so I am ready to make it official. I am stepping

Re: [openstack-dev] [openstack-infra] How to take over a project?

ONOS is not part of Neutron and hence Neutron Release team should not be involved in its matters. If gerrit ACLs say otherwise, you should fix the ACLs. Ihar On Tue, Apr 24, 2018 at 1:22 AM, Sangho Shin wrote: > Dear Neutron-Release team members, > > Can any of you

Re: [openstack-dev] [neutron] [networking-ovn] Non voting jobs for networking-ovn on neutron.

On Mon, Dec 4, 2017 at 5:20 AM, Miguel Angel Ajo Pelayo wrote: > We were thinking about the option of having a couple of non-voting jobs > on > the neutron check for networking-ovn. It'd be great for us, in terms of > traceability, > we re-use a lot of the neutron unit

Re: [openstack-dev] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

Hi Andrea, thanks for taking time to reply. I left some answers inline. On Fri, Jan 19, 2018 at 9:08 AM, Andrea Frittoli <andrea.fritt...@gmail.com> wrote: > > > On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >> Hi all, &

Re: [openstack-dev] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

On Thu, Jan 18, 2018 at 8:33 AM, Michael Johnson wrote: > This sounds great Ihar! > > Let us know when we should make the changes to the neutron-lbaas projects. > > Michael Hi Michael! You can already start, by introducing new service names without q-* for your services.

[openstack-dev] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

Hi all, tl;dr I propose to switch to lib/neutron devstack library in Queens. I ask for buy-in to the plan from release and QA teams, something that infra asked me to do. === Last several cycles we were working on getting lib/neutron - the new in-tree devstack library to deploy neutron services

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

For the record, I added Lucas to the gerrit group. I assume he will mostly focus on OVN patches. You are still welcome to review other repo patches, and if you stick to it, I am happy to expand your role to cover all of them. As for OVN, you only have one +2, and existing stable reviewers may not

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

Please tell me who from the OVN group is ready to take the burden, and I will make you part of neutron-stable-maint. I think it's ok to be more laissez faire with backports for subprojects than we were used to, with the recent drop in core team membership and reduced capacity. Ihar On Wed, Dec

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

It's a sad day. But I am happy we had you in leadership for so many productive years. I also hope the community is anti-fragile and adopts to changes. I wish you all the best. Ihar On Fri, Dec 15, 2017 at 11:01 AM, Armando M. wrote: > Hi neutrinos, > > To some of you this

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

YES, FINALLY. On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton wrote: > +1! ... even though I haven't been around. :) > > On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle wrote: >> >> Hi Neutron Team, >> >> I want to nominate Slawek Kaplonski (irc: slaweq) to

Re: [openstack-dev] [neutron] multiple agents with segment access

In general, you should be able to run both regular l2 agent (ovs) and sriov agent. If you have problems with it, we should probably assume it's a bug. Please report. On Tue, Nov 14, 2017 at 8:02 AM, Legacy, Allain wrote: > Is it a known limitation that the ML2 plugin

Re: [openstack-dev] [zun][neutron] About Notifier

I don't think it is supposed to be pluggable, so no guarantees it won't break for you if you decide to implement an out-of-tree notifier. But I think Zun could instead listen for notifications that are fed into ceilometer. We already issue those notifications, so it would make sense to retrieve

Re: [openstack-dev] Supporting SSH host certificates

What you describe (at least the use case) seems to resemble https://review.openstack.org/#/c/456394/ This work never moved anywhere since the spec was posted though. You may want to revive the discussion in scope of the spec. Ihar On Fri, Sep 29, 2017 at 12:21 PM, Giuseppe de Candia

[openstack-dev] [neutron] Ocata moving to phase II

Hi all, with the latest Ocata release[1], stable/ocata branches now officially move to phase II support. The phase is defined in [2] as: "Only critical bugfixes and security patches are acceptable." In Neutron, it usually means that we may now allow fixes for High and Critical bugs only. (Plus

Re: [openstack-dev] [neutron] MTU native ovs firewall driver

On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu) wrote: > So I was forced to explicitly set the MTU on br-int > ovs-vsctl set int br-int mtu_request=9000 > > > Without this the tap device added to br-int would get MTU 1500 > > Would this be something the ovs l2 agent

Re: [openstack-dev] [Neutron] Denver Team Dinner

+1 On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton wrote: > +1 > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński > wrote: >> >> +1 >> >> — >> Best regards >> Slawek Kaplonski >> sla...@kaplonski.pl >> >> >> >> >> > Wiadomość napisana przez Miguel Lavalle

Re: [openstack-dev] removing screen from devstack - RSN

On Fri, Sep 8, 2017 at 2:17 PM, John Villalovos wrote: > Does this mean we can now get more user friendly names for the log files? > > Currently I see names like: > screen-dstat.txt.gz > screen-etcd.txt.gz > screen-g-api.txt.gz > screen-g-reg.txt.gz >

Re: [openstack-dev] [neutron] - transitioning PTL role to Miguel Lavalle

It's very sad news for the team, but I hope that Kevin will still be able to contribute, or at least stay in touch. I am sure Miguel will successfully lead the community in Queens and beyond. Thanks to Miguel for stepping in the ring. Thanks to Kevin for his leadership in recent cycles. King is

[openstack-dev] [neutron] no upgrades meeting tomorrow

Hi, I won't be able to chair the meeting because of a conference, so I cancel it. We won't have one the week after that because of PTG either. We will meet the next time in two weeks. Thanks, Ihar __ OpenStack Development

Re: [openstack-dev] [neutron][puppet] mod_wsgi support (pike bug?)

On Mon, Sep 4, 2017 at 8:07 AM, Kevin Benton wrote: > #2 would be preferable as well just because we have so many guides/distros > mentioning the different file locations. I'm not familiar with mod_wsgi > enough to know if it's possible. > > Another 3rd option may be to edit the

Re: [openstack-dev] [neutron] [tests] [tempest] Neutron dvr tempest test problem

On Thu, Aug 24, 2017 at 5:13 AM, Luigi Toscano wrote: > On Thursday, 24 August 2017 12:51:05 CEST Ning Yao wrote: >> Hi, all >> >> I encounter a problem about neutron tempest test. I run the tempest >> neutron plugin test against my self-build OpenStack, and I find that >>

[openstack-dev] [neutron] no CI and upgrades meetings this week

Hi, we are in pre-release mode, and some of active participants will not be able to join those meetings, so we will cancel them this week. Thanks, and see you all next week. Ihar __ OpenStack Development Mailing List (not

Re: [openstack-dev] [neutron] Functional job failure rate at 100%

On Mon, Aug 7, 2017 at 2:52 AM, Jakub Libosvar wrote: > Hi all, > > as per grafana [1] the functional job is broken. Looking at logstash [2] > it started happening consistently since 2017-08-03 16:27. I didn't find > any particular patch in Neutron that could cause it. > >

Re: [openstack-dev] [neutron] Call for help with in-tree tempest scenario test failures

Thanks for those who stepped in (Armando and Slawek). We still have quite some failures that would benefit from initial log triage and fixes. If you feel like in this feature freeze time you have less things to do, helping with those scenario failures would be a good way to contribute to the

[openstack-dev] [neutron] FFE for net-mtu-enh api extension requested

Hi PTL/all, I would like to request an exception for inclusion of net-mtu-enh API extension (with ML2 implementation) for Pike. The patch is ready for review, it includes tempest tests and docs update. There are several things in the patch that we will need to follow up in the next release

Re: [openstack-dev] [all] Proposal to change integrated neutron grenade gate job to multi-node

I don't see any issue with it, but it would be great to hear from infra. They may have their reservations because the change may somewhat raise pressure on the number of nodes (that being said, there are some savings too for projects that currently run both versions of the job at the same time -

Re: [openstack-dev] [neutron] [l2gw] DSVM gates for networking-l2gw

is is just a first rough idea and I haven't tested anything. > > Do you have any other good approach for this??? > > On Mon, Jul 3, 2017 at 5:14 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >> Plan sounds fine. Those interested in ovs backend may build on top, >&

Re: [openstack-dev] [neutron] writable mtu

On Wed, Jul 5, 2017 at 6:43 PM, Ian Wells wrote: > I think I misinterpreted: you'd enable all options and then deal with the > consequences in the backend code which has to implement one the of the > previously listed behaviours? That seems sane to me provided the

Re: [openstack-dev] [neutron] writable mtu

On Wed, Jul 5, 2017 at 6:11 PM, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > On 5 July 2017 at 14:14, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >> Heya, >> >> we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for >> Pike th

[openstack-dev] [neutron] writable mtu

Heya, we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for Pike that allows setting MTU for network on creation. (but not update, as per latest comment from Kevin there) I already see a use case to modify MTU for an existing network (for example, where you enable Jumbo frames for

[openstack-dev] [neutron] no CI meeting tomorrow

It's July 4th, so we'll skip the meeting. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [neutron] [l2gw] DSVM gates for networking-l2gw

Plan sounds fine. Those interested in ovs backend may build on top, but at least laying basic api coverage with a fake/dummy driver is a must for a service plugin project that is serious about integration with Neutron. Ihar On Wed, Jun 14, 2017 at 9:38 PM, Ricardo Noriega De Soto

[openstack-dev] [neutron] no CI and upgrades meetings in next two weeks

Hi all, subject says it all. Also note that upgrades meeting moved to Thursday: https://review.openstack.org/474347 Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [neutron] security group OVO change

To close the loop here, - this also broke heat py3 job (https://launchpad.net/bugs/1698355) - we polished https://review.openstack.org/474575 to fix both vmware-nsx and heat issues - I also posted a patch for oslo.serialization for the bug that triggered MemoryError in heat gate:

[openstack-dev] [neutron][upgrades] no meeting today

And sorry for late notice. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [neutron] pep8 breakage

UPD: in case you wonder if that's fixed, we are waiting for https://review.openstack.org/#/c/471763/ to land. Ihar On 06/07/2017 05:23 AM, Akihiro Motoki wrote: Six 1.10.0 is not the root cause. The root cause is the version bump of pylint (and astroid). Regarding pylint and astroid, I think

Re: [openstack-dev] [stable][kolla][release] Policy regarding backports of gate code

On 06/05/2017 09:42 AM, Michał Jastrzębski wrote: My question is, is it ok to backport gate logic to stable branch? Regular code doesn't change so it might not be considered a feature backport (users won't see a thing). Yes, that's allowed. Stable maintainers are concerned about destabilizing

Re: [openstack-dev] [tc][ptls][all] Potential Queens Goal: Migrate Off Paste

On Fri, Jun 2, 2017 at 1:21 PM, Matt Riedemann wrote: > I don't think the maintenance issue is the prime motivator, it's the fact > paste is in /etc which makes it a config file and therefore an impediment to > smooth upgrades. The more we can move into code, like default

[openstack-dev] no upgrades meeting on May 29th

It's Memorial day in US. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [networking-sfc] pep8 failing

Make sure you have the latest neutron-lib in your tree: neutron-lib==1.6.0 On Tue, May 16, 2017 at 3:05 AM, Vikash Kumar wrote: > Hi Team, > > pep8 is failing in master code. translation hint helpers are removed from > LOG messages. Is this purposefully done ?

[openstack-dev] [neutron] no upgrades meeting tomorrow

Hi, I have some unexpected family obligations for the time slot that just popped up that I can't postpone, so we will need to cancel the meeting. I believe it's also reasonable since we haven't made much progress on action items pointed out during the previous meeting, so let's meet once we have

[openstack-dev] [neutron] no CI or upgrades meetings this week

And no CI meetings in next two weeks after the summit because of no planned attendance from main participants. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [neutron] no upgrades meeting on May 1

Hi, Due to a conflict in my schedule, I need to cancel the meeting this Monday. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Openstack] All Hail our Newest Release Name - OpenStack Rocky

Hi, It would also be nice to actually get an email to vote. I haven't seen one. :) Not that I'm not ok with the name, just saying that it may be worth exploring what happened. Ihar On Fri, Apr 28, 2017 at 3:34 PM Morgan Fainberg wrote: > It would be nice if there

[openstack-dev] [neutron] CI team meeting on Apr 25 canceled

Hi, sorry for late update, but I will not be offline for the time of the meeting, so I guess we will cancel. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [Openstack][Neutron]Why we use secuirity group which only support dispatching whiltelist rules?

All traffic is denied by default. OpenStack security groups API is modeled to reflect what AWS does. You may find your needs better served by fwaas plugin for neutron that is not constrained by AWS compatibility. Ihar On Sun, Apr 23, 2017 at 8:33 PM, 田明明 wrote: > Can

Re: [openstack-dev] Development workflow for bunch of patches

Sometimes it's possible to avoid the stacking, and instead just rely on Depends-On (usually in those cases where patches touch completely different files). In that way, you won't need to restack on each dependency respin. (But you may want to recheck to get fresh results.) Of course it won't work

Re: [openstack-dev] [qa][gate] tempest slow - where do we execute them in gate?

On Mon, Apr 17, 2017 at 9:35 AM, Jordan Pittier wrote: > We don"t run slow tests because the QA team think that they don't bring > enough value to be executed, every time and everywhere. The idea is that if > some specific slow tests are of some interest to some

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

I just saw the plan merged in master: https://review.openstack.org/#/c/451492/ That's cool! Can we also backport the change to Ocata and maybe Newton so that we don't hit the same bug there? The backport is already up: https://review.openstack.org/#/c/456506/ Thanks, Ihar On Mon, Apr 3, 2017 at

[openstack-dev] [qa][gate] tempest slow - where do we execute them in gate?

Hi all, so I tried to inject a failure in a tempest test and was surprised that no gate job failed because of that: https://review.openstack.org/#/c/457102/1 It turned out that the test is not executed because we always ignore all 'slow' tagged test cases:

Re: [openstack-dev] [stable] What's the plan for mitaka-eol?

Yes, please cancel. I don't even see at this point a need for a separate program for the effort. It was applicable before when we dealt with stable gates on daily basis, but it's no longer the case. Ihar On Mon, Apr 10, 2017 at 2:19 PM Matt Riedemann wrote: > There was no

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

boy...@sapwetik.org> wrote: > On Mon, Apr 3, 2017, at 04:33 PM, Ihar Hrachyshka wrote: >> Are we going to keep some job not using the archive, to make sure we >> don't >> break people using packages from LTS? Maybe just periodic/non-voting >> would >> be enou

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

Are we going to keep some job not using the archive, to make sure we don't break people using packages from LTS? Maybe just periodic/non-voting would be enough to keep it working on older packages. On Mon, Apr 3, 2017 at 4:07 PM Clark Boylan wrote: > Hello, > > One of the

Re: [openstack-dev] [neutron] - Adding Miguel Lavalle to neutron-drivers team

On Thu, Mar 30, 2017 at 2:11 PM, Kevin Benton wrote: > Hi, > > I would like to add Miguel Lavalle (mlavalle) to the Neutron drivers team > [1]. It's not completely clear if you seek support here, but in case you do, +1. Ihar

[openstack-dev] [neutron] functional job broken by eventlet 0.20.1

Hi all, FYI we were broken by the new eventlet. The fix is at: https://review.openstack.org/#/c/447817/ Hopefully we can find reviewers in EMEA/APAC time zones to groom and land it. Thanks, Ihar __ OpenStack Development

Re: [openstack-dev] [QA][gate][all] dsvm gate stability and scenario tests

I had some patches to collect more stats about mlocks here: https://review.openstack.org/#/q/topic:collect-mlock-stats-in-gate but they need reviews. Ihar On Fri, Mar 17, 2017 at 5:28 AM Jordan Pittier wrote: > The patch that reduced the number of Tempest Scenarios

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

On Thu, Mar 16, 2017 at 12:00 PM, Doug Hellmann wrote: > Please keep translations for exceptions and other user-facing messages, > for now. To clarify, that means LOG.exception(_LE(...)) should also be cleaned up? The only things that we should leave are messages that

Re: [openstack-dev] [codesearch] how to exclude projects?

/gist.github.com/dianaclarke/1533448ed33232f5c1c348ab57cb884e > [5] https://docs.openstack.org/infra/system-config/codesearch.html > > On Wed, Mar 15, 2017 at 5:06 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> Hi all, >> >> lately I noticed that any search in codesearch t

Re: [openstack-dev] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

g with it. > > Thanks, > Ilya > > 2016-11-26 2:28 GMT+03:00 Ihar Hrachyshka <ihrac...@redhat.com>: >> >> Hi all, >> >> I am looking at >> http://stackalytics.com/?project_type=openstack=neutron-group and I >> see some reviews counted for

[openstack-dev] [codesearch] how to exclude projects?

Hi all, lately I noticed that any search in codesearch triggers duplicate matches because it seems code for lots of projects is stored in openstack/deb- repos, probably used for debian packaging. I would like to be able to exclude the projects from the search by openstack/deb-* pattern. Is it

Re: [openstack-dev] [neutron][gate] functional job busted

.openstack.org/445884 > > > On Wed, Mar 15, 2017 at 10:14 AM, Gorka Eguileor <gegui...@redhat.com> > wrote: >> >> On 14/03, Ihar Hrachyshka wrote: >> > Hi all, >> > >> > the patch that started to produce log index file for logstash [1] and >> >

[openstack-dev] [neutron][gate] functional job busted

Hi all, the patch that started to produce log index file for logstash [1] and the patch that switched metadata proxy to haproxy [2] landed and together busted the functional job because the latter produces log messages with null-bytes inside, while os-log-merger is not resilient against it. If

Re: [openstack-dev] [neutron][networking-l2gw] Unable to create release tag

On Tue, Mar 14, 2017 at 6:04 AM, Jeremy Stanley wrote: > The ACL for that repo doesn't seem to be configured to allow it > (yet): > Probably fallout of neutron stadium exclusion. While it was in the stadium, releases were happening thru openstack/releases machinery. Ihar

Re: [openstack-dev] [neutron]

On Tue, Feb 21, 2017 at 7:03 AM, Roua Touihri wrote: > How can we interconnect two VMs without using a bridge or a switch as an > intermediate. That is, only via a virtual link (e.g. veth or tap). In fact, > I see that when we create an aditional subnet and two ports

Re: [openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

On Fri, Mar 10, 2017 at 6:49 AM, Andrea Frittoli wrote: > - Glance v1 has been deprecated in Newton, so it's deprecated in all > supported releases Glance not maintaining Mitaka branch? Ihar __

Re: [openstack-dev] [neutron] upgrades PTG recap

On Mon, Mar 6, 2017 at 10:50 AM, Morales, Victor wrote: > Regarding this testing, is there a place where it was documented, scripted or > shared? Something that helps to someone else can take a look. And in the > other hand, is there a way to simulate a “fake change”

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

I have a question: why can't operators just switch to en_US to execute services? Another question: what makes log messages so much different from API responses? Couldn't you make the same argument that it's easier to find a reason for a request failure if the error message is in English? Should

[openstack-dev] [neutron] upgrades PTG recap

Hi all, This is a report on upgrades related topics discussed during PTG in Atlanta. A general PTG report from PTL can be found at: http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html Topics discussed: 1. OVO progress; 2. running mixed server versions; 3.

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

With https://review.openstack.org/#/c/437699/ in, stadium projects will no longer have any other option but to follow the common schedule. That change is new for Pike+ so we may still see some issues with Ocata release process. Ihar On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang

Re: [openstack-dev] [requirements][neutron] bot bumping patches off gate queue

01, 2017 at 07:49:21AM -0800, Ihar Hrachyshka wrote: >> On Wed, Feb 1, 2017 at 7:42 AM, Armando M. <arma...@gmail.com> wrote: >> > >> > >> > On 1 February 2017 at 07:29, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >> >> >&g

Re: [openstack-dev] [ironic] state of the stable/mitaka branches

On Thu, Mar 2, 2017 at 8:13 AM, Pavlo Shchelokovskyy wrote: > I'm also kind of wondering what the grenade job in stable/newton will test > after mitaka EOL? upgrade from mitaka-eol tag to stable/newton branch? Then > even that might be affected if devstack-gate +

Re: [openstack-dev] [ironic] state of the stable/mitaka branches

with constraints in place! Ihar On Wed, Mar 1, 2017 at 12:34 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-03-01 11:36:47 -0800 (-0800), Ihar Hrachyshka wrote: >> On Wed, Mar 1, 2017 at 11:15 AM, Pavlo Shchelokovskyy >> <pshchelokovs...@mirantis.com> wro

Re: [openstack-dev] [ironic] state of the stable/mitaka branches

On Wed, Mar 1, 2017 at 11:15 AM, Pavlo Shchelokovskyy wrote: > With all the above, the question is should we really fix the gates for the > mitaka branch now? According to OpenStack release page [1] the Mitaka > release will reach end-of-life on April 10, 2017. Yes

[openstack-dev] [neutron] no upgrades meeting today

Hi, Sorry for short notice but I figured some of us just met on PTG and where still traveling back in last several days and would appreciate getting the hour back to settle pending post PTG items. This week I will work with PTG participants on producing a detailed report on the event where it

Re: [openstack-dev] [neutron] - approximate schedule for PTG

Thanks a lot for the ical, it's really helpful, adding some structure to the PTG anarchy. Ihar On Sat, Feb 18, 2017 at 12:42 PM, Kevin Benton wrote: > Hi All, > > > Here is a rough outline of the order in which I want to cover the items: >

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

+1. On Fri, Feb 17, 2017 at 11:18 AM, Kevin Benton wrote: > Hi all, > > I'm organizing a Neutron social event for Thursday evening in Atlanta > somewhere near the venue for dinner/drinks. If you're interested, please > reply to this email with a "+1" so I can get a general

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

Another potentially interesting devstack service that may help us to understand our memory usage is peakmem_tracker. At this point, it's not enabled anywhere. I proposed devstack-gate patch to enable it at: https://review.openstack.org/#/c/434511/ On Wed, Feb 15, 2017 at 12:38 PM, Ihar Hrachyshka

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

Another potentially relevant info is, we saw before that oom-killer is triggered while 8gb of swap are barely used. This behavior is hard to explain, since we set kernel swappiness sysctl knob to 30: https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L432 (and any value

Re: [openstack-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

On Fri, Feb 10, 2017 at 2:48 PM, Clark Boylan <cboy...@sapwetik.org> wrote: > On Fri, Feb 10, 2017, at 10:54 AM, Ihar Hrachyshka wrote: >> Oh nice, I haven't seen that. It does give (virtualized) CPU model >> types. I don't see a clear correlation between models and >>

Re: [openstack-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

the overcommit/system load for each hypervisor affected. But I assume we don't have access to that info, right? Ihar On Fri, Feb 10, 2017 at 8:39 AM, Clark Boylan <cboy...@sapwetik.org> wrote: > On Fri, Feb 10, 2017, at 08:21 AM, Morales, Victor wrote: >> >> On 2/9/17, 10:59 PM, &qu

[openstack-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

Hi all, I noticed lately a number of job failures in neutron gate that all result in job timeouts. I describe gate-tempest-dsvm-neutron-dvr-ubuntu-xenial job below, though I see timeouts happening in other jobs too. The failure mode is all operations, ./stack.sh and each tempest test take

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

Has the liberty-eol cleanup happened? Because I still see stable/liberty branch in openstack/neutron repo, which gets in the way of some logic around proactive backports: https://review.openstack.org/#/c/427936/4/bugs-fixed-since.py@75, and I see backports proposed for the branch that is no longer

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

On Thu, Feb 2, 2017 at 7:44 AM, Matthew Treinish wrote: > Yeah, I'm curious about this too, there seems to be a big jump in Newton for > most of the project. It might not a be a single common cause between them, but > I'd be curious to know what's going on there. Both Matt

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

The BadStatusLine error is well known: https://bugs.launchpad.net/nova/+bug/1630664 Now, it doesn't mean that the root cause of the error message is the same, and it may as well be that lowering the number of workers triggered it. All I am saying is we saw that error in the past. Ihar On Thu,

Re: [openstack-dev] [requirements][neutron] bot bumping patches off gate queue

On Wed, Feb 1, 2017 at 7:42 AM, Armando M. <arma...@gmail.com> wrote: > > > On 1 February 2017 at 07:29, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >> Hi all, >> >> lately I see the requirements bot proposing new rebases for its >> patches (

[openstack-dev] [requirements][neutron] bot bumping patches off gate queue

Hi all, lately I see the requirements bot proposing new rebases for its patches (and bumping existing patch sets from the gate queue) every second hour, at least for Neutron [1], which makes it impossible to land the patches, and which only makes gate pre-release situation worse. On top of that,

[openstack-dev] [elastic-recheck] Miscellaneous questions of potential Neutron interest

Hi all, we were looking at expanding usage of elastic-recheck in Neutron, and several questions popped up that we would like to ask. 1. Are all jobs eligible for coverage with queries? The reason we ask is that there was some disagreement on whether all job runs are eligible, or e.g. gate queue

Re: [openstack-dev] [neutron] [ovo] unhashable type error

Looking at the code, I don't see a clear case to even use set() type there. A list would seem to work just fine. Should we try to convert to using lists there? Nevertheless, we can look into extending the object base class for hashing. I wonder though if it's something to tackle in Neutron scope.

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

On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday wrote: > Thanks for bringing this up! > > I was assuming that from Ocata everyone should switch from usage 'old' > TunnelTypeDriver to updated one. I am not sure. We haven't marked the 'old' one with any deprecation

Re: [openstack-dev] [Neutron] PTL Candidacy

On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor wrote: > Given the latest issues related with the memory consumption[1] in CI jobs, > I’m just wondering if you have a plan to deal and/or improve it in Neutron. AFAIU the root cause is still not clear, and we don't

Re: [openstack-dev] [neutron] PTL candidacy

On Wed, Jan 25, 2017 at 7:45 AM, Kevin Benton wrote: > LBaaS is a little special since Octavia will have it's own API endpoint > completely that they will evolve on their own. The other spun-out projects > (e.g. VPNaaS) will have the API defined in neutron-lib[1]. In a way,

Re: [openstack-dev] [neutron] PTL candidacy

Catching up on the thread, lots of good thoughts. I don't think there is disagreement here around how Networking API should evolve in terms of vendor extensions. As Kevin suggested, we don't want to advertise API extensibility without Neutron team supervision. One of the reasons behind current

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

Hi Anna, I see that as part of [1], we changed the argument type for the $subj function from session to context. Sadly, it turns out we still call it with a session from the 'old' TunnelTypeDriver. I suspect the same issue may affect allocate_fully_specified_segment. I assume that means all

Re: [openstack-dev] [Neutron] PTL Candidacy

On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote: >> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton <ke...@benton.pub> wrote: >> > I'm on board with getting visibility into

Re: [openstack-dev] [Neutron] PTL Candidacy

On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton wrote: > I'm on board with getting visibility into the drivers with improvements to > driverlog, etc. What I'm uncertain of is providing much in the lines of > 'validation'. Core reviewers don't frequently have access to the

[openstack-dev] [neutron] PTL candidacy

Hi team, I would like to propose my PTL candidacy for Pike. Some of you already know me. If not, here is my brief OpenStack bio. I joined the community back in Havana, and managed to stick around till now. During the time, I fit several project roles like serving as a Neutron liaison of

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

An alternative could also be, for Newton and earlier, to release a note saying that operators should not run the code against ENFORCING galera mode. What are the reasons to enable that mode in OpenStack scope that would not allow operators to live without it for another cycle? Ihar On Mon, Jan

Re: [openstack-dev] [Neutron] Using neutron lib plugin constants

On Tue, Dec 27, 2016 at 12:03 AM, Gary Kotton wrote: > The following decomposed plugins are not gating: > > - openstack/networking-brocade > > (please see

[openstack-dev] [neutron] killing non-dvr ovs scenario job

Hi all, currently, we have three experimental scenario jobs: 1. linuxbridge single node 2. ovs non-dvr single node 3. ovs dvr multi node I don’t see why we should at this point care about the 2nd one. I think we decided some time ago that the future we see is most if not all tempest jobs

[openstack-dev] [neutron][dragonflow] advertise_mtu option to be removed

Hi all, I plan to remove the deprecated advertise_mtu option with https://review.openstack.org/413567 I checked projects still using the option, and the only project to be hit by the change seems to be dragonflow. I proposed a fix at: https://review.openstack.org/414047 Please make

  1   2   3   4   5   6   7   8   9   10   >