15:04:38 <pc_m> #startmeeting vpnaas
15:04:39 <openstack> Meeting started Tue Mar 10 15:04:38 2015 UTC and is due to finish in 60 minutes.  The chair is pc_m. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:42 <openstack> The meeting name has been set to 'vpnaas'
15:04:53 <pc_m> #topic Announcements
15:05:32 <pc_m> New experimental queue functional job for StrongSwan is upstreamed.
15:05:57 <pc_m> Gate hooks are also approved, but stuck in gate, due to test breakage.
15:06:28 <pc_m> Plan to make functional job non-voting in check queue next (as soon as gate clears).
15:06:54 <pc_m> Scenario test out for review. needs reviewers. #link https://review.openstack.org/#/c/159746/
15:07:33 <pc_m> StrongSwan implementation out for review. need reviewer (badly). #link https://review.openstack.org/#/c/144391
15:07:45 <pc_m> SridharRamaswam1: Thanks for your reviews!
15:07:58 <SridharRamaswam1> pc_m: sure
15:08:05 <pc_m> Need to finalize on meeting time.
15:08:11 <pc_m> Any other announcements?
15:08:34 <SridharRamaswam1> pc_m: FF deadlines ?
15:09:16 <pc_m> Yeah, for what we have the next date that is important is the 19th to get our commits in. Especially the StrongSwan implementation.
15:09:41 <SridharRamaswam1> pc_m: Thats not far!
15:09:53 <pc_m> RC are 4/9-23, as mentioned in Neutron meeting.
15:10:02 <pc_m> RCs
15:10:41 <pc_m> We can discuss StrongSwan in a bit.
15:10:53 <pc_m> #topic Meeting time
15:11:48 <pc_m> Only consensus we had was to make the meeting on-demand. Kyle mentioned to me that we should reserve an IRC channel for the desired time, and then email, when we want to have a meeting.
15:12:21 <SridharRamaswam1> pc_m: thats a good idea
15:12:22 <pc_m> The votes are 1630 UTC (1), 1600 UTC(2), 1500 UTC (1).
15:14:05 <pc_m> Majority is for 1600 UTC right now. Unfortunately, those that wanted different times aren't here.
15:14:06 <SridharRamaswam1> pc_m: any decision on the slot ?
15:14:59 <pc_m> I guess I can post to ML about 1600 and then see if that is OK. I know it'll be a hard time for Zhang.
15:15:48 <pc_m> #action pc_m to post the proposed time for meetings and to indicate that ML will be used to announce meeting (with update on wiki)
15:16:03 <pc_m> #topic Functional Testing
15:16:25 <SridharRamaswam1> pc_m: l'd also suggest the folks calling for the meeting to update the agenda in the wiki
15:16:31 <pc_m> We can do 'check experimental' to run the StrongSwan based functional test job.
15:16:36 <pc_m> SridharRamaswam1: Sure
15:16:51 <SridharRamaswam1> pc_m: cool!
15:17:25 <SridharRamaswam1> pc_m: it will fail now given strongswan hasn't merged ?
15:17:51 <pc_m> Once 161714 is merged, both openswan and strongswan will run (so we can't use it yet). Should happen today.
15:18:42 <pc_m> SridharRamaswam1: No, the job just runs devstack with StrongSwan selected as the IPSEC_PACKAGE, and selects the drivers. There aren't any REAL test cases yet, only dummy ones.
15:19:15 <pc_m> Once strongswan implementation is upstreamed, and tests are created, they can run against that job.
15:19:36 <SridharRamaswam1> pc_m: got it
15:19:44 <pc_m> (or if one has a test commit that depends on the strongswan commit).
15:20:16 <pc_m> BTW: When the strongswan job runs, it'll run tests in tests/functional/common and tests/functional/strongswan.
15:20:56 <pc_m> Likewise, when the existing openswan job runs, it'll run tests in tests/functional/common and tests/functional/openswan.
15:21:53 <pc_m> I expect we'll get the bug fix merged that fixes UT breakage, and then the gate hook commit will go up and we can do experimental job today.
15:22:13 <pc_m> I will then push out for review a commit to make the job run all the time, non-voting.
15:22:27 <pc_m> That's it for functional testing.
15:22:34 <pc_m> #topic StrongSwan
15:22:55 <pc_m> Zhang says that he's fixed the status issue and PS55 is out.
15:23:38 <pc_m> I looked it over and it looks much better. I did try it once, but it failed to connect up. Removed the connection on one end and reconnected, and it worked.
15:23:53 <SridharRamaswam1> I'll try PS55 as well
15:23:54 <pc_m> So... we need some testing of this (also with other combinations).
15:23:58 <pc_m> SridharRamaswam1: thanks!
15:24:45 <pc_m> I do have concerns on whether or not the mode (auto=add) is right. It seems like it may be manual mode. I asked Zhang if it should be auto=route.
15:24:45 <SridharRamaswam1> I've also started looking at the diffs.. I'm catching up a bit on openswan to level set before commenting on the new strongswan code
15:25:31 <pc_m> I think the goal is we want it working like OpenSwan, where both ends are passively listening for connections and then traffic attempts will cause the negotiation.
15:26:13 <pc_m> We should try multiple connections, disconnect, admin down, deleting connections, and maybe try openswan to strongswan.
15:26:25 <pc_m> Just some ideas to think over.
15:27:07 <SridharRamaswam1> pc_m: I've been trying delete and re-create of one site / side ...
15:27:18 <SridharRamaswam1> pc_m: these are good ideas
15:27:41 <pc_m> SridharRamaswam1: Great the more testing we can do the better.
15:27:45 <pc_m> Oh yeah, Zhang found an issue with the refactoring commit I did. Had a few places still specifying self.agent.foo, instead of self.foo
15:28:07 <pc_m> He has a fix that is out for review. https://review.openstack.org/162840
15:28:23 <pc_m> I commented on it, please check it out. We need to get that in ASAP.
15:28:43 <SridharRamaswam1> pc_m: sure, will take a look
15:28:48 <pc_m> That's all I have on StrongSwan
15:28:54 <pc_m> SridharRamaswam1: Appreciate it.
15:29:02 <SridharRamaswam1> pc_m: np
15:29:08 <pc_m> #topic Bugs
15:29:31 <pc_m> Here's the list... http://goo.gl/LxiN4E
15:30:39 <pc_m> If there are any to highlight (besides the obvious bug fix, ut fix,  and strongswan), speak up.
15:30:59 * SridharRamaswam1 looking
15:31:40 <SridharRamaswam1> pc_m: nothing specific to talk about
15:32:07 <pc_m> #topic Bucket List
15:32:41 <pc_m> This is an area where I've been dropping a list of items that can be done. Feel free to add to this list and sign up to work on items.
15:33:19 <pc_m> It mostly has short term things. We'll need to add longer term and more strategical items at some point.
15:34:28 <pc_m> #topic Open Discussion
15:34:34 <pc_m> Anything else to disscuss?
15:35:02 <SridharRamaswam1> For the Bucket List, I'd like to add DMVPN as a longer term goal
15:35:39 <pc_m> SridharRamaswam1: Sure go ahead. I guess I've been wondering what, as a team, we want to focus on in the future.
15:36:14 <SridharRamaswam1> DMVPN, IMO, make perfect sense from a deployment perspective ..
15:36:40 <pc_m> SridharRamaswam1: I've got to look into that (and figure out how it fits in)
15:36:54 <SridharRamaswam1> I've been reading up quite a bit including options for opensource reference impl for that
15:37:30 <pc_m> Cool. Feel free to post links on the Wiki, may be good for others to see.
15:37:39 <SridharRamaswam1> sure..
15:38:12 <SridharRamaswam1> meanwhile when does the window opens for blueprints for L release ?
15:39:01 <pc_m> SridharRamaswam1: not sure.
15:39:09 <pc_m> We can ask Kyle.
15:39:25 <SridharRamaswam1> Okay, will check w/ him
15:39:32 <pc_m> may not be till after the summit.
15:39:36 <zhhuabj> hi
15:39:38 <pc_m> zhhuabj: Hi
15:40:16 <pc_m> We're at the tail end of the meeting (open discussion). If you have anything to discuss... nows your chance!
15:40:47 <zhhuabj> 1, for https://review.openstack.org/#/c/162887/
15:40:59 <pc_m> BTW, the majority seems to want 1600 UTC for this meeting, so we'll like move there.
15:41:13 <zhhuabj> why jenkins always failure
15:42:11 <pc_m> Yes, it sometimes fails due to other reasons. I had done a recheck, and you did another. It is almost finished and I think it may pass this time.
15:42:19 * pc_m fingers crossed
15:42:35 <pc_m> It is running Grenade test right now and almost done.
15:43:11 <zhhuabj> recheck or reverify, I remember it should be reverify, am I wrong ?
15:43:16 <pc_m> Once merged, we can rebase other commits.
15:43:43 <pc_m> I was told that reverify is deprecated and just does a recheck now.
15:43:58 <pc_m> so same thing
15:44:20 <pc_m> #2?
15:44:23 <pc_m> :)
15:45:18 <pc_m> you don;t need to do it again...
15:45:36 <zhhuabj> #2, what do you mean of this comment in the link https://review.openstack.org/#/c/162840/1/neutron_vpnaas/services/vpn/device_drivers/ipsec.py
15:45:38 <pc_m> It's running in the queue right now, and almost done.
15:45:57 <zhhuabj> why we don't need to delete _delete_vpn_processes() ?
15:47:10 <pc_m> In the patch _delete_vpn_processes() was removed. It did two things. One, delete the process(es) and two delete the router(s).
15:47:21 <pc_m> Don't we still need it to delete the processes?
15:48:22 <pc_m> I would have thought we'd only want to remove the self.destroy_router() call
15:48:48 <pc_m> zhhuabj: Make sense?
15:49:31 <zhhuabj> the first thing seems be 'self.ensure_process(process_id)' , not delete the process(es)
15:50:54 <pc_m> zhhuabj: The old code did ensure_process() and then destroy_router(). Now, destroy_router() is broken into two parts, destroy_process() and code to remove the router.
15:50:56 <zhhuabj> _delete_vpn_processes method do the following two things for the router without vpnservices
15:50:56 <zhhuabj> self.ensure_process(process_id)
15:50:57 <zhhuabj> self.destroy_router(process_id)
15:51:14 <pc_m> I would think we still want to call destroy_process().
15:51:34 <pc_m> That will remove the process entry.
15:51:54 <zhhuabj> oh, I see, make sense, thanks :)
15:52:46 <pc_m> I think just changing destroy_router() with destroy_process(). I really don't know why they have the ensure_process() call there.
15:52:52 <zhhuabj> #3, for strongswan, do you want me to try 'add=route' ?
15:53:34 <zhhuabj> ensure_process is here in case of process doesn't exist I think
15:54:49 <pc_m> I thought it was adding it, if it doesn't exist, and then we are turning around and deleting it... I may be wrong.
15:54:52 <zhhuabj> 'auto=add' can work, today I make many test, every time the status has becames ACTIVE
15:55:33 <pc_m> It failed for me. My concern is that it appears to be manual config. I wonder if it will stop trying to negotiate if it fails once.
15:55:47 <pc_m> Wondering if route mode will continue to try.
15:56:11 <pc_m> It may be good to explore using that, just to see what the behavior is.
15:56:34 <pc_m> With auto=add, I tried today, and it failed to come up. I removed on one end and recreated, and it worked.
15:56:39 <pc_m> hence the concern.
15:57:49 <pc_m> WE can all test it out. If you get a chance, look into the route option (I'm wondering if that will be the same as the openswan passive mode).
15:58:03 <pc_m> We've got 3 mins. Anything else quick?
15:58:05 <zhhuabj> ok, I will try 'auto=route', and give you the result.
15:59:04 <zhhuabj> but I always be ok today by using 'auto=add' both in ubuntu 14.10 with strongswan and in ubuntu 14.04 with openswan, however, later I will test it again.
15:59:38 <mwang2> o/
15:59:45 <pc_m> zhhuabj: I'm doing 14.04 with sswan and had a failure once.
15:59:53 <pc_m> We;re out of time...
15:59:59 <pc_m> #endmeeting