18:32:38 <SridarK> #startmeeting Networking FWaaS
18:32:38 <openstack> Meeting started Wed Jul 15 18:32:38 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:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:32:42 <openstack> The meeting name has been set to 'networking_fwaas'
18:33:35 <SridarK> sorry abt connectivity issues last mtg and thanks all for helping
18:33:41 <SridarK> #topic Bugs
18:34:08 <SridarK> #link https://bugs.launchpad.net/neutron/+bug/1474279
18:34:08 <openstack> Launchpad bug 1474279 in neutron "FWaaS let connection opened if delete allow rule, beacuse of conntrack" [Undecided,New] - Assigned to Elena Ezhova (eezhova)
18:34:20 <SridarK> new one i see and it just get picked up by Elena
18:34:39 <SridarK> any others that folks are aware of causing some concerns
18:34:46 <SridarK> ?
18:35:30 <SridarK> ok lets move on
18:35:41 <SridarK> #topic Service Objects/Group
18:35:49 <SridarK> badveli: all yours
18:36:22 <badveli> i am working on a wip patch
18:36:28 <badveli> not yet there
18:36:56 <SridarK> badveli: ok, can u pls share the link
18:37:31 <badveli> i could spend little time on neutron patch and scenario tests
18:37:43 <SridarK> badveli: so we will have one on neutron and another patch on neutron_fwaas ?
18:37:55 <SridarK> badveli: ok
18:38:00 <badveli> yes scenario tests for neutron-fwaas
18:38:16 <badveli> the patch is only scenario tests in neutron-fwaas
18:38:46 <SridarK> badveli: ok there will be a backend on fwaas as well eventually ?
18:39:24 <badveli> should be as the reference model
18:39:44 <SridarK> badveli: ok perfect, anything else to add or discuss ?
18:40:03 <badveli> but initially to make progress i am concentrating on neutron patch and use the service objects in scenario tests
18:40:23 <SridarK> badveli: yes that definitely makes sense
18:40:55 <badveli> but i need pc_m help
18:41:01 <badveli> to set up the scenario tests
18:41:07 * pc_m ears perk
18:41:13 <SridarK> :-)
18:41:14 <badveli> he asked me to add a job
18:42:04 <badveli> i am not there yet,
18:42:26 <SridarK> badveli: ok, do u want to discuss now with pc_m or take it up offline ?
18:43:32 <pc_m> SridarK: whatever works is OK with me
18:43:42 <badveli> i would like to discuss, since we have not yet have a similar model as vpnaas
18:44:06 <badveli> i can take it up offline
18:44:17 <SridarK> badveli: ok cool
18:44:24 <SridarK> lets move on then
18:44:40 <SridarK> #topic Logging Spec
18:44:41 <pc_m> badveli: Just ping me, when you need help.
18:44:54 <SridarK> yushiro: hoangcx: all yours
18:45:01 <yushiro> hi, SridarK long time no see :-)
18:45:13 <badveli> thanks pc_m
18:45:21 <SridarK> yushiro: yes good to c u
18:45:25 <SridarK> :-)
18:45:44 <yushiro> currently,  we've already implemented new logging API patch.
18:46:06 <yushiro> So,  I'd like to update my spec and WIP.
18:46:16 <SridarK> yushiro: great
18:46:35 <yushiro> RFE - Packet logging API for Neutron. 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:59 <yushiro> And, I'd like pc_m 's help...
18:47:21 <vishwanathj> I vote for cloning pc_m :)
18:47:25 <SridarK> pc_m: is a great help all the time :-)
18:47:29 <SridarK> vishwanathj: +1
18:47:32 <SridarK> :-)
18:47:45 <pc_m> :)
18:47:49 <yushiro> pc_m, I'd like to ask your review in my RFE :-)
18:47:54 * pc_m needs a clone already.
18:48:02 <pc_m> yushiro: Sure will add to my list.
18:48:51 <yushiro> SridarK, pc_m  Our target is 'Liberty' to implement logging feature.
18:49:04 <SridarK> yushiro: yes understood
18:49:54 <SridarK> yushiro: anything else u would like to bring up ?
18:50:21 <yushiro> SridarK, It's OK.  I'll update my fwaas spec and WIP :-)
18:50:30 <SridarK> yushiro: ok thanks
18:51:09 <SridarK> #topic SG - FWaaS alignment (FWaaS Usecases)
18:51:23 <SridarK> #link https://etherpad.openstack.org/p/fwaas_use_cases
18:51:29 <SridarK> xgerman: over to u
18:52:09 <SridarK> thanks to all for adding more inputs here, i tried to summarize into buckets (broadly) around L#131
18:52:52 <mickeys> There is a lot of stuff there. Do we need to prioritize requirements? How?
18:53:18 <SridarK> mickeys: yes hence a first stab at putting it into broader buckets
18:53:26 <SridarK> then we can start prioritizing
18:54:03 <SridarK> Not sure if xgerman: is away, we can continue the discussion
18:54:30 <mickeys> I guess he is at the mid-cycle summit. Does not seem like FWaaS will have quorum there.
18:54:33 <jwarendt> xgerman is at mid-cycle meetup
18:55:32 <SridarK> ok - lets continue with discussion and this is probab going to take some amount of iterations and we can pick it up with xgerman next time
18:55:53 <jwarendt> The usecase document is open for input though
18:56:15 <SridarK> jwarendt: yes
18:56:23 <mickeys> In Vancouver, it seemed like many key Neutron developers had strong opinions on SG - FWaaS alignment, but we have not heard from the in a while. Any idea how to include them so there are no surprises just as we think we are getting consensus?
18:56:37 <SridarK> As i saw it one set of requirements focussed on the point of insertion of the FW
18:56:42 <sc68cal> I was actually writing up a spec to address this
18:56:46 <sc68cal> https://etherpad.openstack.org/p/fwaas-api-evolution-spec
18:56:53 <SridarK> VM ports, routers, router interfaces ...
18:56:57 <SridarK> sc68cal: hi
18:56:58 <jwarendt> Will try to get midcycle input into that doc.
18:57:19 <SridarK> sc68cal: great this is a good place to capture the results of the discussion
18:58:03 <SridarK> mickeys: yes, point taken - i am hoping that requirements that folks come up will drive that decision
18:58:09 <sc68cal> I basically had strong opinions about the SG api (no changes to it), and how the FwaaS API is where everyhting should go, so I am writing a spec to collect my thoughts and document what I've been saying at the midcycle
18:58:53 <SridarK> sc68cal: +1
18:59:11 <jwarendt> +1
18:59:18 <SridarK> the use case etherpad has mostly focussed on fwaas requirements
18:59:25 <hoangcx> +1
18:59:35 <yushiro> sc68cal, great.  I'd like to attend midcycle :-)
18:59:45 <mickeys> I put in some requirements from the point of view of both security groups and fwaas
19:00:10 <SridarK> mickeys: and i think u made a point that u had no religion on this
19:00:17 <sc68cal> yushiro: We actually have a hangout open, for remote attendees
19:00:29 <sc68cal> it's on the etherpad https://etherpad.openstack.org/p/LBaaS-FWaaS-VPNaaS_Summer_Midcycle_meetup
19:01:12 <SridarK> sc68cal: thanks
19:01:20 <mickeys> Sridar: Yes, as long as there is a path for future extensions to security group functionality
19:02:06 <SridarK> sc68cal: perhaps with ur spec if manage to capture the sentiment at the mid cycle that will be good input
19:02:20 <jwarendt> The use case IMHO is what customer needs - whether done in SG or FWaaS is really a detail, do not want to limit meeting customer needs just by OpenStack internal boundaries.
19:02:22 <SridarK> in addition to the requirements
19:02:52 <sc68cal> SridarK: agreed - I plan on doing that and sharing with the community to see if there is consensus in the wider community for whatever conensus we build at the midcycle
19:03:00 <SridarK> jwarendt: yes coming at it from use cases would be right thing
19:03:12 <SridarK> sc68cal: great thanks
19:03:47 <xgerman> we will keep him honest :-)
19:03:59 <SridarK> xgerman: hi :-)
19:04:16 <xgerman> hi
19:04:39 <SridarK> xgerman: we got the ball rolling on the use cases
19:04:44 <SridarK> pls chime in
19:04:45 <xgerman> yep
19:05:15 <xgerman> I think we are ready for the next step so we will weight in on the spec
19:05:19 <badveli> jwarendt but using security groups for advanced use case will it be feasible
19:06:11 <SridarK> xgerman: perhaps a bit more time is needed for folks to digest the contents and then we can start a prioritized list
19:06:23 <SridarK> at least on the use cases
19:06:49 <SridarK> the SG - FWaaS API is a bit more complicated, but hopefully the use cases can drive the discussion there
19:06:49 <xgerman> yeah, we will definitely keep an eye on it and adjust as we go
19:07:42 <SridarK> and sc68cal: 's spec
19:09:07 <sc68cal> btw the spec is just as an etherpad so if you have thoughts chip in :)
19:09:16 <xgerman> +1
19:09:19 <SridarK> sc68cal: surely
19:09:35 <badveli> thanks sc68cal
19:09:54 <jwarendt> +1 on usecases driving discussion <Sridark>
19:11:42 <mickeys> The other thing we should discuss is the flow classifier proposal: https://etherpad.openstack.org/p/flow-classifier
19:11:57 <SridarK> Perhaps we can start the exercise of collating all inputs to some buckets ( i took a very prelim stab at it - pls feel free to edit) so we can get rid of duplicates for each persons inputs and start building out a list
19:11:57 <mickeys> They mention FWaaS and Security Groups explicitly.
19:12:11 <SridarK> then we can prioritize
19:12:37 <mickeys> +1
19:12:48 <jwarendt> +1
19:14:07 <SridarK> ok good lets try to do that then but we can preserve the contents from the folks who put their inputs and we can build this out towards the bottom
19:14:25 <badveli> mickeys, jwarendt to me it looked like we should atleast check the feasabiltiy of the use cases implementation
19:14:56 <badveli> we cannot say the use cases can be done in either security groups or fwaas
19:15:09 <SridarK> badveli: at least once we have the use cases, the next round in addition to prioritization we can do the feasibility
19:15:46 <mickeys> badveli: Not sure how to capture feasibility. Hopefully people take that into account during prioritization.
19:16:51 <SridarK> or at least call it out in terms of SG/FWaaS
19:16:51 <badveli> thanks
19:17:13 <badveli> yes i think that makes more sense
19:17:44 <SridarK> ok so perhaps we can run thru this exercise over the next couple of days so we can target to have a list for discussion by the next meeting
19:17:58 <jwarendt> +1
19:18:57 <SridarK> cool we can possibly discuss this forever, so unless there is something else very critical, lets move on
19:19:02 <SridarK> :-)
19:20:12 <SridarK> we hope that xgerman: & sc68cal: would have all the answers for us, solved world hunger, gotten us to world peace etc etc when they are back from the mid cycle :-)
19:20:39 <jwarendt> +1000
19:20:52 <SridarK> on that note of optimism lets move on
19:21:01 <SridarK> #topic Open Discussion
19:21:09 <SridarK> pc_m: pls go ahead
19:21:13 <SridarK> and others as well
19:21:14 <pc_m> SridarK: I have a few things to mention to the team, in case you folks are not aware of them...
19:21:39 <pc_m> 1) Grenade job has been modified to disable services, so no service based migrations are tested.
19:21:54 <SridarK> i am just catching up after PTO so every thing is news to me :-)
19:22:10 <pc_m> This implies that in the future we should have service based Grenade jobs.
19:22:21 <SridarK> ok and we will need to get them set up
19:22:45 <pc_m> 2) Should also do a Grenade plugin for service
19:23:15 <pc_m> 3) Should do a DevStack plugin too.
19:23:52 <pc_m> I did one for VPNaaS and it has some dependencies on FW plugin (config file). It has been approved and will upstream as soon as we fix breakage
19:24:13 <SridarK> ok
19:24:24 <pc_m> 4) Migration is being modified to support live-migration in Neutron. The services will be updated too. VPN will be guinea pig
19:24:31 <vishwanathj> pc_m, do you mind sharing the patchset link for the VPANaas.Thanks
19:25:08 <pc_m> 5) Related to migration, for VPN, we had a check-migration test under PEP8. It is now broken due to the migration changes.
19:25:18 <SridarK> So on (4) we have to wait till VPNaaS settles in ?
19:25:20 <pc_m> I have a patch that disables that check for VPN.
19:25:52 <pc_m> SridarK: Yeah, they have to do neutron and then each of the services. Requires directory structure change.
19:26:01 <SridarK> pc_m: ok thx
19:26:20 <pc_m> I hit issues with Grenade, and found that it is broken for services. Hence #1.
19:27:35 <SridarK> ok thx pc_m: for the info
19:27:40 <pc_m> So, if you do any change with db migration, it'll need manual checking.
19:27:52 <pc_m> SridarK: sure, np/
19:29:06 <SridarK> Any one else have other things to bring up as we are near to closing
19:29:11 <mickeys> Flow classifier
19:29:13 <pc_m> all set
19:29:33 <badveli> pc_m could you please clarify if we add a upgrade(for example in my case service group does change the db migration by addding a new file)
19:29:58 <badveli> what do you mean by manual checking
19:30:16 <pc_m> badveli: So, grenade disabled FW, so it won't be tested now (at all). You'll need to manually test.
19:30:45 <pc_m> Until you create a FW grenade job, and that will be delayed, until all this migration change is done.
19:30:46 <badveli> ok thanks pc_m
19:30:59 <mickeys> Flow classifier: For Security Groups, I think it is a clear no go due to backwards compatibility and alignment with Amazon
19:31:26 <mickeys> For FWaaS, I personally don't have a strong opinion, but I suspect many of you want backwards compatibility, so you might want to speak up and say it is too late to change the FWaaS model to a common classifier
19:31:37 <SridarK> mickeys: and other issues on the compat that sc68cal: brought up at YVR as well
19:31:44 <mickeys> If FWaaS did go with a common classifier, then service object/group would need to move there
19:31:46 <vishwanathj> Friendly reminder: we are past the hour
19:31:53 <SridarK> vishwanathj: yes
19:32:01 <SridarK> mickeys: sorry lets close out now
19:32:13 <pc_m> bye!
19:32:14 <SridarK> mickeys: add it to the etherpad
19:32:23 <yushiro> bye bye :-)
19:32:27 <SridarK> #endmeeting