18:31:36 <SumitNaiksatam> #startmeeting Networking FWaaS
18:31:36 <yushiro> SumitNaiksatam, hi
18:31:37 <openstack> Meeting started Wed Apr 15 18:31:36 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:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:31:41 <openstack> The meeting name has been set to 'networking_fwaas'
18:31:59 <SumitNaiksatam> #topic Bugs
18:32:03 <badveli> hello all
18:32:09 <SumitNaiksatam> badveli: hi
18:32:18 <badveli> hello sumit and all
18:32:22 <vishwana_> hi all
18:32:25 <SumitNaiksatam> i dont see anything critical pop up
18:32:39 <SumitNaiksatam> we still have the high priority doc bug
18:32:52 <SridarK> SumitNaiksatam: yes i too feel the same
18:32:58 <SumitNaiksatam> SridarK: okay
18:33:05 <SumitNaiksatam> I bugs we need to discuss today?
18:33:07 <SridarK> SumitNaiksatam: sorry i was out on PTO - will resume work on the doc bug
18:33:26 <SumitNaiksatam> SridarK: no worries, i could not post a follow up patch either after where i left off
18:33:46 <SridarK> SumitNaiksatam: no worries - i will work thru this
18:33:56 <SumitNaiksatam> yushiro: you had posted a bug fix, +A’ed that today
18:34:01 <SumitNaiksatam> yushiro: thanks
18:34:14 <yushiro> SumitNaiksatam, https://review.openstack.org/#/c/147396/, Thank you so much for reviewing!
18:35:03 <SumitNaiksatam> pc_m: thanks for posting: #link https://review.openstack.org/171637
18:35:12 <pc_m> sure
18:35:22 <SumitNaiksatam> i think #link https://review.openstack.org/169239 is also ready to be merged
18:35:54 <SridarK> pc_m: this is for L ?
18:36:21 <pc_m> 147396 is for L
18:36:25 <SumitNaiksatam> SridarK: yeah, i think now we are alaready in L
18:36:26 <pc_m> Just need another core
18:36:31 <SridarK> ok cool
18:36:50 <SumitNaiksatam> if there is a critical fix, it will have to be marked rc-potential and cherry-picked
18:37:05 <Swami> hi
18:37:10 <SumitNaiksatam> Swami: hi
18:37:16 <vishwana_> SumitNaiksatam, looks like mestery cherrypicked https://review.openstack.org/#/c/173902/
18:37:37 <mestery> vishwana_: ack
18:37:48 <vishwana_> mestery, thanks
18:38:06 <SumitNaiksatam> mestery: thanks
18:38:24 <SumitNaiksatam> i am wondering why its breaking python-27
18:38:42 <vishwana_> i need to investigate that later this afternoon
18:38:56 <SumitNaiksatam> vishwana_: i think it probably needs a rebased
18:39:14 <vishwana_> SumitNaiksatam, I will try that, thanks for the suggestion
18:39:34 <SumitNaiksatam> some of the  protoocl constants were removed from a particular module in Neutron
18:39:41 <SumitNaiksatam> they were in two places before
18:40:18 <SumitNaiksatam> so any part of the code that was referring to neutron/plugins/common/constants.py and had those protocol names will break
18:40:43 <SumitNaiksatam> vishwana_: i believe your patch was merged in L prior to that change
18:40:54 <vishwana_> yes
18:41:09 <vishwana_> so you think rebase would fix?
18:41:29 <SumitNaiksatam> fyi - #link https://github.com/openstack/neutron-fwaas/commit/0f5852efb8ceaed94504075cb6b0fdb16c2b3b76
18:41:33 <vishwana_> I do not see the rebase button
18:41:35 <SumitNaiksatam> is the relevant commit
18:42:25 <vishwana_> thanks
18:42:38 <vishwana_> I remember reviewing that patch set
18:42:50 <SumitNaiksatam> it seems that the issue is with the
18:43:28 <SumitNaiksatam> proposed/kilo branch for neutron-fwaas referring to neutron liberty
18:43:38 <vishwana_> I see AttributeError: module object has not attribute 'TCP', SumitNaiksatam, you are probably right
18:44:02 <SumitNaiksatam> that commit went into liberty
18:44:37 <vishwana_> SumitNaiksatam, what should I be doing?
18:44:56 <vishwana_> would appreciate any guidance or next steps
18:45:39 <SumitNaiksatam> i am trying to think why the proposed/kilo branch would break on a change that went into neutron for liberty
18:46:57 <vishwana_> SumitNaiksatam, maybe mestery or other neutron cores would have a better explanation for this?
18:46:57 <SumitNaiksatam> i think the problem might be that “proposed/kilo” is still pointing to neutron master:
18:47:04 <vishwana_> ok
18:47:05 <SumitNaiksatam> #link https://github.com/openstack/neutron-fwaas/blob/proposed/kilo/requirements.txt#L22
18:47:23 <SumitNaiksatam> whereas it should be pointing to kilo candidate
18:48:02 <pc_m> SumitNaiksatam: Hmm. Wonder if that is going to be an issue for all *aaS
18:48:08 <SumitNaiksatam> pc_m: yes
18:48:17 <pc_m> mestery: ^^^
18:48:29 <mestery> I think this has to do with pinning the version in there, marun and I have talked about this before.
18:48:35 <SumitNaiksatam> mestery: yeah
18:48:46 <SumitNaiksatam> currently its pointing to master
18:49:19 <SumitNaiksatam> that is the requirements.txt for all *aas kilo proposed branches is pointing to neutron master
18:49:47 <mestery> I think we should pin those to point to kilo, pc_m, want to propose 3 patches, one for each service repo?
18:49:58 <SumitNaiksatam> mestery: yes we need to pin to kilo
18:50:34 <pc_m> mestery: Yeah, I can. Do you know the syntax to specify the branch name in requirements file entry?
18:51:25 <iben_> mestery: is the telco meeting here soon?
18:51:38 <mestery> iben_: No idea :)
18:51:42 <vishwana_> SumitNaiksatam, mestery, pc_m, thanks
18:51:56 <vishwana_> pc_m, let me know if there is any way that I can help out
18:52:16 <iben_> are you guys in a meeting now?  Sorry if so… didn’t mean to intrude
18:52:21 <pc_m> vishwana_: Sure. We just need to figure out the syntax.
18:52:56 <SumitNaiksatam> pc_m: you can go like this: git+https://github.com/openstack/neutron.git@<branch-name>#egg=neutron
18:52:57 <pc_m> mestery: Do you know the syntax to specify the branch?
18:53:07 <pc_m> SumitNaiksatam: Thanks
18:53:17 <mestery> pc_m: yes what SumitNaiksatam said :)
18:53:37 <pc_m> Also, what branch do we commit to, exactly?
18:53:52 <SumitNaiksatam> pc_m: proposed/kilo
18:54:03 <iben_> https://wiki.openstack.org/wiki/TelcoWorkingGroup#Meetings
18:54:30 <SumitNaiksatam> iben_: sorry did not get the context of that post
18:54:44 <pc_m> iben_: Its the FWaaS meeting right now.
18:54:54 <SridarK> iben_: i think u are in the wrong channel
18:55:10 <pc_m> SridarK: yup. meeting-alt
18:55:12 <iben_> keep calm and carry on - my bad - have a nice day!
18:55:15 <iben_> i found it...
18:55:16 <SridarK> i guess u should be in openstack-meeting-alt
18:55:21 <SumitNaiksatam> iben_: np :-)
18:55:29 <iben_> iben was here!
18:55:34 <SridarK> :-)
18:55:57 <SumitNaiksatam> i dont think we have any other patches posted to proposed/kilo
18:56:15 <SumitNaiksatam> any other bugs anyone wants to discuss (or is blocked on)?
18:56:33 <vishwana_> badveli, is the VArmour firewall code using process_router() method?
18:56:45 <vishwana_> if yes, you are impacted otherwise you are good
18:56:49 <SumitNaiksatam> vishwana_: good point
18:57:08 <SumitNaiksatam> but the UTs are not breaking yet (assuming the code path is being tested)
18:57:09 <yushiro> to all,  https://review.openstack.org/#/c/171923/, is ready to review :)
18:57:27 <badveli> yes on the other day i am investigating it
18:57:39 <SumitNaiksatam> yushiro: thanks for catching this, nice work!
18:58:35 <vishwana_> SumitNaiksatam, let me know when pc_m and I can bring up about having FirewallService object handling event registrations in liberty? Thanks
18:59:03 <vishwana_> yushiro, is the issue reproducible only through REST API?
18:59:10 <SumitNaiksatam> vishwana_: sure, good segue to the next topic
18:59:14 <SridarK> vishwana_: something pc_m & i discussed - we can look into it
18:59:33 <SumitNaiksatam> #topic Liberty Features
18:59:42 <SumitNaiksatam> vishwana_: pc_m: go ahead
19:00:33 <SridarK> vishwana_: which events are u interested in ?
19:00:58 <vishwana_> SridarK, the router create and update event is what fixed the vyatta broken feature
19:01:00 <yushiro> vishwana_, you mean about https://review.openstack.org/#/c/147396/ ?  If so, Yes.
19:01:09 <SridarK> i guess the context is this is needed by vyatta and can we have this common across all implementations ?
19:01:41 <vishwana_> yushiro, thanks, SridarK, wanted to know if it made sense for other vendors as well ....
19:01:46 <SridarK> vishwana_: for router create - for the ref impl that is specified on the plugin
19:02:04 <SridarK> vishwana_: i think for u too correct ?
19:02:29 <vishwana_> SridarK, yes because we use reference plugin and do not have our own plugin
19:02:55 <SridarK> vishwana_: but u want to know about router create ?
19:03:24 <SridarK> vishwana_: with the ref plugin that will be specified on the API
19:03:37 <SridarK> and on the update API as well
19:03:46 <vishwana_> SridarK, to be very specific, Vyatta agent is interested in the events.AFTER_CREATE and events.AFTER_UPDATE
19:04:04 <vishwana_> for resources.ROUTER
19:04:55 <SridarK> vishwana_: ok - lets discuss this more and get back here perhaps ?
19:04:59 <vishwana_> SridarK, pc_m had suggestions of doing the event registration in the common firewallService class....pc_m, can you please share your thoughts
19:05:09 <pc_m> vishwana_: sure
19:05:51 <vishwana_> SridarK, fine by me...perhaps pc_m can provide a summary and we can hash it out later
19:06:14 <pc_m> For VPN, the reference "service" object registers for all the events desired. Then, when those events occur, it calls methods in the service object, which calls the device drivers for some actions.
19:06:22 <SridarK> vishwana_: ok sounds good - so we can do a quick round of topics of interest before we run out of time
19:06:44 <pc_m> For FW, the same could be done. Vendors that want to take actions, can provide a method that the service method could call.
19:06:55 <SridarK> pc_m:  and the device drivers may or may not provide a method
19:07:08 <pc_m> Reference and other vendors can skip the method, and then there would be a NOP.
19:07:10 <SridarK> pc_m: ys
19:07:16 <SumitNaiksatam> pc_m: vishwana_ SridarK: i think supporting the super set of events (consumed by the drivers) is probably a good idea
19:07:44 <SridarK> ok lets do some discussion offline perhaps and report back in the next mtg ?
19:07:45 <SumitNaiksatam> good idea because there is consistency
19:07:57 <pc_m> SumitNaiksatam: yes.
19:08:08 <vishwana_> SumitNaiksatam, pc_m, SridarK, should this be tracked via a bug?
19:08:20 <SumitNaiksatam> vishwana_: i was just thinking about that
19:08:31 <pc_m> yes, probably
19:08:34 <SumitNaiksatam> i think if its a small enough change a bug might be find
19:08:37 <SumitNaiksatam> *fine
19:08:45 <SridarK> perhaps as an enhancement ?
19:09:01 <SumitNaiksatam> i am guessing none of the drivers will have to be changed (except may be vyatta in this case)
19:09:11 <SridarK> so is there interest in interface events as well ?
19:09:16 <SridarK> pc_m: is that supported ?
19:09:31 <SumitNaiksatam> SridarK: good point, i am guessing some vendors will definitely be interested in those
19:09:32 <vishwana_> interface events could be needed as well
19:09:50 <SumitNaiksatam> ideally the rules should be applied at interface granularity
19:09:56 <pc_m> Right now I think there are router events in the L3 agent.
19:10:08 <SumitNaiksatam> ok lets circle back on this
19:10:10 <SridarK> so my confusion here is that i can see the need for interface events
19:10:19 <SridarK> but router events - need more discussion
19:10:26 <SumitNaiksatam> SridarK: vishwana_: you wanted to bring up support for zones?
19:10:29 <pc_m> It's easy to add more notifications in the L3 agent.
19:10:30 <SridarK> SumitNaiksatam: yes lets come back on ths
19:10:35 <SumitNaiksatam> pc_m: agreed
19:10:47 <SridarK> SumitNaiksatam: yes Zones is something we want to bring up
19:10:50 <SumitNaiksatam> SridarK: please go ahead
19:11:08 <SridarK> I think this is something we have had on the table for some time
19:11:24 <SumitNaiksatam> SridarK: true, right from the inception of FWaaS
19:11:26 <SridarK> and it is a fairly common characteristic of FW
19:11:45 <SumitNaiksatam> SridarK: i dont think anyone can disagree on that :-)
19:11:47 <SridarK> one of the things holding it back was being more specific on insertion
19:11:47 <badveli> sridark, currently we were fine with the router creation what events we would be adding
19:12:08 <SridarK> and now this seems a fairly natural thing to take on next
19:12:15 <vishwana_> +1
19:12:20 <SumitNaiksatam> SridarK: +1
19:13:15 <SridarK> ok assuming we are good on moving forward with this
19:13:23 <SridarK> i also want to bring up
19:13:27 <SridarK> #link https://review.openstack.org/#/c/171340/
19:13:31 <SridarK> from Slawek
19:13:46 <SridarK> i think this may be something good to look at as wel
19:13:58 <SridarK> as a simpler model with direction on rules
19:13:58 <slaweq> SridarK: I just want to ask You about review of it :)
19:14:10 <SumitNaiksatam> slaweq: ah thanks for joining!
19:14:14 <SridarK> slaweq: ok good u are here
19:14:17 <SridarK> pls go ahead
19:14:25 <SumitNaiksatam> slaweq: yes, please go ahead
19:14:45 <slaweq> so I propose to add simple "direction" parameter to rules in firewall
19:15:04 <slaweq> to apply rules for example only for ingress chain in L3 plugin iptables
19:15:26 <SumitNaiksatam> slaweq: that’s a nice simple of way of stating it :-)
19:15:59 <yushiro> slaweq, SridarK , I see. I will read your specs :)
19:15:59 <slaweq> :)
19:16:04 <SumitNaiksatam> slaweq: what is the proposed default?
19:16:08 <SridarK> slaweq: i think i have stated my thoughts in the review - in summary there is some overlap with zones - but this is a simpler model
19:16:28 <slaweq> SumitNaiksatam: default is bidirectiona as it is default now
19:16:36 <SridarK> and also not all vendors may support zones so this gives some flexibility from the vendor perspective also
19:16:51 <SumitNaiksatam> slaweq: good, so not specifying the direction would not change the current behavior (or API)?
19:17:11 <slaweq> SumitNaiksatam: should be like that IMHO
19:17:21 <slaweq> to have compatibility with existing rules
19:17:28 <SumitNaiksatam> SridarK: i agree, perhaps support for zones can make use of this internally? (or you think it will be completely independent)
19:17:36 <SumitNaiksatam> slaweq: nice!
19:17:41 <SridarK> SumitNaiksatam: slaweq: yes so this makes it easy for adoption
19:17:56 <slaweq> so that's why I propose Null value as default but some of You asked why not 'bidirectional'
19:18:11 <SridarK> SumitNaiksatam: on the zones overlap there may some differences as there we specify the ingress and egress points
19:18:29 <SumitNaiksatam> SridarK: okay
19:18:42 <SridarK> slaweq: bidirectional is todays behavior so that is good correct ?
19:18:52 <SumitNaiksatam> slaweq: yeah, although “bidirectional” could be set by default as well
19:19:04 <slaweq> yes, AFAIK today rule is apply in both directions always
19:19:22 <badveli> Sumit, the bidirectional should be default
19:19:28 <slaweq> SumitNaiksatam: ok, I have to change that in specs
19:19:35 <slaweq> I will do it today
19:19:48 <SridarK> SumitNaiksatam: so we will work thru this to see that we are not causing any confusion - i think it is fine - i just want to play this thru a bit more to be sure
19:20:19 <SridarK> slaweq: will u be at vancouver ?
19:20:32 <slaweq> SridarK: unfortunately not
19:20:39 <vishwana_> SridarK, this is not going to impact the zone support, right?
19:20:45 <SridarK> slaweq: ok :-(
19:20:51 <SridarK> vishwana_: yes that is correct
19:20:59 <SridarK> vishwana_: we should keep this separate
19:21:01 <vishwana_> ok, thanks
19:21:45 <SumitNaiksatam> okay we have 9 minutes
19:22:18 <SumitNaiksatam> what other features do people have in mind?
19:22:31 <badveli> on the functional tests
19:22:35 <SridarK> SumitNaiksatam: u had mentioned impacts with flavors
19:22:50 <SridarK> earlier
19:22:55 <SumitNaiksatam> SridarK: yes, once that lands in neutron, we will need to support that
19:23:06 <SumitNaiksatam> SridarK: so we will need someone to volunteer for that work
19:23:16 <badveli> to test the traffic as i had mentioned on the other day we can use pinger class
19:23:21 <SumitNaiksatam> in the past gary (varmour) had done the service type support
19:23:29 <SumitNaiksatam> badveli: okay
19:23:37 <SridarK> SumitNaiksatam: yes agreed
19:23:48 <badveli> that internally use name space for exec the ping
19:24:14 <SumitNaiksatam> badveli: we are discussing possible new features for Liberty
19:24:18 <badveli> we can use the similar mechanism of name space and test traffic
19:24:37 <SumitNaiksatam> badveli: i think you are bringing up functional testing
19:24:58 <SumitNaiksatam> badveli: thats a great thing to pursue in Liberty if you are signing up for that
19:25:12 <badveli> sorry we did not get to functional tests, so was updating
19:25:40 <badveli> yes updating on the functional tests, since we did not have agenda
19:26:02 <SumitNaiksatam> so if you have any features in mind for FWaaS please propose a spec to the neutron specs
19:26:14 <SumitNaiksatam> also, if its a longer discussion, add it as a topic to: #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics
19:26:46 <SumitNaiksatam> #topic Open Discussion
19:26:50 <SumitNaiksatam> anything we missed today?
19:26:52 <SridarK> perhaps if u are adding to the ether pad will be good to add it under the FWaaS topics
19:26:59 <SumitNaiksatam> SridarK: good point!
19:27:23 <SumitNaiksatam> lbaas has created a new etherpad and pointed to that etherpad from teh neutron etherpad
19:27:30 <SumitNaiksatam> we could also potentially do something similar
19:27:32 <slaweq> can I ask You one more think about this rules direction specs?
19:28:04 <slaweq> I wan't to ask about API and functional tests section in specs, should I write some such tests for such change?
19:28:30 <slaweq> what should be tested in such tests?
19:28:35 <SumitNaiksatam> slaweq: yes, you wil definitel need UTs
19:28:59 <SumitNaiksatam> slaweq: you will also need to update the tempest API tests for FWaaS which have been now moved to neutron
19:29:03 <slaweq> SumitNaiksatam: about unit tests it is clear for me
19:29:16 <SumitNaiksatam> slaweq: ideally we should also be adding “functional” tests
19:29:26 <SumitNaiksatam> slaweq: however we currently dont have any functional tests
19:29:27 <slaweq> ok, so API tests are in tempest, right?
19:30:38 <SridarK> slaweq: from the spec perspective - u will need to indicate the tests at a higher level
19:30:45 <SumitNaiksatam> slaweq: i was just checking
19:31:36 <SumitNaiksatam> slaweq: lets take it to #openstack-fwaas
19:31:40 <SumitNaiksatam> since we are out of time
19:31:44 <SumitNaiksatam> thanks everyone!
19:31:47 <SumitNaiksatam> bye
19:31:49 <vishwana_> thanks...bye
19:31:49 <slaweq> ok, thx
19:31:54 <pc_m> bye
19:31:57 <yushiro> SumitNaiksatam, thanks  :-)
19:32:01 <SumitNaiksatam> #endmeeting