18:32:08 #startmeeting networking_fwaas 18:32:09 Meeting started Wed Mar 16 18:32:08 2016 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:32:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:32:13 The meeting name has been set to 'networking_fwaas' 18:32:22 hi sc68cal, all 18:32:31 #chair SridarK 18:32:32 Current chairs: SridarK sc68cal 18:32:34 #chair xgerman 18:32:35 Current chairs: SridarK sc68cal xgerman 18:32:44 Hi All 18:33:33 Today I think is mostly just working on the actual release of mitaka 18:34:38 sc68cal: i think there is nothing pending w.r.t the release 18:34:47 agreed 18:36:14 so I think once the release happens, hopefully capacity will open back up and development can resume on the v2 api 18:36:46 sc68cal: yes hope so too 18:37:11 i guess the branch should open up for Newton real soon ? 18:39:35 I would assume so. I think part of the problem is that none of the cores have done a release, it's always been handled for us, by either mestery or ihar 18:40:07 ok 18:40:40 It appears we have a stable/mitaka branch cut 18:41:15 so, I assume that we're open for newton based on that fact 18:41:18 ok cool 18:41:45 In terms of the N release, we should get #link https://review.openstack.org/#/c/278863/ for observer hierarchy 18:42:11 the submitter it seems also got sucked into other things 18:42:36 but will be good to close it out early as a long standing thing 18:43:29 yes, that patch is very important. SridarK or jwarendt - do you think you guys could push revisions if the submitter does not reappear? 18:43:55 sc68cal: yes will do so 18:44:53 Yes 18:45:01 o/ 18:45:36 jwarendt: i think u have been looking at the neutron (L3Agent) side of things 18:47:22 Correct, but the agent.py on neutron side has direct calls right now into FWaaS class - instead of decoupled observer. I have made the lookup dynamic, but observer would be much better. 18:48:08 jwarendt: yes agreed 18:48:35 i will reach out the submitter again to check on his availability and we can move forward accordingly 18:48:50 *reach out to the .. 18:49:00 Plus for some reason there is a router_add but no router_delete on L3 agent side; hoping observer will properly listen to delete so fwaas can change state appropriately. 18:49:53 jwarendt: yes the router delete - earlier there was not much to do as the iptables will get cleaned out 18:50:14 well, we still need to remove it from the DB 18:50:17 jwarendt: now with router insertion things are a bit different - but yes that is a clean up 18:51:10 xgerman: yes i believe we have Foreign Key constraint 18:51:28 but let me look at that code again 18:51:31 ok, that would work 18:51:42 from the agent side of the world 18:52:16 Okay good i think we are all on the same page 18:53:35 An update blocks if router in use, but can delete the router underneath the FWaaS without the FWaaS changing from ACTIVE state - even if the DB cleans up. 18:54:32 Observers will help straighten that out. 18:54:42 jwarendt: yes agreed 18:54:49 +1 18:56:07 cool 18:56:22 one other patch i wanted to discuss: #link https://review.openstack.org/#/c/291822/ 18:56:22 The other thing I wanted to bring up, is the state of 3rd party drivers 18:56:36 sc68cal: u read my mind :-) 18:56:38 :) 18:56:55 Now - macafee's driver, they actually have a CI job that passes reliably 18:57:09 but the code itself needs a maintainer - to fix pylint issues 18:57:26 sc68cal: on this, i reached out to intel - there is some churn in ownership of McAfee - so things are in a bit of flux 18:57:55 I asked if they could take care of the pylint issues - which was one of ur main concerns 18:58:02 yep 18:58:26 hopefully they can help with transtioning this to the new maintainers 18:58:27 If they fix the issues, then that would be a positive step 18:59:04 but what do we do about drivers like varmor and cisco? 18:59:11 we can consider giving some time until they sort out the maintainers - i will stay in touch with intel folks to help transition 18:59:14 does the cisco driver have a 3rd party CI? 18:59:36 sc68cal: yes but i will be first to admit - the reliability is a bit suspect 18:59:53 I haven't seen it report on a recent patch. 18:59:57 or any, really. 19:00:05 sc68cal: i think we can start having vendors pull out to their own rep 19:00:08 *repo 19:00:47 +1 19:01:03 yeah, that would be good. The main thing is that we're supposed to vouch for the quality of these drivers, that are in tree - and to be honest the only one we can vouch for is the l3reference, since that gets tested at the openstack gate 19:01:15 sc68cal: yes earlier - we had some control on the ownership of the CI - now its in another part of Cisco 19:01:18 sc68cal: +1 19:01:49 and most vendors do have their networking-vendor repos 19:04:22 Would it be reasonable to ask if vendors can move their drivers out by N-2 ? 19:04:36 that sounds good to me 19:05:07 +1 19:06:58 ok i will ping the vendor contacts as the first step 19:07:03 though in LBaaS we decided to leave them in 19:07:15 some vendors see it important to be part of the repo... 19:07:19 xgerman: hmm ok 19:07:39 we should ping them anyway and if they resist we can revisit 19:07:58 i am not religious on this, i thought in neutron in general the direction with vendor decomp - we want to ease vendors out 19:08:06 xgerman: yes sounds good to me 19:08:30 I'm not religious either, but the pylint thing just highlighted a driver that needs an owner 19:09:24 agreed. 19:11:26 ok those were some things i wanted to discuss - did not have anything else - i can think of right now. 19:12:12 that's all from me too. Anyone else? 19:12:26 well, we should mention that PTL proposals are open.. so if anyone wants to run... 19:12:52 for the PTL of Neutron... 19:13:27 I wish anyone who wants to, all the best 19:13:49 * sc68cal leans back in his lazy boy chair and sips his drink 19:13:56 +1 19:15:56 unless there is anything else, I think we can close this out and give everyone 15 back 19:16:01 +1 19:16:04 +1 19:16:29 #endmeeting