18:32:20 <SridarK> #startmeeting Networking FWaaS
18:32:21 <openstack> Meeting started Wed Jul 29 18:32:20 2015 UTC and is due to finish in 60 minutes.  The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:32:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:32:25 <openstack> The meeting name has been set to 'networking_fwaas'
18:32:44 <SridarK> #topic Bugs
18:32:54 <SridarK> from last week:
18:33:07 <SridarK> or rather last mtg
18:33:12 <SridarK> #link https://bugs.launchpad.net/neutron/+bug/1474279
18:33:13 <openstack> Launchpad bug 1474279 in neutron "FWaaS let connection opened if delete allow rule, beacuse of conntrack" [Undecided,Incomplete]
18:33:34 <SridarK> this may be a non issue and could be related to the conn track - thanks to Elena for following up on this
18:33:54 <SridarK> new:
18:33:58 <SridarK> #link https://bugs.launchpad.net/neutron/+bug/1477097
18:33:59 <openstack> Launchpad bug 1477097 in neutron "fwaas: firewall in error status after update firewall-rule " [Undecided,New] - Assigned to Sridar Kandaswamy (skandasw)
18:34:36 <SridarK> i just assigned it to myself for a quick eval - i think we have fixed some code around here - so lets see
18:35:06 <SridarK> anything else noteworthy that others might be aware of
18:35:07 <SridarK> ?
18:35:42 <SridarK> badveli: did u find anything else as u were checking ?
18:36:12 <badveli> nothing much but should we see the linkhttps://bugs.launchpad.net/openstack/+bugs?field.searchtext=fwaas&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_p
18:36:34 <badveli> sridar some of them are low priority
18:36:54 <SridarK> badveli: yes those are fine and some are not directly related
18:37:18 <SridarK> badveli: so if u have nothing more that u have seen to raise concern we can move on
18:37:28 <badveli> fine sridark
18:37:43 <SridarK> #topic Service Objects/Group
18:38:00 <SridarK> badveli: things u would like to bring up, update or discuss
18:38:06 <badveli> yes i am facing an issue with my patches
18:38:12 <badveli> mailed pc_m
18:38:29 <badveli> for some reason when i added the service group extension
18:38:41 <badveli> the unit tests are failing because of
18:38:43 <pc_m> badveli: So that today (back from PTO), wasn't sure what it was about.
18:39:04 <badveli> raise webob.exc.HTTPClientError(code=res.status_int)      webob.exc.HTTPClientError: The server could not comply with the request since it is either malformed or otherwise incorrect.
18:39:20 <badveli> i am getting this while running my unit tests
18:39:24 <pc_m> badveli: Is there a patch up for review?
18:39:40 <SridarK> badveli: but are u able to manually exercise ur extension ?
18:39:42 <badveli> yes but because of this issue its not proper
18:40:11 <badveli> sridark did not get your point, are you asking i am able to see the extension in neutron via cli?
18:40:36 <badveli> previously this code used to work
18:40:58 <badveli> i am trying to check what is the correct way to write an extension
18:41:09 <SridarK> badveli: no are u able to send a REST command to see if the server is picking it up and ur extension is picking it up
18:41:11 <badveli> looks like this is the way from the existing examples
18:42:02 <SridarK> badveli: u can also look at the router extension work in Kilo for a sample - i can help u as well
18:42:12 <badveli> sridark did not check that but as far i think
18:42:30 <badveli> get_resources,get_extended_resources
18:42:41 <badveli> should do that, thanks sridark
18:42:59 <SridarK> badveli: i was trying to ascertain if the issue is only on UT or u have a problem even when u are testing it manually ?
18:43:35 <badveli> fine sridark did not had much time to spend, i will check that and mail
18:43:48 <SridarK> badveli: sounds good
18:44:14 <badveli> thanks sridark, some thing has changed in kilo looks like the previous code is not working any more
18:45:33 <SridarK> badveli: hmm! okay we can discuss offline then ?
18:45:43 <badveli> yes, thanks
18:45:52 <SridarK> ok np
18:46:08 <SridarK> #topic Logging Spec
18:46:19 <SridarK> #link https://review.openstack.org/#/c/132133/
18:46:29 <hoangcx> Hi SridarK and all
18:46:33 <SridarK> #link https://bugs.launchpad.net/neutron/+bug/1468366
18:46:35 <openstack> Launchpad bug 1468366 in neutron "RFE - Packet logging API for Neutron" [Undecided,Confirmed] - Assigned to Yushiro FURUKAWA (y-furukawa-2)
18:46:38 <SridarK> hoangcx: hi
18:46:40 <hoangcx> FWaas logging is still discussing at packet-logger API spec as the following #link https://review.openstack.org/#/c/203509/
18:46:47 <SridarK> ok
18:47:10 <hoangcx> Please help us to review packet-logger spec.
18:47:40 <xgerman> #action review https://review.openstack.org/#/c/203509/
18:48:02 <SridarK> hoangcx: yushiro is not here today, there was query on the older spec - perhaps one of u should respond that u have moved to bug with rfe
18:48:05 <hoangcx> xgerman: Thanks a lot
18:48:09 <jwarendt> Thanks for pointing out.
18:48:31 <SridarK> thanks hoangcx: will do so
18:48:45 <hoangcx> SridarK: ah, I see.
18:49:43 <SridarK> hoangcx: anything else u want to bring up
18:50:06 <hoangcx> That's all for me. and waiting review
18:50:19 <SridarK> hoangcx: ok thanks for the update
18:50:40 <SridarK> #topic SG - FWaaS alignment
18:50:52 <SridarK> #link https://etherpad.openstack.org/p/fwaas_use_cases
18:51:02 <xgerman> #link https://trello.com/b/TIWf4dBJ/fwaas-usecase-categorization
18:51:04 <SridarK> #link https://etherpad.openstack.org/p/fwaas-api-evolution-spec
18:51:12 <xgerman> we moved the use cases int eh troll board and sorted them
18:51:17 <SridarK> over to xgerman:
18:51:39 <xgerman> ok, so at the L4-L7 mid cycle we moved all the use cases into the troll board (linked)
18:51:46 <SridarK> firstly a huge thanks to xgerman: and sc68cal:  for all the inputs here
18:52:06 <SridarK> xgerman: that was the next link - u beat me to it :-)
18:52:12 <xgerman> :-)
18:52:12 <SridarK> pls go ahead all yours
18:52:24 <jwarendt> Please correct any obvious mistakes if you see them...
18:52:39 <xgerman> +1
18:52:51 <SridarK> jwarendt: no thanks to u as well - i saw ur updates as well
18:52:58 <sballe> xgerman: wasn't the next step to look at the existing APIs and see what is missing and if we can even reuse them
18:53:07 <xgerman> yep
18:53:07 <SridarK> i felt this was great first step
18:53:24 <SridarK> sballe: agree on this
18:53:44 <sballe> We have the use cases and then we now need to do a deep dive on the APIs and see where we go from tehre
18:53:52 <xgerman> +1
18:54:16 <SridarK> In looking at the Gaps column - there were a few things which i believe can be addressed in a prioritized manner
18:54:20 <sballe> What is a good way to move forward from tehre?
18:54:31 <sballe> SridarK: I agree
18:54:35 <xgerman> +1
18:54:38 <SridarK> and over all i am in total agreement in ur categorization of the buckets
18:54:44 <sballe> cool!
18:54:52 <xgerman> great!
18:54:56 <SridarK> clearly things like DPI are all great but for the future
18:54:58 <badveli> xgerman trying to see why we have two columns covered by sg and fwaas
18:55:44 <mickeys> I agree with most of the categorization, but I do have some comments. I could not add myself to the Trello board, looks like people need to be added manually by people with permission. Then I will be able to comment in Trello.
18:56:06 <xgerman> what’s your e-mail and then I can add you
18:56:11 <sballe> badveli Wen we did it it was because we wanted to see what SG covered and what FW covered. Does that answer the quesiton
18:56:54 <vishwanathj_> xgerman: please add mine as well vishwanathj@hotmail.com
18:56:55 <mickeys> emspiege@us.ibm.com
18:57:02 <badveli> thanks sballe but putting two things one working at port level
18:57:21 <badveli> and the other one fwaas
18:57:22 <SridarK> As distilled one line summary - i saw these as a priority: Notion of direction (for outbound reputation), Hit Counters, Audit logs, Point of application (different rules to different ports), Notion of Zones
18:57:31 <sballe> We did it this way because we wanted to see where the overlap
18:57:31 <mickeys> If we go for a common superset API, then all of the SG covered items need to be covered by the enhanced FWaaS API
18:57:58 <xgerman> bedevil let's not get too involved into technical details
18:58:01 <sballe> mickeys: That was our thoughts too
18:58:12 <xgerman> we were just looking at use cases not bow they are implemented
18:58:15 <badveli> i think both can cover different use cases
18:58:36 <badveli> ok thanks
18:59:26 <xgerman> mickeys we were thinking less about a superset API but more of both APIs sharing a common backend
18:59:53 <mickeys> Sridar: A big one for me is the ability to refer to a group of addresses or ports, as security groups do today through remote security group
19:00:43 <mickeys> If not a superset API, then are we talking about a new security group API in addition to the existing one? So that we can extend and add functionality?
19:00:58 <SridarK> mickeys: yes i believe i had that on my next list (from the SG + FWaaS column) - and i agree
19:01:21 <badveli> thanks mickeys  initially  we wanted to introduce service groups and then address groups
19:01:51 <mickeys> badveli: No argument with service groups, just saying we need the other one as well
19:01:52 <SridarK> mickeys: can we may be go thru the feature list first and then we can discuss the API coexistence or we can do that first
19:02:16 <xgerman> I think we should make the backends be the same
19:02:31 <mickeys> Sridar: Just wondering what our context is, one superset API or separate APIs. If that is still open, fine as long as we are all on the same page
19:02:54 <SridarK> mickeys: yes so lets get the feedback out on the coexistence first
19:03:00 <sballe> I agree with xgerman. To me the SG is there to have compatiblity with AWS.
19:03:26 <sballe> so we need to mkae sure SG API stay compatible
19:03:32 <SridarK> sballe: , xgerman: did u get that kind of consensus in the mid cycle ?
19:03:34 <sballe> or close to the same
19:03:40 <mickeys> sballe: Many of us want SG functionality with extensions/enhancements. We need a way forward with that, whether that is an additional SG API or an enhanced superset FWaaS API.
19:03:55 <xgerman> yes, it’s difficult to replace SG since they are a “stable” API
19:03:56 <mickeys> In addition to the existing SG API which remains for AWS compatibility
19:04:07 <sballe> Agreed. I personally like an enhanced superset FWaaS API.
19:04:12 <jwarendt> +1
19:04:16 <SridarK> sballe: +1
19:04:16 <xgerman> +1
19:04:23 <mickeys> +1
19:04:35 <sballe> cool! we are all in agreement :-)
19:04:52 <SridarK> sballe: but was that the direction at the mid cycle as well ?
19:05:20 <xgerman> yes, we also entertained minor enhancements to SG but the bulk should be in FWaaS
19:05:36 <xgerman> big consensus was to use the same backend
19:05:38 <badveli> the superset fwaas API will most likely cover the use case
19:05:49 <sballe> sorry I am back...
19:05:51 <SridarK> xgerman: on the backend that totally makes sense
19:05:54 <badveli> that are not part of SG
19:06:00 <sballe> yes as xgerman said above
19:06:30 <SridarK> this is good that we have approaching some consensus on the API relationship
19:06:38 <SridarK> *are
19:07:11 <badveli> the reason i am trying to say is because of the implementation issues we might not be able to extend the existing SG
19:07:36 <SridarK> my personal take also was that the AWS compat was a big issue that is important from a deployer perspective
19:07:41 <badveli> and mostly we can use the superset fwaas API for most of the use cases on the etherpad
19:08:05 <sballe> SridarK: +1
19:08:07 <xgerman> well, there might be use cases which only make sense for SG...
19:08:15 <sballe> +1
19:08:55 <mickeys> xgerman: Depending on how we enhance the FWaaS API, we may be able to cover most of the SG use cases. I hope that is feasible, but we need to flesh that out to be sure.
19:09:16 <jwarendt> But should still share backend mechanisms even if SG unique use case if possible.
19:09:23 <sballe> mickeys: I agree and I feel we need to start the investigation
19:09:36 <SridarK> mickeys: would those mostly involve on where the rules are applied ?
19:10:04 <mickeys> Yes, if we can associate a firewall or firewall policy with a security group
19:10:11 <mickeys> Also the remote stuff that I mentioned earlier
19:10:38 <mickeys> Whether that is the same notion of security group is a major question that we may need to think about
19:11:04 <SridarK> mickeys: okay but what if we can associate a FW at VM port level ?
19:11:23 <badveli> sridark since the SG applies at port level
19:11:32 <SridarK> badveli: yes
19:11:37 <mickeys> Sridar: That is useful as well, and I would like all of that to be in the same API, but that is not SG functionality.
19:11:37 <xgerman> well, we should make that a use case if that is needed
19:12:15 <mickeys> I asked for ports and for groups, and I believe that is mostly captured in Trello. There was one requirement I had that was left out, probably needs clarification.
19:13:57 <badveli> Sridark when we tie up to the port level we might be in a difficult situation if we need to provide more use cases
19:14:44 <SridarK> badveli: the port (VM port) is a SG thing for sure
19:14:58 <mickeys> Tying to port level would not be mandatory, it would be an option, up to the user. Where this gets tricky is if a customer specifies multiple overlapping policies with different associations.
19:15:32 <xgerman> yep, we talked about hsoe validations and how we should delegate them to the appliance
19:15:34 <mickeys> Can a customer define one firewall or policy at tenant granularity, and another associated with a port?
19:15:43 <badveli> yes
19:16:00 <badveli> it is very tricky
19:16:08 <SridarK> mickeys: in theory yes, but at this point the association is only with router(s)
19:16:09 <xgerman> hence, my handwaving
19:17:06 <SridarK> The first step may be even at the router i/f level (so different networks can get diff FW associations)
19:17:11 <badveli> mickeys what is the benefit of tie the policy to a port
19:17:30 <SridarK> now if we should get to the VM port level - that is open
19:18:14 <SridarK> mickeys: i think there is value in not having to replicate rules sets across SG and FW
19:18:24 <jwarendt> .+1
19:18:26 <sballe> SridarK: +1
19:18:31 <mickeys> This all ties into the operator versus user (application deployer) aspect in the use cases. If we allow different types of associations that may overlap in arbitrary ways, then the distinction between what an operator wants and what a user wants does not have to be addressed in the API explicitly. The alternative, if we do not, then at a minimum we need to allow overlapping of one operator firewall or policy and one user firewall or policy o
19:18:31 <mickeys> r SG
19:19:25 <mickeys> To the user/application deployer, port is clearly useful
19:20:47 <SridarK> we probab should be careful on the overlap so that we have no confusion
19:21:22 <xgerman> well, it will be difficult for the API to know so it could only be raised at appliance level
19:21:38 <sballe> +1
19:21:56 <SridarK> operator owned resource can be marked shared - but that may not solve this perfectly (i can't share with a specific tenant)
19:22:14 <badveli> this is where the problem lies and making SG at port level and the fwaas as it is might be fine?
19:23:08 <mickeys> badveli: I hope we can get something more flexible, but we need to figure out what this means in terms of overlap, ACL merge type issues, etc. If this looks too hairy, at a minimum, what you said.
19:23:29 <badveli> +1
19:23:35 <jwarendt> <badveli> SG has some warts but is limited by AWS legacy, part of why extended FWaaS as superset in that direction is appealing.
19:23:56 <SridarK> mickeys: i think we can go to the etherpad for more articulation on the overlap cases
19:24:06 <mickeys> +1
19:24:10 <xgerman> mickeys +1 Though I think some applicances so a better job with conflict resolution than others - so it’s an implementation detail for me
19:24:24 <SridarK> so i think in summary - we like having 2 APIs but we still need to work out the kinks on the overlap cases
19:25:11 <xgerman> well both APIs drive the same backend which then can deal with the overlap (aka throw an error)
19:25:25 <xgerman> or intelligently resolve
19:25:55 <mickeys> Sridar: Not clear what you mean by 2 APIs and where the consensus is. I think there is strong consensus behind the existing SG API for AWS compatibility, and some sort of enhanced FWaaS API. The part where I am not clear is whether the enhanced FWaaS API becomes a superset of FWaaS and SG functionality, or whether we go to 3 APIs: Old SG, new enhanced SG, new FWaaS.
19:26:00 <badveli> xgerman you give lot of work
19:26:27 <xgerman> mickeys let’s stick to two APIs
19:26:51 <xgerman> we put all the new stuff into FWaaS, maybe minor enhancements into SG
19:26:57 <badveli> 3 API's seems easier
19:27:09 <sballe> yeah not three APIs. FW is still expermental so we don't have to keep things around
19:27:13 <mickeys> That is my preference. We have to work to do to incorporate enhanced SG functionality into the enhanced FWaaS API.
19:27:19 <SridarK> mickeys: i am saying exactly the same thing but on the 3 APIs - i am still a bit on the wall
19:27:32 <sballe> mickeys: +1
19:27:38 <xgerman> +!
19:27:40 <xgerman> +1
19:28:07 <SridarK> +1
19:28:19 <SridarK> ok folks time keeper kicks in
19:28:34 <SridarK> so we can continue more articulation on the etherpad
19:28:41 <xgerman> or trello
19:28:41 <sballe> oh no we were having so much fun :-)
19:28:46 <SridarK> but this is great
19:28:48 <mickeys> I assume we are referring to the API evolution etherpad?
19:28:49 <xgerman> +1
19:28:55 <SridarK> mickeys: yes
19:29:13 <SridarK> #topic Open Discussion
19:29:24 <SridarK> anything folks wanted to bring up
19:29:28 <SridarK> before we close out
19:29:33 <xgerman> in 60s
19:29:44 <badveli> xgerman are we tracking using etherpad or trello
19:29:56 <SridarK> this was an hour well spent
19:30:06 <xgerman> I am mostly on the ether pad those days but can copy things over
19:30:19 <badveli> ok thanks
19:30:23 <SridarK> xgerman: +1 lets do that
19:30:24 <xgerman> trello
19:30:34 <xgerman> actually I men trello
19:30:53 <SridarK> ok we end
19:31:00 <vishwanathj_> Bye
19:31:01 <badveli> ok thanks
19:31:03 <SridarK> #endmeeting