22:00:29 #startmeeting neutron_drivers 22:00:30 Meeting started Thu Jul 6 22:00:29 2017 UTC and is due to finish in 60 minutes. The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:31 o/ 22:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:34 The meeting name has been set to 'neutron_drivers' 22:00:35 that’s abrupt 22:00:38 :) 22:00:44 not even hello 22:00:47 hello 22:00:48 hi 22:00:50 o/ 22:00:51 too late 22:00:54 * amuller is lurking 22:01:23 ok, i want to look at a few things from the list here 22:01:25 #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 22:01:40 #link https://bugs.launchpad.net/neutron/+bug/1627987 22:01:41 Launchpad bug 1627987 in neutron "[RFE] SR-IOV accelerated OVS integration" [Wishlist,Triaged] - Assigned to Moshe Levi (moshele) 22:02:03 this one seems easy enough to me 22:02:08 kevinbenton: I looked at it and reviewed the patches just now 22:02:36 not sure I see much of an RFE material in the sense that this feels like a minimal enhnancement 22:02:40 am I missing something? 22:03:00 nope 22:03:05 that's why we can just approve 22:03:14 pretty well contained 22:03:14 and skip spec 22:03:17 well, I’d argue we should just remove the rfe tag :) 22:03:27 though 22:04:00 this reminds of https://bugs.launchpad.net/neutron/+bug/1506127 22:04:01 Launchpad bug 1506127 in neutron "enable vhost-user support with neutron ovs agent" [Wishlist,Fix released] - Assigned to Terry Wilson (otherwiseguy) 22:04:03 which was an RFE 22:05:02 but it brought in a user-facing change and some contention in relation to the networking-ovs-dpdk project 22:05:29 nope 22:05:43 seems to just be an agent flag to change info in vif details to nova 22:05:54 nope to what? 22:06:03 what is the difference between removing rfe tag and approving rfe without requesting spec? 22:06:10 not user facing or anything like that 22:06:14 the change would be simple 22:06:23 amotoki: none, just ignore me :) 22:06:38 kevinbenton: agreed, but won’t we need to add a new value to https://review.openstack.org/#/c/237264/19/neutron/plugins/ml2/drivers/openvswitch/agent/common/config.py@56? 22:06:47 sorry I meant 22:06:51 https://review.openstack.org/#/c/237264/19/neutron/plugins/ml2/drivers/openvswitch/agent/common/config.py@52 22:07:58 (sorry, internet is really slow) 22:08:45 armax: what was that a link to? 22:08:49 amuller: you mean https://review.openstack.org/#/c/237264/19/neutron/plugins/ml2/drivers/openvswitch/agent/common/constants.py ? 22:09:00 amuller: sorry 22:09:10 :) 22:09:14 armax: ^ 22:09:18 no 22:09:44 I meant the datapath_type config option agent side 22:09:50 ah i see. datapath_type 22:09:59 the RFE states 22:10:11 that a new hw_acc value would be used 22:10:17 yeah, so an operator option is needed then 22:10:18 to make sure we can do a direct binding 22:10:41 kevinbenton: that’s what I thought, and hence I posted my question in the review 22:10:42 is there a problem we are trying to figure out here? 22:10:47 none 22:10:50 or can we move to review 22:10:50 as far as I can see 22:10:53 yeah 22:10:57 ok 22:11:12 so long as we document the whole thing etc we should be good 22:11:28 #link https://bugs.launchpad.net/neutron/+bug/1667877 22:11:29 Launchpad bug 1667877 in neutron "[RFE] Allow DVR for E/W while leaving N/S centralized" [Wishlist,Triaged] 22:12:27 armax has a suggestion in there about an agent config mode to make it not do offload 22:12:52 kevinbenton: right now we have a config option used for L3 agents 22:12:54 armax: well i thought you did 22:13:10 whose values are ‘dvr’, ‘dvr_snat’, and ‘legacy’ 22:13:19 I went thorugh the bug again. Didn't see any change 22:13:25 armax: didn't you leave a comment somewhere? 22:13:28 we can add a new one ‘dvr_no_dnat’ 22:13:46 armax: yeah, that would work for me 22:14:06 this way FIP requests will always go to ‘dvr_snat’ nodes 22:14:09 dvr_no_nat? 22:14:34 amotoki: yeah, that would be set on the compute node l3 agents 22:14:50 and then they would do no north/south translation 22:15:05 which would be left to a central node at that point 22:15:20 and that woul;d by dnat, right? 22:15:28 kevinbenton: right, code agent side would need to be refactored a bit to avoid some of the spaghetti mess 22:15:46 armax: didn't you comment this somewhere or am i going crazy? 22:15:55 (other than above in this meeting) 22:16:02 kevinbenton: perhaps I was 22:16:08 kevinbenton: do you want me to repost? 22:16:23 yeah, put it in the bug if you can 22:16:28 yes, sir 22:16:50 Swami commented this mroning during L3 team meeting he is ready to start working on this 22:17:02 does anyone have any objections then to having this option to basically disable the north-south capabilities on a compute node l3 agent? 22:17:05 so any guidance we can leave in the rfe will be helpful 22:17:10 which would then force them back to the central agent? 22:17:17 mlavalle: OK 22:17:30 I am ok with it 22:17:47 okay 22:18:05 kevinbenton: let me comment and if you’re happy with it then you can rfe-approve 22:18:18 armax: ok 22:18:32 the only difference between the initial approach 22:18:37 and this one being discussed right now 22:18:51 is that the centralized DNAT is always config driven 22:19:03 not based on some ‘circumstantial’ condition 22:19:24 which is based on agent health 22:19:59 so operator chooses to centralize DNAT or not based solely on cofig, right? 22:20:00 and also the fact that we don’t have yet another config option a user must wrap her head around 22:20:01 yes 22:20:32 any l3 agents without external network access would have this option set 22:20:32 we need to understand what happens in clouds with a mix of agents where 22:21:00 ok 22:21:04 a bunch are dvr (computes), dvr_snat (network nodes) and dvr_no_dnat (compute) 22:21:26 armax: shouldn't be anything too special there 22:21:37 just whatever was on no_dnat would be centralized 22:21:41 while other stuff remains the same 22:21:42 when a VM with FIP migrates from a compute running in DVR mode to one running in dvr_no_dnat what happens? 22:21:54 I still believe this is a can of worms 22:22:01 but hey, you want the rope 22:22:04 ... 22:22:07 have at it 22:22:07 the same thing as happens now 22:22:14 just a different destination :) 22:22:28 kevinbenton: let’s hope so :) 22:22:48 armax: ok, did you comment yet? 22:22:51 no 22:23:02 do I have to now? I can’t multitask :) 22:23:08 oh, no 22:23:08 if I comment, I can’t talk to you 22:23:12 i just thought you meant right now 22:23:20 let's move on for now then 22:23:27 I’ll ping you as soon as I do 22:23:42 #link https://bugs.launchpad.net/neutron/+bug/1669630 22:23:43 Launchpad bug 1669630 in neutron "Network RBAC acceptance workflow" [Wishlist,Triaged] 22:24:24 https://bugs.launchpad.net/neutron/+bug/1669630 22:25:07 this would need a spec, wouldn’t it? 22:25:21 we need new CLI, docs etc, the whole lot 22:25:28 no? 22:26:53 * armax wonders how many bauds kevinbenton is running on 22:27:20 i think a spec is a good start 22:27:41 yeah, it does enatil cli, api change, docs, etc 22:27:48 entail^^^^ 22:29:13 #chair armax 22:29:14 Current chairs: armax kevinbenton 22:29:43 (bad connection, will read backlog later, sorry everyone!) 22:30:27 kevinbenton: we were talking about a spec as a next step 22:30:48 given that it entails cli, api change, docs 22:30:56 that's as much as you lost 22:31:49 maybe we lost him again 22:32:18 yeah 22:33:20 mlavalle: I suppose we can comment on the bug report for him 22:33:27 yeah 22:33:36 let's do that 22:33:48 no we have the option to continue to scrub the list or call the meeting off 22:34:41 #chair armax 22:34:42 Current chairs: armax kevinbenton 22:34:46 did that make it through? 22:34:50 yay! 22:34:53 kevinbenton: yes it did 22:34:55 yes it did 22:35:06 i'm okay with just ending the meeting for now if you folks want 22:35:13 mlavalle, amotoki thoughts? 22:35:19 ok with me 22:35:21 i got the two burning ones blocking people 22:35:29 burning? 22:35:32 okay 22:35:33 this one 22:35:33 https://bugs.launchpad.net/neutron/+bug/1669630 22:35:34 Launchpad bug 1669630 in neutron "Network RBAC acceptance workflow" [Wishlist,Triaged] 22:35:35 burning rfe's 22:35:40 armax: ^^^^ 22:35:44 looks like it has a contributor that i can help 22:35:51 I hardly thought they were lukewarm 22:36:01 but sure 22:36:21 let’s wrap this up so that I can comment on these and move them through the pipeline 22:36:27 sounds good? 22:36:30 sounds good 22:36:36 sounds good to me 22:36:44 did anyone have any other high priority things? 22:36:48 before we end? 22:36:51 yeah 22:36:56 anything anyone? 22:36:56 I will make sure Swami gets the latest news about the fip rfe 22:37:06 mlavalle: aye 22:37:11 mlavalle: send him a carrier pigeon 22:37:17 LOL 22:37:18 or a horse’s head 22:37:23 your choice 22:37:34 amotoki: anything you want to discuss? 22:37:37 ROFL 22:37:59 kevinbenton: no priority item from me. 22:38:16 ok 22:38:19 ok 22:38:25 let's end then and chat next week 22:38:29 thanks everyone 22:38:33 kevinbenton: do you have spare bauds to close the meeting? 22:38:37 #endmeeting