18:30:53 <SumitNaiksatam> #startmeeting Networking FWaaS
18:30:54 <openstack> Meeting started Wed Jan  7 18:30:53 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:30:57 <openstack> The meeting name has been set to 'networking_fwaas'
18:31:08 <SumitNaiksatam> new year greetings to you!
18:31:24 <SumitNaiksatam> #info metting agenda https://wiki.openstack.org/wiki/Meetings/FWaaS#Agenda_for_Next_Meeting
18:31:30 <vishwanathj> Happy New year filled with +2's for all :)
18:31:31 <SridarK> Happy New Year to all as well
18:32:02 <SumitNaiksatam> #info Kilo-2 is Feb 5th
18:32:34 <SumitNaiksatam> i believe we would have multiple patches to be lined for this
18:33:18 <SridarK> SumitNaiksatam: yes i will have one for vendor and one for Router Insertion
18:33:45 <SumitNaiksatam> #topic FWaaS code split and work items
18:33:55 <SumitNaiksatam> i am not sure if we have any pending items for this
18:34:14 <SridarK> SumitNaiksatam: i think we are good on this
18:34:15 <SumitNaiksatam> the UT refactor was merged on dec 19th 
18:34:26 <SridarK> SumitNaiksatam: i ran some tests with devstack and we are good
18:34:34 <SumitNaiksatam> SridarK: great
18:34:44 <SumitNaiksatam> i havent checked what the tempest status is
18:35:23 <SumitNaiksatam> badveli: hi
18:35:31 <badveli> hello sumit and all
18:35:36 <SridarK> badveli: hi
18:35:43 <badveli> hello sridark
18:36:06 <SumitNaiksatam> #topic Bugs
18:36:30 <SumitNaiksatam> i see some new low priority bugs
18:36:34 <SumitNaiksatam> but nothing critical
18:36:50 <SridarK> SumitNaiksatam: yes on this
18:37:08 <SumitNaiksatam> #topic Docs
18:37:23 <SumitNaiksatam> one thing we are missing is the developer documentation
18:37:44 <SumitNaiksatam> #link http://docs.openstack.org/developer/neutron/devref/fwaas.html#
18:38:17 <SumitNaiksatam> we need to take some stab at it sooner than later
18:38:26 <SumitNaiksatam> i will look at it
18:38:35 <SridarK> SumitNaiksatam: if it is not urgent - i can help as well
18:38:42 <SumitNaiksatam> others are welcome to help
18:38:47 <SumitNaiksatam> SridarK: thanks, yes sure
18:38:58 <vishwanathj> sure
18:39:03 <SridarK> SumitNaiksatam: ok cool - next week is bad after that will be fine
18:39:29 <SumitNaiksatam> not sure if we need to follow up on the FWaaS/DVR documentation anymore
18:39:51 <SumitNaiksatam> i dont think Swami is around, and have not heard back from him
18:39:53 <SridarK> SumitNaiksatam: i will check with Swami to see if something is needed
18:40:00 <SumitNaiksatam> SridarK: great, thanks
18:40:11 <SridarK> np
18:40:19 <SumitNaiksatam> #topic FWaaS: L3 Agent restructure - observer hierarchy
18:40:25 <SumitNaiksatam> #link https://review.openstack.org/#/c/140884/
18:40:32 <SumitNaiksatam> vishwanathj: brought this up earlier today
18:40:37 <SumitNaiksatam> and pc_m is here
18:40:43 <pc_m> SumitNaiksatam: Yes, need review of this.
18:40:49 <pc_m> It is first of two parts.
18:40:50 <SumitNaiksatam> so we can probably have a short discussion
18:40:52 <SridarK> pc_m: i am looking now
18:40:57 <SridarK> and it looks good
18:41:08 <pc_m> This adds the service class and loads the driver.
18:41:19 <SumitNaiksatam> pc_m: vishwanathj was requesting a bit of summary/guidance on this
18:41:28 <SumitNaiksatam> pc_m: in case you want to oblige
18:41:38 <pc_m> A later commit can do any L3 event callbacks (if any).
18:41:43 <pc_m> SumitNaiksatam: Sure.
18:41:53 <SumitNaiksatam> pc_m: starting with the commit in neutron
18:42:02 <SumitNaiksatam> #link https://github.com/openstack/neutron/commit/2494da22007b204113e48f5fe2ccbcb8594ce1f2#diff-2
18:42:07 <pc_m> The goal is to separate the services from the L3 agent.
18:42:48 <pc_m> To do this, we're trying to tease apart the code. There are three things that we're working on.
18:43:16 <pc_m> One is at init, drivers are loaded by the services. This, we moved to a new service class.
18:43:39 <pc_m> Two is that there are L3 events that services are interested in.
18:44:16 <pc_m> To deal with this, we use the service class as an "observer" that subscribes with an event notifier instance.
18:44:56 <pc_m> In the L3 agent, it will do before and after notifications for certain events. The event notifier object will then notify each of the observers registered.
18:45:22 <pc_m> This gives the observer (e.g VPN driver) a chance to take any action.
18:45:41 <pc_m> Three is that some device drivers call back into the L3 agent for things.
18:46:10 <pc_m> For now, we've been placing those methods in the service class, as it knows the L3 agent and can forward the calls.
18:46:56 <pc_m> The plan is to have a Router object, and in the future the device drivers will get that object (instead of an L3 agent) and can directly access it.
18:47:08 <pc_m> These methods will then be removed.
18:47:43 <pc_m> Here' s a placeholder for VPN: https://review.openstack.org/145219
18:47:57 <pc_m> Make sense?
18:48:01 <vishwanathj> pc_m, thanks for the summary
18:48:10 <pc_m> vishwanathj: np
18:48:18 <SumitNaiksatam> pc_m: yes, thanks
18:48:22 <vishwanathj> thanks for the VPN link as well
18:48:26 <pc_m> So with FW, we're trying to do step 1, doing the driver.
18:48:54 <SumitNaiksatam> pc_m: tiny nit, now that i think back - perhaps AdvancedServicesOberver would have been a better class name than “AdvancedServices” for: #link https://github.com/openstack/neutron/commit/2494da22007b204113e48f5fe2ccbcb8594ce1f2#diff-8c9b587b95c8967128f336672d1b5a01R22
18:49:02 <SumitNaiksatam> pc_m: but thats only merged
18:49:03 <pc_m> Here's teh VPN refactoring, which is done: https://review.openstack.org/140918
18:49:08 <SumitNaiksatam> so besides the point
18:49:58 <SumitNaiksatam> SridarK: i believe it will be easier to do the firewall insertion if this change gets in first?
18:50:01 <pc_m> SumitNaiksatam: Yeah, there was quite a bit of naming discussion, but it is a base class and then each service will have a concrete class, so you can call the FW one with Observer on it.
18:50:27 <SridarK> SumitNaiksatam: we may over write some of these changes with insertion
18:50:41 <pc_m> In fact, there is still some discussion on whether the AdvanceService should e a singleton or not.
18:50:49 <SumitNaiksatam> SridarK: in which case I think better for pc_m’s patch to merge first
18:50:57 <SridarK> SumitNaiksatam: but yes i think we should decouple this
18:51:02 <SridarK> SumitNaiksatam: yes
18:51:04 <SumitNaiksatam> pc_m: where is this discussion happening?
18:51:19 <vishwanathj> pc_m, the three things you mentioned, are they all targeted for kilo-2?
18:51:35 <pc_m> SumitNaiksatam: mostly in the reviews.
18:51:40 <SumitNaiksatam> pc_m: okay
18:51:42 <pc_m> vishwanathj: yes.
18:52:09 <SumitNaiksatam> pc_m: when do you anticipate posting a WIP for the follow up FWaaS patch, or is someone else planning to post that patch?
18:52:15 <pc_m> vishwanathj: The third will likely be later, as the router class is targeted for K-2, so this will be changed after that.
18:52:28 <pc_m> SumitNaiksatam: Glad you asked...
18:53:19 <pc_m> I wanted to get this device driver one in first. Then, I'd like to work with someone from the FW team to see what events are needed, whether the existing notification are ok or if more are needed, etc.
18:53:25 <SumitNaiksatam> pc_m: i was just trying to understand if we need to see the followup patch before merging the current one
18:53:46 <SumitNaiksatam> pc_m: ah okay, so your expectation is to get this merged first
18:53:54 <SridarK> pc_m: i can definitely look at that or work with u - i am quite familiar with that code
18:54:08 <pc_m> SumitNaiksatam: I don't think so, the first provides the basic class, and driver load, so is decoupled.
18:54:23 <pc_m> SridarK: Would love that. Maybe next week, when I'm in SJ?
18:54:31 <SridarK> pc_m: surely
18:54:49 <SumitNaiksatam> pc_m: okay good, so we can focus on getting the current patch reviewed and merged first
18:54:50 <pc_m> SridarK: I'll be arriving Monday, so will have all Tuesday to work on it.
18:54:54 <SridarK> pc_m: as i indicated earlier that area is going to see a lot of flux with the router insertion work as well
18:55:10 <pc_m> SumitNaiksatam: Super
18:55:22 <vishwanathj> pc_m, are the vendor drivers code patch uploads expected to wait until the first two things are completed?
18:55:25 <pc_m> SridarK: Good to know. We can work it together.
18:55:37 <SridarK> pc_m: sounds good
18:56:56 <SumitNaiksatam> pc_m: the follow up patch(es) will be in neutron-fwaas or in neutron, or both?
18:56:59 <pc_m> vishwanathj: Good question. I think they can work independently. What we did with VPN, which already existed, was to put the hooks in place, and then implement the event handlers/moving.
18:57:21 <SridarK> vishwanathj: i think in theory u will have to wait - but i think u can still make some progress on the plugin and kind of treat this as a black box
18:58:03 <pc_m> SumitNaiksatam: The event handlers, if new are needed, will affect both places (definition/notifier in neutron, handler in neutron-fwaas).
18:58:13 <vishwanathj> pc_m, SridarK, thanks
18:58:28 <pc_m> For the router instance, that'll be all in the neutron-fwaas I suspect.
18:59:06 <SumitNaiksatam> pc_m: in that case, can the firewall insertion and this change be handled in the same patch?
18:59:18 <SumitNaiksatam> SridarK: perhaps question for you as well ^^^
18:59:37 <SridarK> SumitNaiksatam: pc_m: It can be done that way as we will land up mauling all that code
18:59:55 <SridarK> today we are interested in router add notifications
19:00:04 <SumitNaiksatam> i am trying to see how we can land the firewall insertion change in K2 since that is highest priority in my opinion
19:00:05 <pc_m> SumitNaiksatam: May be good to decouple all the chnages.
19:00:09 <SridarK> but we may not need this with the router insertion changes
19:00:38 <SridarK> but we will want to the leave the repo in a sane state
19:01:07 <SridarK> SumitNaiksatam: perhaps pc_m & us can discuss the changes more in detail when he is in SJ ?
19:01:12 <SridarK> and then decide
19:01:14 <SumitNaiksatam> since review cycles are limited, i would hope to get the attention focussed on the firewall insertion changes (after the pc_m’s current patch is merged)
19:01:18 <pc_m> As we have it now, we retro-fitted the changes in. Essentially, created the event, then moved the logic over.
19:01:27 <SumitNaiksatam> SridarK: sure
19:02:02 <SumitNaiksatam> perhaps we can do this on tuesday and anyone else interested can join as well (vishwanathj i am looking at you ;-) )
19:02:16 <pc_m> SumitNaiksatam: Sounds fine. I can always try to work the FW stuff and get guidance from SridarK.
19:02:40 <vishwanathj> SumitNaiksatam, sure
19:02:41 <pc_m> SumitNaiksatam: re; tuesday, yeah, I have no other plans.
19:02:43 <SridarK> Sounds good folks
19:02:56 <SumitNaiksatam> ok lets do that then
19:02:58 <vishwanathj> I will be in San Jose next week
19:03:03 <SumitNaiksatam> moving on
19:03:05 <SridarK> vishwanathj: we can work out offline on the logistics unless u are in SJ next week as well :-)
19:03:20 <SumitNaiksatam> #topic FWaaS insertion
19:03:49 <SumitNaiksatam> SridarK: any update on this?
19:03:58 <SridarK> SumitNaiksatam: with the time off and all have started looking at this
19:04:16 <SumitNaiksatam> SridarK: np
19:04:16 <SridarK> SumitNaiksatam: first step is to look at functional blocks to break out the reviews in sensible chunks
19:04:27 <SridarK> SumitNaiksatam: if that is needed
19:04:37 <SumitNaiksatam> hmmm…is it going to be that big a change?
19:04:46 <SridarK> SumitNaiksatam: not really sure now
19:04:48 <SumitNaiksatam> i was thinking this will be fairly contained
19:04:54 <SumitNaiksatam> i might be wrong
19:04:55 <SridarK> SumitNaiksatam: will have that evaluated
19:05:22 <SridarK> SumitNaiksatam: yes will only plan for that if it is really required
19:05:24 <SumitNaiksatam> since we already do router-specific processing
19:05:52 <SridarK> SumitNaiksatam: yes in the best case - it could be only some changes with the agent messaging
19:06:17 <SridarK> SumitNaiksatam: and the main changes are really on the db side of things to track routers
19:06:43 <SumitNaiksatam> i can pitch in with that if you need help on that side (and we are breaking the patches)
19:06:53 <SridarK> SumitNaiksatam: will have this scoped out and will run it by u
19:06:53 <SumitNaiksatam> breaking -> splitting
19:07:02 <SridarK> SumitNaiksatam: yes definitely thanks
19:07:38 <SumitNaiksatam> but we need to be aggessive in pursuing it here on, since we need to give enough time before the k2 deadline for reviews
19:07:58 <SumitNaiksatam> SridarK: thanks
19:08:05 <SumitNaiksatam> #topic Service Objects
19:08:11 <SumitNaiksatam> badveli: hi
19:08:19 <badveli> yes sumit
19:08:32 <SumitNaiksatam> anything we need to discuss on this front?
19:08:46 <SumitNaiksatam> have the code patches been posted?
19:09:29 <badveli> no not yet, with the new infra should i wait?
19:10:01 <SumitNaiksatam> badveli: new infra?
19:10:28 <badveli> i might need to see if the service groups used by firewall rule need to wait
19:12:11 <badveli> what should i do should i get in the service groups and the objects code review
19:12:35 <glebo> during spec review, when Doug W orginally put a -1 on the service objects spec, I contacted him and we had a good talk about it
19:12:38 <glebo> his issue was:
19:12:51 <glebo> he didn't want them to be FWaaS specific, but instead
19:13:08 <glebo> wanted them to be able to be generically used across all modules
19:13:10 <glebo> and I agreed
19:13:24 <glebo> he wasn't sure if the current spec got us there or not
19:14:07 <SumitNaiksatam> glebo: okay
19:14:13 <glebo> I assured him that was the intention, but I myself am a bit unclear how this intersects architecturally with GBP objects, or congress-based objects, for that matter
19:14:41 <glebo> when he sensed that we at least understood the importance of the architectural fit question,
19:14:45 <glebo> he then approved,
19:15:00 <glebo> but I'm not sure we've really *addressed* it correctly yet.
19:15:25 <glebo> vishnu and I could use a bit of insight / perspective from the team here
19:15:35 * glebo wonders if any of this is making sense?
19:16:55 <SridarK> glebo: i always thought that this will be made avail  to Sec Groups or any other feature but this patch will only address FWaaS
19:17:01 <SumitNaiksatam> the service groups/objects proposal was targeted to address, what i understood, was an immediate need for fwaas
19:17:27 <SumitNaiksatam> hence the proposal targeted grouping firewall rules
19:18:06 <badveli> sumit i had a tough time in the review, as per my understanding this was approved because the sec groups could use it
19:18:08 <SumitNaiksatam> it was anticipated that over time, with experience from using service objects in FWaaS, the definition could be extended
19:19:00 <glebo> I think that's where reviewers are choking: they'd rather see a more generic object model, where the service / service group can be called by any other OpenStack module, not just AdvServices, and not just Neutron.
19:19:22 <SumitNaiksatam> glebo: i would imagine that would be a new spec then
19:19:26 <glebo> That makes rational sense to me to, but I'm not sure about scope and timing
19:19:46 <SumitNaiksatam> glebo: since i would like to understand what the expectations of that “other OpenStack module” is
19:20:35 <glebo> SumitNaiksatam: could be QoS, could be monitoring, could be service chaining rule, could be…. you get the point.
19:20:59 <SumitNaiksatam> glebo: well but we need to spec that
19:21:17 <glebo> time running short…
19:21:26 <glebo> here, in this mtg, I mean,
19:21:48 <glebo> could we have a call or move to FW room after meeting to try to get our collective heads around this?
19:22:05 <glebo> I just don't want the actual code commits to be blocked again
19:22:15 <glebo> by neutron reviewers
19:22:24 <SumitNaiksatam> glebo: my concern as well
19:22:54 <glebo> and I want to do the *right* thing for the OS community too, of course
19:23:57 <SumitNaiksatam> glebo: i guess we are all trying to do the right thing for the community :-)
19:24:10 <glebo> SumitNaiksatam: sure ;-)
19:24:47 <SumitNaiksatam> #topic Open Discussion
19:25:12 <SumitNaiksatam> we can continue the same discussion, but just wanted to open it up in case there is something else anyone wants to bring up
19:25:50 <glebo> SumitNaiksatam:  ummm, how will we proceed on last topic? How about a call today at 1pm pst? If that works, I can send out conf details
19:26:05 <glebo> takers?
19:26:14 <SridarK> Vendor implementations with dependencies on neutron vendor implementation which will in a separate repo - is something we are breaking our heads on
19:26:32 <SumitNaiksatam> glebo: unfortunately i have a conflict today
19:26:39 <SumitNaiksatam> SridarK: ah good point
19:26:39 <SridarK> vishwanathj: this is something for u as well
19:26:49 <glebo> immediately following this then?
19:27:07 <SridarK> glebo: sorry today is bad for me
19:27:32 <vishwanathj> SridarK, what is the dependency on neutron vendor implementation?
19:27:42 <vishwanathj> sorry, I did not get that
19:27:56 <glebo> SridarK:  SumitNaiksatam: ack. I'll propose another day / time over email / ML.
19:27:59 <SridarK> vishwanathj: the fact that ur router implementation will not be in neutron anymore
19:28:14 <vishwanathj> oh ok, I get it
19:28:19 <SridarK> or rather will not be in neutron
19:28:40 <SridarK> and we need to see how we manage that with a vendor repo etc
19:29:09 <SumitNaiksatam> SridarK: so this is logistics issues, but from a run-time perspective, it will be very similar to how it currently does, right?
19:29:24 <SridarK> SumitNaiksatam: yes exactly
19:29:47 <SridarK> and maybe something that we can look for common approaches across the vendor community as well
19:30:04 <SumitNaiksatam> SridarK: okay so another topic for discussion on the coming tuesday ;-)
19:30:11 <SumitNaiksatam> alrighty, we have hit our time
19:30:15 <SridarK> SumitNaiksatam: yes :-)
19:30:19 <SumitNaiksatam> thanks all for joining!
19:30:24 <SridarK> thanks
19:30:27 <SumitNaiksatam> #endmeeting