18:31:57 <SumitNaiksatam> #startmeeting Networking FWaaS
18:31:57 <openstack> Meeting started Wed Feb 25 18:31:57 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:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:32:01 <openstack> The meeting name has been set to 'networking_fwaas'
18:32:06 <SumitNaiksatam> #info metting agenda https://wiki.openstack.org/wiki/Meetings/FWaaS#Agenda_for_Next_Meeting
18:32:42 <SumitNaiksatam> #info kilo-3 feature proposal freeze is March 5th, and milestone date is March 19th
18:33:16 <SumitNaiksatam> any other info anyone want to share?
18:33:40 <SumitNaiksatam> #topic Bugs
18:33:51 <SumitNaiksatam> #link https://bugs.launchpad.net/neutron/+bug/1418196
18:33:52 <openstack> Launchpad bug 1418196 in neutron "fwaas: driver base class is stale" [Undecided,In progress] - Assigned to yalei wang (yalei-wang)
18:34:04 <SumitNaiksatam> is badveli here?
18:34:32 <SumitNaiksatam> since #link https://review.openstack.org/#/c/153930/ affects their patch
18:34:56 <SumitNaiksatam> sorry, not patch, affects the varmour driver, is what i meant
18:35:59 <SumitNaiksatam> anyone else got a chance to review the patch?
18:36:17 <SridarK> SumitNaiksatam: i did look at this - more on the method args
18:36:27 <SumitNaiksatam> SridarK: yeah
18:36:46 <vishwanathj> will try to look at it later today or early tomorrow
18:36:50 <SridarK> SumitNaiksatam: i was not so sure if this was mandatory
18:37:32 <SridarK> SumitNaiksatam: but as such the changes are fine - should not cause impact - not every one will have agent_mode as something significant
18:37:43 <SridarK> it is more to do with the ref implementations
18:38:17 <SridarK> logically i viewed this as the base class methods as stating some basic requirements
18:38:33 <SridarK> but this is more a python thing with this patch
18:39:00 <SumitNaiksatam> SridarK: okay
18:39:19 <SridarK> SumitNaiksatam: i think this is fine
18:39:24 <SumitNaiksatam> i am not able to find the commit id that this patch references
18:40:13 <SridarK> Also it did not get linked to the bug ?
18:41:00 <SumitNaiksatam> “The change set of f69ed3b3, Change-Id: Iba78e534ccf347ea6270aabc939a489dd40a7b9e”
18:41:05 <SumitNaiksatam> i could not find this
18:41:09 <vishwanathj> I see the bug id being referred in the commit message
18:41:25 <SridarK> SumitNaiksatam: yes but usually we also see a review url
18:42:32 <SumitNaiksatam> my point is that the bug is referring to a commit ID (and hash) that supposedly made a change to the fwaas driver base
18:42:41 <SumitNaiksatam> but i cant locate that bug id
18:42:45 <SumitNaiksatam> sorry commit id
18:43:04 <SumitNaiksatam> the linking from the review to the LP bug is a separate thing
18:43:12 <vishwanathj> ok
18:43:20 <SumitNaiksatam> sometimes it happens that way that the link does not get established
18:43:57 <badveli> Hello All, sorry a bit late
18:44:09 <SumitNaiksatam> i dont undertand what consistency is the author referring to
18:44:26 <SumitNaiksatam> i am guessing this is the root wrap changes
18:46:00 <SumitNaiksatam> okay anyway, i will try to track this offline
18:46:17 <SumitNaiksatam> badveli: can you comment on the review: #link https://review.openstack.org/#/c/153930/
18:46:24 <SumitNaiksatam> as this affects your driver
18:47:13 <badveli> Yes sumit, will review it
18:47:16 <SumitNaiksatam> or this might be the DVR agent mode
18:47:35 <SumitNaiksatam> i am not sure why the driver base class has to be changed
18:47:39 <SumitNaiksatam> anyway
18:48:00 <SumitNaiksatam> vishwanathj: you are looking at #link https://bugs.launchpad.net/openstack-manuals/+bug/1419498 right?
18:48:01 <openstack> Launchpad bug 1419498 in openstack-manuals "Networking services in OpenStack Security Guide - FWaaS Section Updates" [Low,In progress] - Assigned to vishwanath jayaraman (vishwanathj)
18:48:26 <vishwanathj> yes, I uploaded a patch set and have got one +1 and one  +2
18:49:03 <vishwanathj> the review is at link https://review.openstack.org/#/c/158943/
18:49:31 <SumitNaiksatam> vishwanathj: oh wow, that was fast ;-)
18:49:56 <vishwanathj> SumitNaiksatam, thanks to your tips and guidance yesterday, that made it go faster
18:50:14 <SumitNaiksatam> vishwanathj: happy to help, and thanks for acting on this quickly
18:50:24 <vishwanathj> it was a low hanging bug with less changes
18:50:34 <SumitNaiksatam> vishwanathj: sure
18:51:29 <SumitNaiksatam> i dont see an update on #link https://review.openstack.org/#/c/147396/
18:52:11 <yushiro> SumitNaiksatam, sorry.  this patch needs following patch.
18:52:21 <SumitNaiksatam> yushiro: ah ok
18:52:30 <SumitNaiksatam> yushiro: thanks for stopping by in the meeting
18:52:45 <SumitNaiksatam> yushiro: one use case was that we actually wanted to share the firewall policies
18:52:59 <SumitNaiksatam> yushiro: across tenants
18:53:12 <SumitNaiksatam> yushiro: do you think this can be better handled by changes to policy.json?
18:53:36 <SumitNaiksatam> yushiro: by this i meant the patch you have posted
18:54:22 <SumitNaiksatam> yushiro: we have the shared attribute in the firewall policy
18:54:45 <yushiro> SumitNaiksatam, yes.  firewall-policy has the attribute 'shared'
18:54:55 <SumitNaiksatam> which is set to True by default
18:55:12 <SumitNaiksatam> which means that the firewall_policy created will be shared by default across tenants
18:55:28 <SumitNaiksatam> hence you are seeing the behavior
18:56:35 <yushiro> SumitNaiksatam, sorry to late response.  I'm not good at writing english
18:56:44 <SumitNaiksatam> yushiro: no worries at all
18:57:16 <SumitNaiksatam> yushiro: we can take it offline if you prefer that (over ML and #openstack-fwaas)
18:57:36 <yushiro> SumitNaiksatam, Yes, I'd like to. thank you.
18:57:42 <SumitNaiksatam> yushiro: sure
18:57:51 <SumitNaiksatam> yushiro: and thanks for your work
18:58:01 <vishwanathj> +1
18:58:04 <SumitNaiksatam> SridarK: badveli: anything else on the bugs to discuss today?
18:58:06 <yushiro> SumitNaiksatam, Thank you too :-)
18:58:15 <SridarK> SumitNaiksatam: nothing from me
18:58:19 <badveli> nothing much from my side
18:58:26 <SumitNaiksatam> ok moving on
18:58:32 <SumitNaiksatam> i know vishwanathj has to leave early
18:58:40 <SumitNaiksatam> lets try to get the firewall insertion in before that
18:58:52 <SumitNaiksatam> #topic Firewall Insertion
18:59:00 <SumitNaiksatam> #link https://review.openstack.org/152697
18:59:10 <SumitNaiksatam> SridarK: over to you
18:59:19 <SridarK> #link https://review.openstack.org/#/c/152697/
18:59:35 <SridarK> next rev of patch posted on Sun
18:59:50 <SridarK> folks pls take  a look (thanks pc_m )
19:00:06 <SridarK> basic structure in place
19:00:26 <SridarK> working on validation code to test if routers specified can be associated with fw
19:00:45 <SridarK> ie, same tenant and router is not already allocated to another fw
19:00:53 <SridarK> testing that
19:01:00 <SridarK> other thing that remains is UT
19:01:23 <SumitNaiksatam> SridarK: okay great, thanks
19:01:26 <SridarK> i have fixed most of the existing UT, working thru agent
19:01:41 <SridarK> the other thing is to gauge vendor code impacts
19:01:47 <SridarK> freescale is fine
19:02:08 <SridarK> will need discussion with badveli & vishwanathj for their vendor code
19:02:19 <SumitNaiksatam> vishwanathj: what about your plugin/driver?
19:02:53 <vishwanathj> SumitNaiksatam, SridarK and I will have an offline conversation later today
19:03:06 <SumitNaiksatam> vishwanathj: okay sure
19:03:17 <SumitNaiksatam> badveli: you are fine with the changes so far?
19:03:48 <badveli> sridar and myself will need a talk
19:03:59 <badveli> we planned to discuss today
19:04:10 <SumitNaiksatam> badveli: have you reviewed the patch?
19:04:17 <SumitNaiksatam> so far
19:04:39 <badveli> just went through the code changes,
19:05:12 <SumitNaiksatam> badveli: okay, might be good to have a good understanding of the proposed changes, so that you can have a more meaningful interaction
19:05:27 <SumitNaiksatam> all please note that we are getting very close to cut-off on the features
19:05:40 <SumitNaiksatam> so we need to wrap up on the pending items at the earliest
19:05:40 <badveli> yes, Sumit,
19:06:18 <SumitNaiksatam> so i would very much request cooperation and deligent/speedy feedback from the entire team on this
19:06:33 <SridarK> Folks thanks in advance
19:06:41 <SumitNaiksatam> there was a suggestion that i made to SridarK in the morning
19:06:57 <vishwanathj> SumitNaiksatam, SridarK, sure, we will review and provide feedback and impact if any
19:07:10 <SumitNaiksatam> regarding the default behavior to keep it consistent with the prevailing semantics
19:07:32 <SumitNaiksatam> the suggestion was to check if no routers are specified during create
19:07:55 <SumitNaiksatam> and if they arent, then apply the firewall on all routers
19:08:03 <SumitNaiksatam> which is what is done today
19:08:38 <vishwanathj> ok
19:08:46 <SumitNaiksatam> if you need more granular application, you can provide the list of routers
19:09:10 <SumitNaiksatam> if you provide an empty list, then the firewall is not applied to any routers
19:10:17 <SridarK> SumitNaiksatam: that will the case when the FW will remain in PENDING_CREATE
19:10:36 <SumitNaiksatam> SridarK: correct
19:10:38 <SridarK> SumitNaiksatam: and in the case where the attribute is not specified and there are no routers in the tenant
19:10:51 <SridarK> SumitNaiksatam: yes agreed
19:11:23 <SumitNaiksatam> anyone else has thoughts on this?
19:11:25 <SridarK> SumitNaiksatam: also one thing that i also just realized is that the help string associated with the --router-ids can also convey this
19:11:34 <SumitNaiksatam> SridarK: perfect!
19:11:39 <SridarK> SumitNaiksatam: so users are more aware
19:11:59 <vishwanathj> seems reasonable to me
19:12:21 <SumitNaiksatam> my main motivation in suggesting this is that it makes this entire patch a non-disruptive change
19:12:23 <SridarK> So i will query if there is no attribute, i will query for routers on the tenant and apply that
19:12:43 <SumitNaiksatam> so that we dont have transient gate breaking issues
19:13:02 <SumitNaiksatam> also existing clients dont have to be changed immediately, and will continue to work
19:13:11 <SumitNaiksatam> SridarK: yeah
19:13:32 <SridarK> Sounds good - i will add that
19:13:53 <SumitNaiksatam> SridarK: AFAIK, that should work, but i dont know if things have changed since i last used the “ATTRIBUTE_NOT_SPECIFIED"
19:14:18 <SridarK> SumitNaiksatam: i will test this out first too
19:14:19 <SumitNaiksatam> vishwanathj: badveli pc_m: any thoughts on this default behavior semantics?
19:14:54 <vishwanathj> like I said earlier, the defaulth behavior seems reasonable to me
19:15:18 <vishwanathj> SumitNaiksatam, I got to leave, I will review the meeting minutes later and catch up, bye all
19:15:23 <pc_m> SumitNaiksatam: sorry, don't know enough about it... :(
19:15:27 <SridarK> vishwanathj: bye
19:16:06 <badveli> currently PENDING_CREATE
19:16:22 <badveli> state is changed when the firewall becomes active
19:17:22 <SumitNaiksatam> badveli: ACTIVE is also a state
19:17:24 <badveli> we are saying that if there is empty list the fw will remain in PENDING STATE
19:17:33 <badveli> and will never change, correct?
19:17:46 <SridarK> badveli: an UPDATE will change it
19:17:51 <SumitNaiksatam> badveli: empyt list implies that that fw should not be applied on any router
19:17:59 <SumitNaiksatam> badveli: yes
19:18:41 <SumitNaiksatam> badveli: however, if you dont specifiy the router_id list (which is different from specifying an empty list), it will be applied to all routers, as is the case today
19:19:52 <badveli> fine with me
19:19:58 <SumitNaiksatam> badveli: ok
19:20:03 <SumitNaiksatam> pc_m: no worries :-)
19:20:43 <SumitNaiksatam> btw, i posted the CLI patch for this insertion change: #link https://review.openstack.org/#/c/158118/
19:20:50 <SumitNaiksatam> SridarK: thanks for the update
19:21:09 <SridarK> SumitNaiksatam: no worries, thanks for the input on this
19:21:12 <SumitNaiksatam> #topic FWaaS L3 agent refactoring/restructuring
19:21:21 <SumitNaiksatam> SridarK: thanks for the update on this earlier
19:21:37 <SumitNaiksatam> SridarK: pc_m: so i believe no immediate changes required at this point?
19:21:50 <pc_m> SumitNaiksatam: correct
19:22:10 <SumitNaiksatam> pc_m: okay, thanks for the discussion with SridarK on this
19:22:12 <pc_m> seemed like not many changes may be needed anyway, so can defer
19:23:14 <SumitNaiksatam> pc_m: okay great
19:23:22 <SumitNaiksatam> #topic Service Objects
19:23:26 <SumitNaiksatam> badveli: over to you
19:23:44 <SumitNaiksatam> any updates you want to provide?
19:23:47 <badveli> still working on the neutron patch
19:23:54 <SumitNaiksatam> badveli: okay
19:24:02 <badveli> able to retrieve my code changes
19:24:15 <badveli> some how my previous review is not there any more
19:25:34 <SumitNaiksatam> badveli: its probably abandoned
19:25:46 <badveli> yes might be
19:25:58 <badveli> need to get from some where locally
19:26:22 <badveli> which was very old one and need to modify
19:26:52 <SumitNaiksatam> badveli: okay
19:27:09 <SumitNaiksatam> thanks for the update
19:27:15 <SumitNaiksatam> #topic Open Discussion
19:27:22 <SumitNaiksatam> anything else we need to discuss?
19:27:27 <banix> have a stupid question that will probably waste couple of minutes of your time but if that’s ok, I will ask :)
19:28:04 <SumitNaiksatam> banix: we have exactly a couple of mins
19:28:08 <SumitNaiksatam> banix: so shoot :-)
19:28:10 <banix> any plans to include a group of ip addresses in service object or in firewall rules at some point?
19:28:33 <banix> i see references to grouping of addresses as a possible extension in the original design doc
19:28:34 <SumitNaiksatam> banix: we have address objects on the road map
19:28:40 <SumitNaiksatam> banix: yes
19:28:53 <SumitNaiksatam> banix: we prioritized service objects over that
19:29:00 <banix> SumitNaiksatam: i see. great. thanks for the info.
19:29:04 <pc_m> I mentioned to SridarK this morning, but I was looking at the API reference doc, and VPN doc is gone. Don't know when that happened. I'm not sure if FWaaS have API reference documentation too, but there is nothing there on the web page. http://docs.openstack.org/developer/devstack/
19:29:16 <SumitNaiksatam> banix: but service objects has been in review for over a year now!
19:29:24 <pc_m> Just a heads up...
19:29:44 <SumitNaiksatam> pc_m: ah good to know
19:29:45 <pc_m> Wrong link... http://developer.openstack.org/api-ref-networking-v2.html
19:29:46 <banix> SumitNaiksatam yeah noticed that
19:30:08 <annegent_> pc_m: is there a WADL for VPNaaS in the openstack/api-site repo?
19:30:13 <pc_m> SumitNaiksatam: It has LBaaS
19:30:28 <SumitNaiksatam> annegent_: thanks for chiming in
19:30:32 <SumitNaiksatam> annegent_: we will check
19:30:37 <pc_m> annegent_: Not sure. What is a WADL?
19:30:52 <annegent_> The bug has been here since last fall: https://bugs.launchpad.net/openstack-api-site/+bug/1358179
19:30:53 <openstack> Launchpad bug 1358179 in openstack-api-site "Neutron Virtual Private Network as a Service (VPNaaS) API requires "v2.0" in URI" [Undecided,Triaged]
19:30:54 <SumitNaiksatam> annegent_: which exact location should we be looking at?
19:30:59 <pc_m> annegent_: In 2013 I added documentation as part of a commit.
19:31:01 <annegent_> Web Application Description Language
19:31:30 <annegent_> I'll triage that bug further
19:31:48 <annegent_> pc_m: it needs to go into https://github.com/openstack/api-site
19:31:50 <pc_m> annegent_: I committed, and it was on the web site, back in 2013
19:32:04 <annegent_> pc_m: the API reference? If so I can find it in history.
19:32:07 <SumitNaiksatam> to the best of my knowledge we had fwaas here as well, since i had added that patch (sometime in 2013 as well)
19:32:14 <pc_m> Used to be on the API reference pages.
19:32:16 <SumitNaiksatam> annegent_: okay thanks
19:32:25 <annegent_> SumitNaiksatam: will also look in history there
19:32:36 <SumitNaiksatam> annegent_: thanks, will try to follow up as well
19:32:39 <annegent_> thanks
19:32:56 <SumitNaiksatam> alrighty, thanks everyone, we are a couple of mins over time
19:33:03 <SumitNaiksatam> bye
19:33:08 <SridarK> bye all
19:33:12 <SumitNaiksatam> #endmeeting