18:35:07 #startmeeting Networking FWaaS 18:35:07 SumitNaiksatam: np 18:35:08 Meeting started Wed Oct 15 18:35:07 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:35:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:35:11 The meeting name has been set to 'networking_fwaas' 18:35:40 any big announcements, or info, that people want to share at the outset? ;-) 18:36:01 #topic Bugs 18:36:22 we are getting close to the Juno release (RC2 has been out for a few days) 18:36:55 did our testing reveal any new FWaaS related issues? 18:36:59 we could talk about the brewing consensus around moving vendor-specific code out of neutron, but why don't we cover that after the other status stuff 18:37:34 glebo: yes sure 18:37:46 #chairs SridarK badveli glebo 18:37:51 in case my client acts up 18:37:59 ack 18:38:21 IRC bot did not not seem to like that 18:38:30 #chairs 18:38:38 #chair 18:38:39 Current chairs: SumitNaiksatam 18:38:48 #chair SridarK badveli glebo 18:38:49 Current chairs: SridarK SumitNaiksatam badveli glebo 18:38:54 okay 18:39:20 SridarK: badveli: anything new/critical it terms of bugs that showed up on your radars? 18:39:31 i did not see anything new 18:39:34 SumitNaiksatam: have not noticed either 18:39:44 okay 18:39:56 btw, this is a good time to turn our attention to pending Client issues 18:40:07 i believe there is at least one patch that is for review 18:40:30 r either badveli or SridarK doing any testing themselves, or r we just receiving bugs (when they come) from others doing integrated system testing? 18:40:56 #link https://review.openstack.org/104132 18:40:57 said another way, is anyone actively pushing on the FWaaS code directly? Or just looking to see that it doesn't break other things 18:40:58 i have my set up 18:40:59 ? 18:41:27 glebo: we have two parallel paths 18:41:43 glebo: we rely on the upstream gate to catch regressions 18:41:53 (sorry for the newbie question, just trying to get caught up. We can take it offline, if people prefer) 18:41:55 glebo: and then we do manual testing as well 18:42:04 glebo: very fair question 18:42:09 ack 18:42:24 i am working on some vendor stuff but that is based on Juno so getting some testing done there 18:42:42 on the manual testing front both badveli and SridarK have been active 18:42:50 yes 18:42:52 btw, thanks SridarK and badveli for that effort! 18:43:11 *snaps for badveli & SumitNaiksatam* 18:43:19 glebo: :-) 18:43:25 no worries :-) 18:43:31 * SumitNaiksatam applauds as well 18:43:47 glebo: the main concern is with regressions at this point 18:43:57 and in the context of the DVR 18:43:59 SumitNaiksatam: i think we need to formalize this in some form 18:44:01 re: snaps: s/SumitNaiksatam/SridarK 18:44:22 SumitNaiksatam: this? 18:44:33 since we could not get any new features into juno anyway! ;-) 18:44:54 ah 18:45:01 glebo: this being pre-Juno release 18:45:20 glebo: fyi - #link 18:45:22 glebo: fyi - #link 18:45:25 glebo: fyi - #link 18:45:40 so it was mostly ensuring that our pre-existing code didn't foobar the DVR stuff in Juno? 18:46:12 glebo: yes, that and the support for N-S that we added (in the DVR context) 18:46:15 glebo: fyi - #link 18:46:48 ok related activity 18:46:52 #topic Docs 18:47:03 SridarK: are we covered? 18:47:06 SumitNaiksatam: i am on the hook for wrapping up the DVR docs 18:47:16 SridarK: i am asking in the context of the network install guide 18:47:19 SridarK: ah good 18:47:35 just need to loo at the format of the things - i will get a review out next week 18:47:42 *look 18:47:46 SridarK: do you have a patch posted or are you coordinating with someone on the DVR team to push a consoliated patch? 18:48:02 SridarK: ok, i think you answered my question 18:48:03 I was just going to address it in the context of FWaaS 18:48:26 SridarK: do you have the LP bug link handy? (just for the record here) 18:48:46 SumitNaiksatam: no for this it did not create a bug 18:48:51 we have this one: #link https://bugs.launchpad.net/openstack-manuals/+bug/1346986 18:49:38 ah i remember, i think we had an AI to follow up with Rudrajit? 18:50:48 SumitNaiksatam: yes Rudrajit to my surprise does not show up in cisco anymore 18:50:50 :-) 18:50:57 I will reach out 18:51:03 SridarK: oops 18:51:07 but this is a bit dated so not sure if relevant 18:51:25 in any case will cover the DVR support as a separate bug 18:51:35 SridarK: great 18:52:24 ok so i will jump to open discussion since we are not tracking a specific feature/bug at this point 18:52:30 #topic Open Discussion 18:52:38 glebo: you were making a point earlier? 18:53:04 about the vendor specific code? 18:53:16 glebo: i believe so 18:53:25 yeah, so 18:53:29 glebo: i think there is already good support for that 18:53:37 I've been working hard to figure out 18:54:12 glebo: not just in the context of fwaas, but vendor plugins in general (or at least that was the last discussion i recall on the ML) 18:54:15 what the core issues are that are resulting in all our FWaaS, GBP and vendor plugin code from not seeing integration into mainline 18:54:21 talking to a bunch of different folks 18:54:37 glebo: i added a comment to the ether pad also in the fwaas context and completely on board 18:55:14 and seeing that the cores' main issue for Neutron/* is 18:55:30 clean up, stability, and feature parity with Nova Networking, 18:55:35 to me it seemed like there is a nova 18:55:40 glebo: yeah 18:55:45 in order to have a strong foundation of neutron 18:55:47 parity that is important 18:55:49 glebo: its not specific to FWaaS, GBP or vendor plugins, its any new feature or code in general 18:55:55 on which to build all the service layers features we all want 18:56:01 This is probab among the most important things to cover _before_ we talk about stuff coming out of neutron 18:56:01 and, 18:56:16 in order to retire nova-networking, so the nova folks aren't blocked on that stuff, 18:56:23 which they are bogging down in now, and don't want to be 18:56:30 glebo: yeah 18:56:47 but how do we add features now? 18:56:49 so there is a lot of pressure on the neutron cores to get their sh1t together, 18:57:14 all of this, while there is a MAJOR growing pain occuring across all OS, and cores are stretched to the bone, 18:57:44 its a bit of a confluence of events that just leave little cycles to do the "icing" feaures, 18:58:01 even though the icing features are what the customers all need in order to deploy 18:58:03 so, 18:58:27 understand the nova parity things and all the efforts 18:58:28 in trying to figure out how to eleviate the pain where it is felt most for the cores, 18:58:36 how do we add feature now? 18:58:45 to the mainline 18:58:51 how do we make their lives easier, is the question I've been asking them, and 18:59:10 glebo: thats a reasonable summary 18:59:13 the most immediate thing I see that would help is to pull all the 18:59:26 vendor-specific code out of neutron, which 18:59:57 relieves pressure, test scope, reviews, bloat, etc from Neutron, 18:59:59 while 19:00:22 giving us essentially a bit more freedom to develop a bit faster, and own our own destiny, 19:00:49 in essence, the plug-ins will become their own project, for any given area like FWaaS or LBaaS, 19:00:50 where 19:00:58 glebo: pulling code out is probab a good thing but if the interfaces to neutron are not clearly defined - we will be floating away in space :-) 19:01:25 SridarK: *getting to that* 19:01:25 glebo: dont confuse advances services’ with vendor code 19:01:41 SridarK: *typing as fast as his little fingers will allow* 19:02:05 glebo: for vendor plugins to support a feature, its API has to be first exposed somewhere 19:02:07 glebo: :-) no worries 19:02:08 our plugins will truly be 19:02:14 glebo: today that happens to be neutron 19:02:17 +1 19:02:24 PLUGINS, not mainline code, 19:02:26 glebo: we can pull the vendor plugins out of neutron 19:02:49 glebo: plugins are only an implementation of the API that is exposed in the “mainline" 19:03:05 * SumitNaiksatam is glad the pc_m is watching over our shoulder ;-P 19:03:07 and then it is up to us to very clearly work w/in the related neutron areas to define, code, merge in the interfaces, constructs, etc, we need to make a framework for the plugins, 19:03:19 however, the framework MUST stay common, 19:03:35 seems to make sense for vendor items to come out of Neutron, IMO 19:03:43 we can't go off splintering tons of "mine, mine, mine" features to differentiate over each other, 19:04:06 glebo: that would mean that you would not be able to add new features until neutron reaches the perceived “stability" 19:04:07 or we will drift, as SridarK feared 19:04:22 *fingers tired. listening to others now* 19:04:25 correct sumit 19:04:38 glebo: pulling vendor extensions out of the main tree is very achievable 19:04:55 glebo: in fact you can even do that today, just publish a pypi package :-) 19:05:13 *vendor extensions -> vendor plugins (and perhaps extensions as well) 19:05:16 SumitNaiksatam: not that I'm giving up, but what I'm hearing is we aren't going to be given air time to add new features until "stability" anyway, 19:05:26 glebo: correct 19:05:27 SumitNaiksatam: Does that then implement the driver and it gets selected in INI? 19:05:38 so we can pull it out and work on the side, or keep it all in and stall 19:05:43 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage 19:05:45 pc_m: yeah, that could be one option i guess 19:05:45 given the choice, i prefer the latter 19:05:55 glebo: pull out what? 19:06:02 i had see the neutron gap coverage that 19:06:19 s/stall/stahl 19:06:37 *he thinks that's how its spelled, but spelling was never his strong point* 19:07:03 sumit i think right now is this important 19:07:08 ? 19:07:10 badveli is right, that's the holy grail right now 19:07:13 the gap coverage 19:07:18 for the record of the chat, 19:07:32 #link: https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage 19:07:35 glebo: sorry i lost you there 19:07:53 SumitNaiksatam: where is "there"? 19:08:04 *giggles playfully* 19:08:14 Sumit i think untill the gap coverage is done 19:08:23 glebo: what you are proposing to pull out and what you are proposing keep in (and “stahl”) 19:08:28 adding new stuff would not be possible 19:08:48 SumitNaiksatam: sorry, I was saying that, as I see it, 19:08:53 we have 2 options: 19:08:58 (1) 19:10:24 pull out the vendor extenstions from the main tree, and structure them truly as optional modules that the operators can choose to "install", or 19:10:34 (2) stay in and simply stahl for a while 19:10:53 given the two options, I like opt 2 19:11:30 glebo: i think we need to discuss where services will be and then the vendor stuff comes next 19:11:31 glebo: (2) is really frustrating, from personal experience. 19:11:32 and I think that option pleases a lot of the cores too, because it will help ease the pain during the gap-closure period of history in which we all find ourselves presently 19:11:47 SridarK: maybe so 19:11:54 SridarK: AND 19:12:43 SridarK: I think that conversation will be far better received once the cores see the longer range picture of removing the vendor-specific code in an effort to help get the gap closed 19:13:04 pc_m: I hear u on that 19:13:04 glebo: for stuff that is in already in terms of the API yes we can worry about the vendor stuff, but if want to get new features in then we need to see how services come out 19:13:28 if we cannot add things like service groups for example 19:13:29 SridarK: true 19:13:52 so there are 2 (possibly and likely) parallel paths 19:14:36 sorry, folks, just realized that i have a hard stop 19:14:43 if as vendors we come - if we need to add an extension that is vendor specific - how we can do that if we are outside is still a challenge as SumitNaiksatam pointed out 19:14:43 i will check back the logs 19:14:48 and continue the discussion later 19:14:54 SridarK: but once the cores see that we get the gap issue, and are willing to do some serious heavy lifiting to help out, they may be more helpful wrt the common-framework build-up features need to EMPOWER services to be out on their own 19:15:01 SumitNaiksatam: sounds good 19:15:02 SridarK: see the point? 19:15:06 SridarK: badveli glebo: if you will be kind enough to end the meeitng when done 19:15:09 great discussion! 19:15:11 thanks all! 19:15:12 ok 19:15:14 later 19:15:27 SumitNaiksatam: ack. syl 19:15:51 glebo: yes agree but it is important that the necessary stuff is done in neutron _before_ things are pulled out 19:16:14 if the order is reversed we will be waiting for a couple of releases to have something working 19:16:32 SridarK: well, I think the move that earns us a "well played" at the end is to say, 19:17:15 SridarK: "Sure, we'll go ahead and pull out, but here's the list of what we need in order to do that rationally, w/o regressing to a lesser feature state." 19:17:24 glebo: exactly 19:17:27 SridarK: and, in so doing, we get our stuff progressed. 19:17:41 glebo: and possibly the most important conversation to have at the summit 19:17:51 SridarK: and everyone feels like they are getting what they want, us, cores, etc. 19:18:04 SridarK: win-win's are good. Happy people. 19:18:12 glebo: yes and that is a very reasonable place to be for all 19:18:39 +100 to sridark, glebo 19:19:04 sounds like a good plan 19:19:11 i wasn't sure how all y'all would feel about this plan 19:19:13 glebo: i think most are in alignment with this - we just need to articulate that and have a good conversation on this 19:19:49 now that we appear to have alignment internally, 19:19:57 meaning here in FWaaS, 19:20:10 I think the next step is to get the LBaaS folks on board 19:20:15 glebo: and also as vendors 19:20:27 glebo: yes 19:20:29 SridarK: we r the vendors, no? 19:20:52 glebo: that is what i meant as vendors we are in alignment too 19:21:04 glebo: in addition to fwaas sub team 19:21:08 then step 3 would be to continue socializing this idea with more and more cores, 19:21:29 and the idea is that we do step 3 in parallel to step 2 19:21:44 SridarK: agreed 19:21:59 glebo: i think we have a plan 19:22:29 *hears music to his ears* 19:22:40 :-D 19:22:45 glebo: and pc_m is on vpnaas 19:22:59 so we have that as well 19:23:17 SridarK: ah yes, we'd definitely need to add vpnaas to step 2. Good catch, m8 19:23:27 vpnaas == forgotten stepchild 19:23:37 pc_m: :-) 19:23:38 pc_m: LoL 19:23:55 pc_m: bastard step child? 19:24:05 pc_m: hope not!! 19:24:07 Not many people working on it, so even harder to get visibility 19:24:14 glebo: :) 19:24:44 pc_m: patience, my friend. 19:24:57 pc_m: the order of networking things is ALWAYS: 19:25:22 pc_m: connectivity, access control, privacy, auth 19:25:57 pc_m: it's like maslows hierarchy of needs for new networking technologies / protocols 19:26:23 pc_m: https://www.google.com/search?q=maslow%27s+hierarchy+of+needs&espv=2&biw=964&bih=716&tbm=isch&tbo=u&source=univ&sa=X&ei=Tco-VPCfIYvgoASMtYGYDA&sqi=2&ved=0CDQQsAQ 19:26:56 :) 19:27:09 coming up on closing time 19:27:12 anything else? 19:27:15 do let me know if you need help in putting things before you go to summit 19:27:23 nothing else from me 19:27:32 i think we can call it a wrap 19:27:41 see u folks later and thanks 19:27:44 badveli: u going to summit? 19:27:55 badveli: I know Yi is. 19:28:04 that all from my side, thanks all 19:28:12 ok i am ending 19:28:14 no 19:28:19 see you folks at the summit! 19:28:24 #endmeeting