14:00:00 #startmeeting networking 14:00:01 Meeting started Tue Mar 28 14:00:00 2017 UTC and is due to finish in 60 minutes. The chair is jlibosva. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:02 o/ 14:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:04 The meeting name has been set to 'networking' 14:00:10 Hello everybody 14:00:15 hi 14:00:20 hi 14:00:32 howdy 14:00:33 o/ 14:00:38 #topic Announcements 14:00:46 o/ 14:01:01 14:00:00 jlibosva | #startmeeting networking 14:01:06 jlibosva: i envy your punctuality :) 14:01:10 I don't remember this being announced anywhere - so native ovsdb interface has been pulled from Neutron and has its own repo now 14:01:16 hi 14:01:23 dasm: :D I actually see it 59:59 :) 14:01:23 yay 14:01:30 #link http://git.openstack.org/cgit/openstack/ovsdbapp 14:01:44 o/ 14:01:46 Neutron still uses in-tree code for interface but there is already a WIP: https://review.openstack.org/#/c/438087/ 14:01:48 hi 14:02:09 hi 14:02:09 jlibosva: what was the plan? do we switch right away or let it bake? 14:02:43 hi 14:02:47 ihrachys: I think the plan is to switch during pike, maybe pike-1. Don't remember. I should be able to find it in PTG summaries 14:03:06 pike1 would be great, though it's around the corner 14:03:12 3 weeks? 14:03:28 yeah, around that time. 14:03:31 Apr 10 - Apr 14 == Pike1 14:03:47 so 2 weeks 14:03:57 This is neutron stadium, right? 14:04:02 I think it would make sense to switch early as currently we need to maintain 'almost' same thing in two places 14:04:02 otherwiseguy: are there obstacles to get the patch not WIP? 14:04:05 hichihara: yes, it is 14:04:07 hichihara: yes 14:04:22 ihrachys: I don't think he's online :) 14:04:23 hi 14:04:23 I see 14:04:56 ok nevermind 14:04:57 #action jlibosva to sync with otherwiseguy on the plan of ovsdbapp switch 14:05:43 This has been announced last week but for those who missed it: post mortem Ocata got merged: https://review.openstack.org/#/c/425990/ 14:06:25 Boston summit Forum sessions should be announced on April 10, deadline for proposals is April 2. 14:07:01 Anything else to announce? 14:07:03 what's the fate of Monday meeting? I saw revert from armax: https://review.openstack.org/#/c/448886/ but it never got merged. 14:07:40 ihrachys: IIRC last week it was agreed to move monday 14:07:54 ihrachys: http://lists.openstack.org/pipermail/openstack-dev/2017-March/114527.html 14:08:01 > Proposed revert in [1] to give time and opportunity to comment on whether 14:08:02 the new time works for the majority of folks. 14:08:20 but i didn't see any follow-up to this 14:08:22 jlibosva: and then armax said it was not properly discussed and proposed revert 14:08:38 that's a bit of a mess :) 14:10:32 so maybe the revert patch would be the best place to discuss 14:10:40 as I think lot of ppl who attend monday are not here 14:10:52 the new earlier times are definitely better for me personally 14:11:07 I can't attend neither so I deffer :) 14:11:10 will look out for objections from others 14:11:41 maybe new time will affect East-Asia ;) 14:12:01 I don't think we will resolve it here, just wanted folks to be aware 14:12:19 good 14:12:27 I agree 14:12:37 if there is nothing else to announce we shall move on 14:12:45 #topic Blueprints 14:12:50 #link https://launchpad.net/neutron/+milestone/pike-1 14:12:51 it does :) 14:13:07 So as mentioned, we're 2 weeks from p1 14:14:17 Does anybody has anything to raise here regarding to work on a blueprint? 14:14:23 any blockers or anything? 14:15:41 seems everything goes smooth then 14:15:46 Any movement on approval of https://bugs.launchpad.net/neutron/+bug/1667329 ? 14:15:46 Launchpad bug 1667329 in neutron "[RFE] Floating IP Subnets on Routed Provider Networks" [Undecided,Triaged] 14:15:53 I was away last week 14:16:18 john-davidge: that's a question to drivers team, but as you can see, there is nothing in LP, which means there was no discussion 14:16:30 the prev drivers meeting was cancelled I believe because of the meeting shift mess 14:16:55 and I can't find it mentioned in drivers meeting logs 14:17:02 ihrachys: Ok, hopefully the new drivers meeting time will stick so I can finally attend :) 14:17:18 people are advised to comment in the bug if they have thoughts, and ofc join the next drivers meeting. 14:18:20 maybe there could be a section in driver's meeting wiki to put a note/question when someone can't attend the meeting due to TZ 14:18:50 jlibosva : +1 14:19:23 LP is the place where we track all info related to RFE bugs 14:20:25 ihrachys: so if someone writes "Any news?" to LP, it'll get attention? 14:21:19 no, RFEs get attention in order 14:21:49 ofc you can vouch for special attention for specific bug, but that will need some personal communication :) 14:23:24 alright 14:23:27 let's move on 14:23:34 #topic Bugs and gate failures 14:24:01 I was the deputy this week 14:24:02 I see a spike in all jobs that happened yesterday. Given that it's in all jobs I assume some infra issue. I haven't seen any email nor bug report though. 14:24:22 ok, let's do the deputy first 14:24:32 ok 14:24:48 nothing major happened, business as usual 14:25:01 I marked some bugs as needs-attention where I saw fit 14:25:12 also cleaned up old needs-attention tagged bugs 14:25:18 the resulting list is https://bugs.launchpad.net/neutron/+bugs?field.tag=needs-attention 14:26:02 most of those still probably need some discussion, f.e. in https://bugs.launchpad.net/neutron/+bug/1585907 it's not clear the intended behaviour of availability API 14:26:02 Launchpad bug 1585907 in neutron "'used_ips' field of 'net-ip-availability-list' command increased by 1 when subnet added into router,In fact, Before subnet added into the router ,'total_ips' of network does not contain 'gateway_ip'." [Medium,In progress] - Assigned to QunyingRan (ran-qunying) 14:26:27 others, like https://bugs.launchpad.net/neutron/+bug/1674889, affect other projects (this one is OVN) and will probably need champions from those communities 14:26:28 Launchpad bug 1674889 in neutron "Fix get_schema_helper bug in some case" [Undecided,Incomplete] - Assigned to Dong Jun (dongj) 14:26:51 I don't think there is a huge reason to go through each of them; instead I will ask folks to eyeball the list and contribute to discussions where due 14:27:21 14:28:34 ihrachys: good, thanks for report 14:29:33 as per gate failure I mentioned earlier - does anybody have any information of what happened? was that an infra issue? 14:29:48 the curve went down, so we're good by now 14:30:07 no idea, I probably missed it while sleeping ;) 14:30:33 :) 14:30:54 alright, we have a special price here which is a bug deputy role for this week 14:30:59 any volunteers? 14:31:54 i can volunteer, haven't done it for a bit 14:32:11 \o/ \o/ go go haleyb go go \o/ \o/ 14:32:23 haleyb: yay! thanks 14:32:42 haleyb: now I feel like my car-selling skills improved too :) 14:32:59 #info haleyb is a bug deputy for week of Mar 27 14:33:01 i'll buy the car too :) 14:33:18 jlibosva: see? he hasn't even asked the price 14:33:20 I can be bug dupty next week 14:33:22 congrats on the new car haleyb 14:33:23 :) 14:33:27 ihrachys: the price was the role 14:33:38 * haleyb assumes it's an older ferarri 14:33:39 amotoki: thanks! 14:33:48 haleyb: Congrats! Now follow me to the finance department... 14:33:54 lol 14:34:01 #info amotoki is a bug deputy for a week of Apr 3 14:34:08 that was gold john-davidge 14:34:47 ihrachys: So are our interest rates! 1lb of gold per day. 14:36:04 if there is nothing else to discuss beside haleyb 14:36:08 's car 14:36:11 we can jump to docs 14:36:14 #topic Docs 14:36:19 john-davidge: yo 14:36:31 jlibosva: yo yo 14:36:50 jlibosva: Nothing significant from me actually, just returned from a week of PTO 14:37:03 oh, so I hope you had a good time :) 14:37:13 jlibosva: I notice lots of OSC conversion patches for review thought, so thanks all for those 14:37:27 jlibosva: Thank you, I did :) 14:37:40 john-davidge: so we can move on, right? 14:37:51 jlibosva: Yes, go ahead 14:37:53 #topic Transition to OSC 14:37:57 amotoki: hi, do you have anything? 14:38:28 nothing to report. the progress is steady 14:38:43 amotoki: cool, thanks 14:38:46 that's fast today :D 14:38:52 #topic Neutron-lib 14:39:06 boden: hi :) 14:39:14 hi 14:39:25 boden: any updates to neutron-lib 14:39:27 ? 14:40:14 we are still working through the rehoming patches for neutron core API resources and api attributes that I mentioned last week 14:40:31 hopefully we can have those in better shape by next week 14:40:33 boden: do we plan a release in next days? because I really want one to move forward with https://review.openstack.org/#/c/448671/ and https://review.openstack.org/#/c/446730/ (that will allow to kill translation markers in trees) 14:40:57 I need a release with 1st included (it's already merged) to proceed with cleanup 14:41:21 and then we will be able to land the 2nd and fix periodic jobs and finally release another one with no-log-translation enforced 14:41:53 ihrachys: it’ll be more than a few days for the patches I mentioned I think, but I don’t have any objections to a release in the meatime 14:42:16 obviously we need to make sure the periodic jobs are green, etc.. 14:42:21 sure 14:42:39 dasm: could you follow up on it? or should I post request myself? 14:42:55 ihrachys: i'll prepare a release 14:42:59 tnx! 14:43:23 also 14:43:36 there are a few patches in neutron that consume lib updates that could use review 14:43:40 boden: ihrachys fyi, currently there are 3 jobs failing. i'll look into that and will report back to you 14:43:47 boden: do you have links handy? 14:43:49 dasm: ack 14:44:01 #link https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22+project:openstack/neutron 14:44:35 boden: thanks! 14:44:36 the patches to use portbindings and providernet API defs from lib have been out there for awhile 14:44:43 please have a looksee if you get a few min :) 14:44:49 will do 14:45:04 boden: Why do some patches have branch name "bp/neutron-lib-networking-ovn"? 14:45:20 hichihara: technically they are part of that effort 14:45:29 rehoming dependencies ovn has on neutron 14:45:51 boden: I got it 14:45:58 I was trying to track the related patches in the BP, but if that’s just confusing it doesn’t matter to me 14:46:37 If it gets confusing using that topic, just let me know and I’ll stop 14:46:57 boden: thanks for updates, I hope more cores will jump on the api-def patches 14:47:00 I don’t have much else to add, unless others do 14:47:05 anything else neutron-lib related? 14:47:07 ok 14:47:14 boden: the topic is useful. keep it up 14:47:18 let's move on 14:47:21 #Disable IPv6 forwarding on backup HA routers 14:47:30 the stage is yours dalvarez :) 14:47:38 jlibosva, thanks! 14:47:40 boden: Don't mind my question 14:47:48 jlibosva: topic change? 14:47:51 jlibosva: topic missing 14:47:54 whoops 14:47:57 dasm: ihrachys thanks :) 14:48:00 #topic Disable IPv6 forwarding on backup HA routers 14:48:19 https://review.openstack.org/#/c/442518/ 14:48:29 #link https://review.openstack.org/#/c/442518/ 14:48:38 is it just a request for review? 14:48:52 i wanted to bring this up in order to move the patch forward 14:49:24 oh ok. you could probably just ping some of us in irc and get the same. :) 14:49:40 dalvarez: do you want to mention the issue you saw yesterday wrt /proc entry, etc 14:49:41 should we aim the bug to p1 then? 14:49:44 oh i was about to elaborate a bit further, but essentialy 14:50:01 what I want to bring up is that if we go ahead with this bug we'll make us dependent on the l3 agent for IPv6 failover 14:50:25 haleyb, i actually found out that this is a bug on 3.10 kernels so procfs entry should still be there 14:50:59 ihrachys, yeah thanks i have done it but it doesn't seem to get traction... I just wanted to know what you guys think about making us dependent on the l3-agent running for Ipv6 failover 14:51:22 dalvarez: oh you mean that data plane correctness will depend on l3 agent disabling forwarding on failover? 14:51:30 ihrachys, that's it 14:51:48 ihrachys, and actually re-enabling it when an instance transitions from backup to master 14:53:09 we already have some bits in the agent that work in sync with keepalived 14:53:09 f.e. we send gARPs for it 14:53:29 but the thing is that I can't think of any other solutions since, right now, ipv6 forwarding is enabled by default on namespaces and that makes it joining different multicast groups and thus responding to queries coming from the outside 14:53:36 here https://github.com/openstack/neutron/blob/master/neutron/agent/l3/keepalived_state_change.py#L87 14:53:56 it would be either keepalived doing it, or smth on top 14:54:11 if keepalived doesn't, I don't see an alternative 14:54:15 ihrachys, ack so you think it's not a big issue to depend on l3 agent running, right? 14:54:18 ack 14:54:28 i think it's the kernel joining the mcast groups, right? 14:54:45 haleyb, correct. that happens automatically when ipv6 forwarding is enabled 14:54:53 and those are left when disabled 14:54:58 dalvarez: I don't see a big difference architecturally between l3 agent doing it or a daemon under its control 14:55:22 ihrachys, the daemon is monitorized by the agent 14:55:29 the only issue I see is additional complexity in the agent, and the fact that it may not react to failover as quick as keepalived could 14:56:05 but that sounds like keepalived bug/missing feature we try to work around 14:56:16 which is not news for the implementation :) [see the garp] 14:56:16 dalvarez: keepalived is moving the LLA, right? 14:56:23 haleyb, it is 14:56:42 then maybe when it moves, forwarding moves? 14:56:55 ihrachys, yes... i think the reaction time is not a big deal here since those changes shouldn't occur too often and the only drawback may be disrupting the traffic until l3 agent reacts 14:57:05 btw, if we run out of time can move to other channel, or continue in L3 meeting thursday 14:57:09 haleyb, that's something that keepalived doesn't do I guess 14:57:26 haleyb, yes! 14:57:31 ihrachys, haleyb thanks a lot guys :) 14:57:41 good 14:57:43 i think we're good to go if we aim for p1 with this bug 14:57:47 we're almost out of time 14:57:59 is there any other quick thing to discuss? 14:58:06 or we could get 2 minutes back 14:58:08 just a shout out for jlibosva chairing those meetings for us. kudos! 14:58:14 \o/ 14:58:16 lol 14:58:30 jlibosva, brought some beers? 14:58:32 ihrachys: and you're always here anyway :D 14:58:36 which is good! 14:58:48 that was part of the plan of deceit 14:58:56 jlibosva: yeah, thanks for chairing this meeting 14:58:56 :) 14:59:09 ok, thanks all for showing up 14:59:15 #endmeeting