18:31:31 #startmeeting Networking FWaaS 18:31:32 Meeting started Wed Jan 28 18:31:31 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:31:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:31:36 Hi All 18:31:36 The meeting name has been set to 'networking_fwaas' 18:31:39 #info metting agenda https://wiki.openstack.org/wiki/Meetings/FWaaS#Agenda_for_Next_Meeting 18:31:48 #info Kilo-2 is Feb 5th 18:32:02 any other announcements/info worth sharing upfront? 18:32:26 #topic Bugs 18:32:35 i think we are good on this in this week as well 18:32:44 SumitNaiksatam: yes nothing new 18:32:48 i was looking at some CLI patches earlier, and posted some comments 18:32:55 but havent been able to get back to those 18:32:58 SridarK: thanks 18:33:15 i am not sure badveli is here 18:33:23 #topic Docs 18:33:38 doesnt seem like any new requirements here either 18:34:07 #topic Firewall Insertion 18:34:15 SridarK: any updates? 18:34:47 SumitNaiksatam: still working thru - i have done some work on the extensions and am now working thru the db side of this 18:34:59 once i have something very basic will push a WIP patch 18:35:06 SridarK: good 18:35:18 wanted to get this out earlier but got tied up with some other things 18:35:27 SridarK: it might be worth posting a WIP patch even without the DB impl 18:35:30 and will push to get this out soon 18:35:51 SridarK: it will give a head start on the review, since feb 5th is only a week away 18:36:04 SumitNaiksatam: at least want something sketchy here - will connect with more on this 18:36:31 SumitNaiksatam: i also am looking how we can minimize impacts with vendor patches 18:36:33 SridarK: based on the extension definition the CLI patch can also be added 18:36:49 SridarK: thats a noble goal! ;-) 18:36:58 SumitNaiksatam: yes definitely - will sync with u on the CLI as well 18:37:00 :-) 18:37:17 any questions for SridarK on the insertion patch? 18:37:29 SumitNaiksatam: noble or selfish (meaning how much it will impact the insertion patch0 :-) 18:37:42 SridarK: okay “noble” 18:37:46 :-) 18:37:59 SridarK: thanks for the update on that 18:38:05 np 18:38:15 SridarK, do you expect a lot of code changes to the vendor code as a result of your patch upload? 18:38:31 just trying to get an effort sizing 18:38:54 vishwanathj: definitely want to minimize this - we will need to discuss this 18:39:19 vishwanathj: i took a quick scan thru ur patch - i need to think this thru some more 18:39:35 needless to say, we will try as much as possible to not create extra work for anyone 18:39:43 vishwanathj: i will ping u and we can run thru - i think it may not be too bad - 18:39:52 hence the offline coordination 18:39:53 SumitNaiksatam: yes exactly 18:39:54 SridarK, Ok 18:40:12 but there might be some refactoring, which unfortunately cannot be avoided 18:40:38 but hopefully we can help each other out here, regardles of vendor code or not 18:40:54 SumitNaiksatam: yes - exactly 18:40:57 Understood 18:41:06 lets get to the vendor patches as the next topic 18:41:26 since pc_m is here 18:41:41 #topic FWaaS L3 agent refactoring/restructuring 18:41:53 pc_m: anything new that we should be discussing here? 18:41:59 or you want to update us? 18:42:13 SumitNaiksatam: no. Just will wait for SridarK to do the FW insertion. 18:42:39 pc_m: okay, really appreciate your patience on this! 18:42:46 np 18:42:56 and also for being our eyes and ears on the L3 agent refactoring 18:43:04 badveli: good time to join 18:43:05 hello all, sorry for being late 18:43:11 #topic Service Objects 18:43:12 badveli: hi 18:43:20 hello sumit, sridar 18:43:21 badveli: any update on this topic? 18:43:41 Sumit:i am trying to understand your mail 18:43:55 badveli: okay 18:44:12 for reference, I believe badveli is referring to my email which was pointing to this patch: 18:44:29 #link https://review.openstack.org/#/c/145085 18:44:49 badveli: correct me if thats not what you meant 18:45:07 sumit, you are right 18:45:17 so last week we had the discussion about splitting the patches for a feature impl across the neutron and the neutron-fwaas repo 18:45:34 there seem to be some patches in LBaaS which are already doing this 18:45:47 the one referenced above is an one such example 18:46:04 as was our understanding, one cannot link patches across gerrits 18:46:25 so the neutron-lbaas patch fails until the extension changes are not approved in neutron 18:46:43 the neutron-lbaas patch points this out in its commit message 18:46:47 we can do something similar 18:47:14 and/or actually copy over the extension definition changes to the neutron-fwaas repo (temporarily) to get the UTs to pass 18:48:07 i do not believe the later is required, but is helpful from a validation or testing perspective (when revieiwing the feature as whole) 18:48:13 badveli: hope that clarifies 18:48:23 latter seem better, imho 18:49:01 SumitNaiksatam: so we will then have to wait for the changes to merge in neutron-fwaas before the extension patch in neutron merges 18:49:03 pc_m: okay 18:49:22 SridarK: the other way round, right? 18:49:38 SumitNaiksatam: oops yes 18:50:00 yeah, a bit painful and non-linear 18:50:34 SumitNaiksatam: the extension patch in neutron will kind of stand on its on and will not really get pulled in anywhere as the plugin that uses it will be in the service repo 18:50:49 SridarK: true 18:50:57 SumitNaiksatam: am i right in thinking this like adding a text file 18:51:48 SridarK: yeah, but it seems to fly in the face of the earlier requirements to have a reference implementation for the extension that can be readily validated 18:52:09 SumitNaiksatam: yes but now it is just a 2 step process 18:52:16 SridarK: i guess this can still be done by pointing to the two relevant patches in devstack, but makes reviewing certainly more challenging 18:53:07 SumitNaiksatam: yes i think there is some confusion being the first time - i guess we will figure this out 18:53:43 SridarK: yeah, lets use the neutron-lbaas patches (and their complements in the neutron repo) as guiding templates 18:54:13 i guess in this case we are happy to let them be “trailblazers” ;-) 18:54:33 SumitNaiksatam: yes that was very useful for pointing us to that - definitely helped 18:54:34 badveli: any update on service groups/objects? 18:55:17 sumit, i have not thaught about how to go with the changes 18:55:23 as i was not very clear 18:55:40 badveli: okay, hope the discusison over the past couple of weeks has helped 18:55:54 yes, 18:56:10 sumit: let me get back on this if i have questions/ will mail the team 18:56:16 badveli: great! 18:56:21 badveli: thanks 18:56:26 thanks sumit 18:56:36 #topic Vendor Plugins/Drivers 18:56:45 vishwanathj: lets start with yours 18:56:59 vishwanathj: your lib dependency issues are resolved? 18:57:21 yes 18:57:39 you want to share a quick summary with the rest of the team? 18:58:03 Sure... 18:59:20 the short summary is that we ran into issues with dependency on code that will be hosted in stackforge, however per Doug_Weigley;s email suggestion used mock in our tests to resolve those issues. 18:59:58 Also, the only person to have reviewed so far is SumitNaiksatam, hopefully others will find the time to look at our code 19:00:02 vishwanathj: thats correct, thats the appraoch with plugins and drivers in neutron as well 19:00:12 vishwanathj: i have started looking :-) 19:00:16 learning a lot 19:00:20 SridarK, thanks 19:00:45 I am done with my summary 19:00:50 vishwanathj: thanks 19:01:26 i also want to point out that there is another plugin which is in review: #link https://review.openstack.org/148884 (freescale) 19:01:51 this nearly made it in Juno and has been tossed around quite a bit 19:02:03 thanks for sharing the link, I will review as well 19:02:08 i'm peeking at it now... but don't have much FW knowledge. 19:02:14 i commend the author’s patience and perseverance on this 19:02:21 SumitNaiksatam: +1 on that 19:02:44 i think he deserves attention! 19:02:45 SumitNaiksatam: i think that patch was quite ready to go 19:02:49 thanks pc_m vishwanathj! 19:02:58 SumitNaiksatam: so hopefully this will be easy 19:03:02 pc_m, I plan to upload updated class diagram and sequence digrams on github....maybe that can help with the FW reviews 19:03:17 vishwanathj: Sure! 19:03:18 vishwanathj: thanks, great, looking forward to it 19:03:51 there was something similar on the LBaaS wiki pages, however it was a bit confusing 19:04:06 vishwanathj: i think what you have might be very helpful 19:04:47 the link to github where I plan to upload will be https://github.com/vishwanathj/ 19:04:48 perhaps publishing the raw files might also help, incase anyone wants to update the sequence diagrams 19:04:54 but totally upto you 19:05:11 I have already uploaded a raw version, 19:05:20 vishwanathj: you can provide a link from the wiki 19:05:32 one needs to install Visual paradigm to open the file 19:05:39 vishwanathj: hopefully others can post changes to your repo 19:05:52 I also plan to upload the JPEGs of the diagrams 19:05:56 vishwanathj: thanks 19:06:14 this is a first attempt, any feedback or corrections are certainly welcome 19:06:15 i believe the last plugin/driver we are tracking is the Cisco one 19:06:28 SridarK: ? 19:06:42 i believe i also yanping here? 19:06:43 SumitNaiksatam: yes, we are getting thru the vendor split for the L3 split 19:06:48 *also saw 19:07:06 SumitNaiksatam: we also have an extension 19:07:19 SumitNaiksatam: something we are in discussion 19:07:33 SridarK: you mean extension to FWaaS? 19:07:40 SumitNaiksatam: yes 19:07:48 SridarK: and you intend to move that with the vendor repo split 19:08:08 SumitNaiksatam: so we have a vendor repo dependency and a Vendor extension for fwaas 19:08:32 SumitNaiksatam: so find an interesting new use case here 19:08:34 SridarK: i would think that would be the sensible/reasonable approach, unless there are explicit guidelines against doing it 19:08:55 SridarK: i meant moving the vendor extension along with the service plugin 19:09:07 SumitNaiksatam: yes - according the guidelines - vendor extensions are to be in neutron 19:09:44 SridarK: it that supposed to be interpreted in the context of the neutron extensions, or also in the context of advanced services’ extensions? 19:10:24 SumitNaiksatam: an easy approach will be to keep it with in the neutron-fwaas repo but given the caveat and also that for the reference implementation we are putting extensions in neutron 19:10:38 okay 19:11:09 SumitNaiksatam: i think we may need to put the extension in neutron - in a vendor section 19:11:21 SridarK: okay 19:11:27 anything else on vendor code? 19:11:32 SumitNaiksatam: we are discussing this internally also 19:11:42 SridarK: yes noticed that 19:11:49 SumitNaiksatam: :-) 19:12:04 :-) 19:12:13 #topic Open Discussion 19:12:30 SumitNaiksatam: but yes we will a plugin patch and yanping will have a agent/driver patch 19:12:47 SridarK: okay, thanks 19:13:02 What is the likelihood of all vendor code reviewed by Feb 5th? 19:13:35 vishwanathj: currently we have two vendor code related patches 19:13:47 vishwanathj: so it seems promising 19:13:56 Brocade and Freescale, right? 19:14:13 that gives me a ray of hope :) Thanks 19:14:23 vishwanathj: yeah 19:14:28 Does FW have a functional test gate running? 19:14:34 vishwanathj: but i am speaking for myself! :-P 19:15:05 pc_m: you mean on the neutron-fwaas repo? 19:15:06 Understood, that's why I asked about the review and not not approval :) 19:15:17 SumitNaiksatam: yes 19:15:48 pc_m: does vpnaas have one? 19:16:23 i recall that the all the adv services tests we moved to a separate job 19:16:24 SumitNaiksatam: In progress, I'm adding it right now... 19:16:40 but i dont see that running now 19:16:44 pc_m: so good point 19:16:59 SumitNaiksatam: I've been taking notes on the steps needed... 19:17:16 pc_m: awesome, it will help this team if you can share those 19:17:40 SumitNaiksatam: Will do. Just need to figure out where to put the notes... may make a Google Doc. 19:17:48 SumitNaiksatam: i think some one was looking at the tests - i will find out and let folks know 19:18:18 pc_m: yes sure, or perhaps you can just create a wiki page, your call 19:18:27 SridarK: ok, it will be good to know 19:18:36 I'm still in the process. Have the functional gate as experimental, and once tested out, will setup check to run all the time, and finally voting. 19:18:42 i currently dont see an lbaas-specific gate job either 19:18:51 pc_m: correct 19:19:09 pc_m: so you are taking the existing vpnaas tempest tests? 19:19:36 There's two things actually, per repo functional gate, so that we can create functional tests for VPN (there are none). 19:19:54 The other is Tempest, which currently, maru is moving to be in-tree for Neutron. 19:20:11 Once in tree, the tests for VPN can be moved to VPN repo. 19:20:21 LBaaS will be doing the same. 19:20:32 * pc_m I've been talking to Doug 19:20:43 Just giving you guys a heads up... 19:20:55 pc_m: okay, yeah there are fwaas tempest tests as well 19:20:59 more side effects of the split 19:21:20 SumitNaiksatam: Yeah, there is one VPN tempest test for API 19:22:09 pc_m: for the former - the functional tests will also be in the services’ repo, right? 19:22:45 Yeah, we're making functional tests for VPN that will go in neutron_vpnaas/tests/functional/ 19:23:11 The gate I just upstreamed will run them (fingers crossed). 19:23:22 s/just/just got/ 19:23:45 pc_m: but you dont have any functional tests, right? 19:24:19 not yet, there are a bunch that people have been developing, and are waiting for the gate to push out for review. 19:24:25 3 I think 19:24:58 pc_m: okay, so you are getting the gate job in place first, and then people will start adding the tests? 19:25:51 Yeah. pretty much. Have it as experimental, then we can create functional tests and check them during review. 19:26:05 pc_m: ok cool 19:26:08 Once things are working, we'll turn on the check all the time, but non-voting. 19:26:27 pc_m: why cant the py27 job run all the tests? 19:26:31 I also have to add gate hooks in the VPN repo. 19:26:56 SumitNaiksatam: As I understand it, the functional tests spin up devstack. 19:27:12 * pc_m don't ask the difference between functional and tempest :) 19:27:32 pc_m: ah ok 19:27:34 So the test starts up devstack and has access to routers, etc... 19:28:16 I heard that the tempest tests do that, and use VMs too, but not sure why functional tests, which have access to a Nova can't do the same/ 19:28:32 probably some misunderstanding on my part. 19:28:35 pc_m: yeah, some of the tempest scenario tests do that 19:28:49 Still trying understand all this... :) 19:29:11 #action pc_m to provide info on VPNaaS functional gate setup 19:29:12 pc_m: but thanks for the headsup here in terms of what you are doing, and is very helpful for the team here as well! 19:29:21 +1 19:29:25 sure. I'm here to help :) 19:29:45 #action fwaas team to take pc_m out for lunch the next time he is in the bay area! ;-) 19:29:54 :) 19:29:57 +1 :) 19:30:05 SumitNaiksatam: or in vancouver 19:30:13 +1 19:30:15 alrighty, we have hit the hour 19:30:21 thanks everyone for joining! 19:30:22 bye 19:30:24 bye all 19:30:27 bye 19:30:27 bye 19:30:32 #endmeeting