18:02:12 <SumitNaiksatam> #startmeeting Networking FWaaS
18:02:13 <openstack> Meeting started Wed Jan  8 18:02:12 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:16 <openstack> The meeting name has been set to 'networking_fwaas'
18:03:36 <SumitNaiksatam> #topic FWaaS tempest tests
18:03:43 <SumitNaiksatam> #link https://review.openstack.org/#/c/64362/
18:04:05 <SumitNaiksatam> this is the initial cut for the API tests
18:04:30 <SumitNaiksatam> fried around?
18:04:36 <RajeshMohan> I will take a look at the review
18:04:40 <SumitNaiksatam> *yfried
18:04:48 <SumitNaiksatam> RajeshMohan: thanks
18:05:22 <SumitNaiksatam> RajeshMohan: the first step is that we need to request enabling of q-fwaas on the gate
18:05:55 <RajeshMohan> ok
18:06:04 <SumitNaiksatam> for that we need to ensure that enabling q-fwaas does not disrupt running the existing tests
18:06:15 <RajeshMohan> Is anyone else working on tempest?
18:07:15 <SumitNaiksatam> RajeshMohan: to some extent many people are looking at it
18:07:19 <SumitNaiksatam> including me
18:07:24 <SumitNaiksatam> SridarK around?
18:07:56 <SumitNaiksatam> I ran devstack with q-fwaas and q-vpn and at least the installation went through peacefully
18:08:12 <SumitNaiksatam> but we need to do more thorough testing
18:08:16 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-infra/2013-December/000579.html
18:09:26 <SumitNaiksatam> clarkb in this thread mentioned that there was an issue that they saw earlier when they turned on q-fwaas
18:09:42 <SumitNaiksatam> but i am not sure what exactly that issue was
18:09:47 <SumitNaiksatam> clarkb: there?
18:11:19 <RajeshMohan> I do not see clarkb on that thread
18:11:22 <SumitNaiksatam> perhaps not
18:11:39 <RajeshMohan> I see Salvatore, yourself and Yair
18:12:22 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-infra/2013-December/000586.html
18:12:39 <SumitNaiksatam> RajeshMohan: see ^^^ this message, it's embedded inside
18:14:04 <RajeshMohan> ok
18:14:14 <SumitNaiksatam> he might have replied privately
18:14:20 <SumitNaiksatam> did not realize that
18:14:24 <SumitNaiksatam> anyway
18:14:40 <SumitNaiksatam> i think we need to do our due diligence before recommending
18:15:31 <RajeshMohan> so, the goal is to make sure vpnaas and fwaas can work togehter?
18:15:47 <SumitNaiksatam> RajeshMohan: yeah
18:16:17 <SumitNaiksatam> RajeshMohan: before that we need to make sure that install goes smoothly (i kind of verified that)
18:16:36 <RajeshMohan> Makes sense
18:16:43 <SumitNaiksatam> RajeshMohan: then we need to run the existing tempest suite, and make sure that it passes (with q-fwaas turned on)
18:16:59 <SumitNaiksatam> this will not have q-fwaas tests yet, but at least that should pass
18:17:10 <RajeshMohan> ok
18:17:18 <SumitNaiksatam> then we will be in a position to recommend that we are not disruptive
18:17:37 <SumitNaiksatam> once that is turned on, the patches such as above can be reviewed
18:17:58 <SumitNaiksatam> currently even if the patch is reviewed, it can't be merged
18:18:38 <RajeshMohan> ok
18:19:13 <SumitNaiksatam> ok if nothing else immediately on tempest, then let's move forward
18:19:43 <SumitNaiksatam> #topic Service context and Insertion
18:19:56 <SumitNaiksatam> #link https://review.openstack.org/#/c/62599/6
18:20:00 <SumitNaiksatam> RajeshMohan: your patch
18:20:13 <RajeshMohan> Yes - UT is still pending
18:20:13 <SumitNaiksatam> RajeshMohan: we had lots of discussions over emails
18:20:18 <SumitNaiksatam> RajeshMohan: np
18:20:33 <SumitNaiksatam> RajeshMohan: i did not get a chance to look at the latest
18:20:53 <RajeshMohan> Yes - please look at it and send me your comments
18:21:08 <SumitNaiksatam> RajeshMohan: we are planning to make the agent and driver side changes as well, right?
18:21:11 <RajeshMohan> I am also working on migration scripts - will update the patch today
18:21:23 <RajeshMohan> Yes - that's the plan
18:21:25 <SumitNaiksatam> RajeshMohan: great
18:21:40 <RajeshMohan> Changes should be on agent only
18:21:51 <RajeshMohan> Driver changes may not be needed
18:22:50 <RajeshMohan> Maybe in update path (when routers are removed in service context), there may be changes in driver code
18:23:25 <RajeshMohan> I have to think through that - CREATE and DELETE will be simple changes
18:23:48 <SumitNaiksatam> RajeshMohan: okay, yeah i thought changes to the driver should be minimal
18:25:22 <SumitNaiksatam> RajeshMohan: anything currently blocking you (apart from more reviews)?
18:25:36 <RajeshMohan> No, I am good.
18:25:42 <SumitNaiksatam> RajeshMohan: ok great
18:26:18 <SumitNaiksatam> RajeshMohan: when the patch is closer to being ready, we need to engage other cores
18:26:27 <SumitNaiksatam> RajeshMohan: start with nati_ueno
18:27:03 <SumitNaiksatam> i will reach out to him as well
18:27:07 <RajeshMohan> Ok, I will ping Nachi
18:27:17 <RajeshMohan> Ok. Thanks.
18:27:33 <SumitNaiksatam> RajeshMohan: anything more on this topic?
18:27:55 <RajeshMohan> For exisiting unit test cases - i had a question
18:28:03 <SumitNaiksatam> ?
18:28:07 <RajeshMohan> is it ok to change existing test cases?
18:28:29 <RajeshMohan> I have managed to make all the test cases work without changes except 2
18:28:43 <RajeshMohan> Both in fwaas-extention test case
18:29:30 <RajeshMohan> The Firewall object return "service_cntext: None"
18:29:48 <RajeshMohan> When service context is not configured
18:31:25 <SumitNaiksatam> okay
18:31:30 <SumitNaiksatam> that does not work?
18:32:06 <RajeshMohan> The expected result does not have "service_context"
18:32:28 <RajeshMohan> Let me spend some more time on it
18:32:54 <RajeshMohan> Maybe there is something I can do with the Mock to not set it when it is None.
18:33:20 <RajeshMohan> The actual Firewall GET will not return service_context if it is not configured
18:33:36 <SumitNaiksatam> hmmm
18:33:42 <RajeshMohan> That's how all the other existing test cases work without change
18:33:43 <SumitNaiksatam> i am not sure if that's the right approach
18:34:12 <RajeshMohan> ok - what do you suggest?
18:34:43 <SumitNaiksatam> shouldn't we be sending back empty service_context?
18:35:28 <SumitNaiksatam> come to think of it, i guess the service_context should never be empty, right?
18:35:47 <SumitNaiksatam> its optional for the user to specific
18:35:51 <RajeshMohan> I started with that - but for backward compatibilty - I decided to go down this path
18:36:06 <SumitNaiksatam> but we will have a default context if none is specified during resource instance creation
18:36:39 <SumitNaiksatam> ah okay, but i think we don't need to worry as much about backward compatibility at least for fwaas
18:36:47 <RajeshMohan> So, GET should show empty or all the routers?
18:38:42 <RajeshMohan> If we show routers, then we may need a way to say that it is default and not what was configured
18:39:10 <SumitNaiksatam> i am thinking GET should give back {'service_context': {'routers': [<router_id>], 'subnets': [], 'ports': [], 'networks': []}
18:39:26 <SumitNaiksatam> i am not sure that we need to indicate that its default or not
18:40:01 <RajeshMohan> So, the router_id will be list of all routers (in case of default)
18:40:09 <SumitNaiksatam> we will not use default if the user configures the router_id, right?
18:40:48 <SumitNaiksatam> ah good, question, so you are asking if the default applies means apply on all routers
18:41:01 <SumitNaiksatam> i guess that should be the case, we are doing that now as default
18:41:13 <RajeshMohan> Other option is to return {'service_context': {'routers': [], 'subnets': [], 'ports': [], 'networks': []}
18:41:36 <RajeshMohan> But this means that the firewall rules are applied on all routers
18:42:22 <SumitNaiksatam> if we return empty, that means its not applied on any routers
18:42:38 <SumitNaiksatam> i would not interpret that as being applied on all
18:42:48 <RajeshMohan> so, we do {'service_context': {'routers': [<list of all router_ids>], 'subnets': [], 'ports': [], 'networks': []}
18:43:02 <SumitNaiksatam> i would think so
18:43:05 <RajeshMohan> when no service_context is configured
18:43:12 <RajeshMohan> ok
18:43:23 <SumitNaiksatam> in the case of the fwaas implementation with perimeter firewalls
18:43:53 <RajeshMohan> BTW - as a side effect, most exisitng unit test cases will change
18:44:25 <SumitNaiksatam> that should be fine
18:44:45 <SumitNaiksatam> i was going to say that the defaults might be different for a different provider and/or a different service
18:45:30 <RajeshMohan> right
18:45:45 <SumitNaiksatam> okay, not stating anything new, just what we had discussed
18:46:16 <SumitNaiksatam> gduan: around?
18:46:19 <RajeshMohan> In this BP, we only worry about L3 reference implementation
18:46:30 <SumitNaiksatam> RajeshMohan: yeah, sure
18:46:42 <SumitNaiksatam> thats why i was checking for gary duan
18:47:03 <SumitNaiksatam> because we currently have not tied in the service provider for fwaas, his patch is doing that
18:47:42 <SumitNaiksatam> so to your point, that is the default implementation with the default provider (once the provider notion gets added as well)
18:48:19 <SumitNaiksatam> anyway since gary is not around we can skip the discussion on #link https://review.openstack.org/#/c/60699/
18:48:31 <RajeshMohan> on the same point provider patch - the second patch that does in will have more change
18:48:34 <SumitNaiksatam> and lets follow up with him
18:48:56 <SumitNaiksatam> RajeshMohan: ? did not get that
18:49:08 <RajeshMohan> if service-insertion patch goes in after provider patch, then I may have more changes
18:49:17 <SumitNaiksatam> RajeshMohan: ah ok
18:49:30 <SumitNaiksatam> RajeshMohan: agree, this will potentially be complicated
18:49:46 <SumitNaiksatam> RajeshMohan: i mean complicated for gary to merge if he goes second
18:50:11 <SumitNaiksatam> RajeshMohan: are you fine with us pushing for provider patch merging in first?
18:50:25 <RajeshMohan> How close is Gary's patch to merge?
18:50:44 <RajeshMohan> He started first - so I am ok with merging mine with his changes
18:50:57 <SumitNaiksatam> seems like he added UTs
18:51:03 <SumitNaiksatam> but is MIA for a while
18:51:16 <RajeshMohan> I see
18:51:19 <SumitNaiksatam> lets try to track him
18:51:28 <RajeshMohan> Must be the holidays
18:51:42 <SumitNaiksatam> yeah, also he was not keeping well
18:51:52 <RajeshMohan> I see
18:51:56 <SumitNaiksatam> i think his patch is more straightforward
18:52:28 <SumitNaiksatam> since it goes along the precedence of lbaas and vpnaas
18:52:30 <RajeshMohan> Ok, I will start planning into merging with his
18:52:37 <SumitNaiksatam> RajeshMohan: great thanks
18:52:52 <SumitNaiksatam> anything more on this topic?
18:53:06 <SumitNaiksatam> since gary and yi are not here we can discuss more on this if required
18:53:30 <SumitNaiksatam> otherwise i don't have anything more for today'a agenda
18:54:20 <RajeshMohan> We have plan on Horizon changes for service-insertion
18:54:42 <SumitNaiksatam> RajeshMohan: oh good point
18:54:44 <RajeshMohan> I meant 'we have to plan on ...'
18:54:54 <SumitNaiksatam> yeah we don't have an owner for that right now
18:55:22 <RajeshMohan> right
18:55:52 <SumitNaiksatam> it is not required for the default case, but if the user has to provide input, then its required
18:56:12 <RajeshMohan> That's true. It will continue to work
18:56:50 <SumitNaiksatam> RajeshMohan: you have some experience with horizon as well, right?
18:57:06 <RajeshMohan> Yes - little bit
18:57:12 <RajeshMohan> mostly cut & paste
18:57:31 <RajeshMohan> I can do it if time permits
18:57:36 <SumitNaiksatam> RajeshMohan: ok we can explore how we can do that patch, the two of us can discuss
18:57:50 <RajeshMohan> ok
18:57:51 <SumitNaiksatam> RajeshMohan: if you can drop some knowledge on me, i can give it a shot :-)
18:58:20 <RajeshMohan> you definetely know more than me :-)
18:58:38 <SumitNaiksatam> #action RajeshMohan SumitNaiksatam  find owner for service insertion context for fwaas
18:58:39 <RajeshMohan> I learnt mostly by looking into Fwaas Horizon changes
18:59:28 <SumitNaiksatam> #topic Open Discussion
18:59:37 <SumitNaiksatam> we have < one min
18:59:47 <SumitNaiksatam> regarding next week's meeting, we will have if required
18:59:59 <RajeshMohan> makes sense
19:00:00 <SumitNaiksatam> we might go to a bi weekly format soon
19:00:05 <SridarK> sorry i was late - should calendar the mtg
19:00:09 <SumitNaiksatam> will send out an email to that effect
19:00:13 <SumitNaiksatam> SridarK: np
19:00:21 <SumitNaiksatam> SridarK: lets catch up later
19:00:27 <SumitNaiksatam> thanks all for joining!
19:00:30 <SridarK> sounds good will ping u after
19:00:37 <SumitNaiksatam> #endmeeting