16:02:53 <pc_m> #startmeeting vpnaas
16:02:54 <openstack> Meeting started Tue Aug 11 16:02:53 2015 UTC and is due to finish in 60 minutes.  The chair is pc_m. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:58 <openstack> The meeting name has been set to 'vpnaas'
16:03:08 <pc_m> #topic Announcements
16:03:36 <pc_m> #info Devstack plugin for VPN caused problems with stable/kilo
16:03:50 <pc_m> Will discuss in a moment.
16:04:53 <pc_m> Need to discuss whether we want to go back to on-demand VPN meetings. Is there a strong desire to meet weekly?
16:05:14 <madhu_ak> +1 for weekly meeting
16:05:40 <ajmiller> +1 We have some bandwidth available for helping out with VPN, esp wrt testing.
16:05:58 <Aish> +1
16:06:11 <pc_m> OK, if there's still interest in holding weekly, will continue.
16:06:24 <madhu_ak> +1 ajmiller
16:06:30 <pc_m> Anyone have any other announcements?
16:06:46 <pc_m> #info will continue with weekly meetings for now
16:07:07 <pc_m> #topic DevStack plugin
16:07:08 <Aish> I faced some issues with running the tests. Would like to discuss that.
16:07:28 <pc_m> Well, this spiraled out of control...
16:08:15 <Aish> Oh, ok then let’s discuss the issue with devstack plugin.
16:08:42 <pc_m> We have a plugin, which works fine. However, it couldn't coexist with q-vpn service setting. Since other jobs shouldn't be testing VPN, I removed the q-vpn service from devstack jobs. I found three jobs that needed the plugin and added it in.
16:09:06 <pc_m> Well, found that the disable of q-vpn is global and applies to ALL releases. That broke stable/kilo tests.
16:09:11 <madhu_ak> so you meant in features.yaml job?
16:09:11 <pc_m> jobs.
16:10:02 <pc_m> yeah removed in features.yaml and test-features.sh.
16:10:23 <madhu_ak> aye, sounds good
16:10:36 <pc_m> In any case, the agreed upon solution is to revert 4 commits. This goes back to using q-vpn service for jobs.
16:10:58 <pc_m> Then, we can work on putting the plugin back in.
16:11:32 <pc_m> I'm working on trying to modify devstack and the plugin so that if both the plugin and q-vpn is enabled, the former will be used.
16:12:07 <pc_m> Doug W would like to see new jobs for the plugin use and then we can backport the changes and jobs, and then remove q-vpn service.
16:12:11 <madhu_ak> when you say devstack plugin, It is in neutron-vpnaas/devstack?
16:12:20 <pc_m> yes.
16:12:51 <pc_m> So, right now four commits are out to revert the USE of the plugin and to re-enable q-vpn.
16:13:15 <pc_m> No matter what we do here, we're going to have some breakage, until all these reverts are upstreamed.
16:13:38 <Aish> Gotcha..
16:13:44 <ajmiller> pc_m:  What is the status of those commits?  +A?,
16:13:54 <pc_m> So that's the plan. There is some discussion on how to re-instate the plugin.
16:14:17 <pc_m> They are waiting review. Were created yesterday and this morning.
16:14:23 <ajmiller> OK
16:14:50 <pc_m> Here is a #link https://etherpad.openstack.org/p/vpn-test-changes with info from Doug, me, and infra.
16:15:55 <ajmiller> Thanks
16:16:48 <pc_m> So... there will be some blockage in tests/reviews for a bit.  It's a royal mess. Hindsight says I should have done the plugin differently, but didn't realize the q-vpn service was used in a bunch of places.
16:16:57 <pc_m> Oh well. Taking my lashings :)
16:17:09 <pc_m> #topic Grenade plugin
16:17:27 <pc_m> Postponing this work for a while.
16:17:47 <ajmiller> Yes, that makes sense.
16:17:54 <pc_m> Found issue with Grenade, such that it is not designed to handle nested upgrades (neutron + adv svcs).
16:18:06 <ajmiller> Grenade is another lovely opportunity to break the gate... (been there, done that)
16:19:01 <Aish> ;)
16:19:03 <pc_m> We have a plugin, but Grenade needs mods (or we need to separate adv svcs more from Neutron, which I don't think can be totally done).
16:19:09 <pc_m> ajmiller: yeah
16:19:32 <pc_m> So, we'll sit on this for a while. Especially given the devstack woes.
16:19:48 <pc_m> #topic VPN Functional tests for Neutron commits
16:20:33 <pc_m> When I test this, for some reason, it is NOT using the neutron changeset, unlike LBaaS, which does. Not sure what is wrong.  Decided to set it aside for a while.
16:21:21 <pc_m> Will talk to Doug W, once things settle down.
16:21:29 <pc_m> #topic Local Tunnel IP
16:21:47 <pc_m> Just waiting for second +2/+A for this. Seems to work fine.
16:22:04 <madhu_ak> could you paste me the link to localtunner ip?
16:22:14 <madhu_ak> local tunnel*
16:22:24 <pc_m> #link https://review.openstack.org/#/c/199670/
16:22:31 <madhu_ak> thanks
16:22:35 <pc_m> sure
16:22:55 <pc_m> #topic Multiple Local Subnets on VPN connection
16:23:24 <pc_m> Getting comments on the review of the developer reference doc #link https://review.openstack.org/#/c/191944
16:23:40 <pc_m> Please look it over. The big concern right now, is how to specify the endpoints.
16:23:52 <pc_m> Currently, for IPSec CIDRs are used.
16:24:02 <Aish> Will take a look.
16:24:09 <pc_m> This allows both local and peer endpoints to be specified the same way.
16:24:32 <pc_m> However, there is a question on whether we should use subnet name/UUID.
16:24:44 <pc_m> It can't be used for peer, but could be for local.
16:25:49 <pc_m> Which is a bit inconsistent. But the question is whether or not the same CIDR can be used with two subnets for a tenant or not.
16:26:22 <pc_m> IF it can, then the CIDR by itself is ambiguous.
16:27:09 <pc_m> Likewise, for BGPVPN, what do we use for endpoints? Network UUID?
16:27:30 <pc_m> And leave remote unspecified (dynamically determined)?
16:28:09 <pc_m> Essentially, it would be good to know the different types of endpoints we'll support, and the way to specify them.
16:28:27 <pc_m> Feel free to comment on the review.
16:28:35 <madhu_ak> sure
16:29:08 <pc_m> In the meantime, I've started on implementing the endpoint create API and database storage (so could use resolution of this).
16:29:36 <pc_m> I have it working, but need to write UTs.
16:30:05 <pc_m> Looking to get this into Mitaka release, as early as possible.
16:30:16 <pc_m> madhu_ak: thanks
16:31:11 <pc_m> Glad I started playing with it, as I changed to endpoint-groups, instead of endpoint-pairs or endpoints, given the way the database and APIs would work out.
16:31:21 <pc_m> Any questions/comments?
16:31:36 <madhu_ak> have a topic to discuss
16:32:27 <pc_m> madhu_ak: Sure, jut hang on, will add to end of agenda...
16:32:34 <pc_m> #topic Bugs
16:32:47 <madhu_ak> sure
16:33:03 <pc_m> Please look at the bugs #link https://goo.gl/XNtnLX and reviews #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas,n,z
16:33:31 <pc_m> Besides the local tunnel IP review, there will be new devstack plugin reviews coming.
16:33:50 <pc_m> Also there is a new bug with providing Python3.4 support in tests.
16:34:32 <pc_m> Any bugs/reviews that need to be highlighted/discussed?
16:34:49 <madhu_ak> yes please
16:35:01 <pc_m> shoot...
16:35:32 <madhu_ak> move vpn api tests from neutron to neutron-vpnaas repo.. #link: https://review.openstack.org/#/c/211381/
16:35:53 <madhu_ak> need reviews and would like to see people to test them as mentioned in README.rst
16:36:25 <pc_m> madhu_ak: Cool! I'm glad someone picked that up. We need to get them migrated.
16:36:40 <madhu_ak> need new job that I can volunteer for it.
16:36:46 <pc_m> I signed up and will look at it.
16:37:15 <madhu_ak> however, I feel that there should be a need to revamp the gate and test hooks..
16:38:16 <pc_m> I'd guess that hooks will need to be updated and a new API job created, yes.
16:38:36 <pc_m> You should be able to follow the way neutron does it.
16:38:57 <madhu_ak> sure.  I shall think about it and submit a new job via infra and neutron-vpnaas
16:39:21 <pc_m> You might want to consider creating the job as experimental, and setting up for test in neutron-vpnaas with an empty test file. Then, migrate the test files over
16:39:29 <madhu_ak> yes +1
16:39:55 <pc_m> This way, job is in place and you can then run job in experimental queue to test it.
16:40:30 <madhu_ak> sure
16:41:13 <pc_m> Right now, you can't really test this patch.
16:41:42 <madhu_ak> yep because we need to get that devstack plugin enabled?
16:41:43 <pc_m> So, if job and dummy test are in place and verified working, then this commit can be tested.
16:42:22 <madhu_ak> sure
16:42:28 <pc_m> madhu_ak: No, because there isn't really an API job for neutron-vpnaas yet.
16:43:07 <pc_m> You can do this to use q-vpn service for now, and then switch to the devstack plugin once it is updated (along with devstack).
16:43:19 <pc_m> madhu_ak: So I see the sequence as...
16:43:34 <pc_m> 1) Create experimental API job for neutron-vpnaas
16:44:04 <pc_m> 2) Create a test stub/simple test file to use to exercise job, and update the hooks as needed.
16:44:25 <pc_m> 3) migrate the real tests over and run them in the experimental queue.
16:44:53 <pc_m> 4) move job to check queue and then later to gate (voting).
16:45:20 <madhu_ak> sure. I can work on items 1 and 2 and once that is merged, I can test experimental job on 3 ( which is this https://review.openstack.org/#/c/211381/)
16:45:21 <pc_m> Devstack plugin selection can come in whenever it is available and will likely change the hook scripts.
16:45:52 <pc_m> madhu_ak: right
16:46:05 <madhu_ak> thanks
16:46:07 <pc_m> madhu_ak: Was that your item to discuss?
16:46:12 <madhu_ak> yep ;)
16:46:16 <pc_m> #topic Open Discussion
16:46:25 <pc_m> Anyone have anything else to discuss?
16:46:35 <ajmiller> I think Aish had something.
16:46:54 <Aish> We are looking towards writing more scenario tests for vpnaas.
16:47:14 <Aish> similar to what neutron-lbaas has.
16:47:18 <pc_m> Aish: Sure. Would be great.
16:47:39 <pc_m> There is a base VPN scenario test case.
16:47:55 <pc_m> Which can be leveraged off of.
16:48:11 <Aish> Yup, I took a  glance at that.
16:48:58 <Aish> I was looking for moving the tempest/lib to vpn repo to start with scenario tests. Thanks to madhu_ak. His patch did that.
16:50:03 <Aish> I will work on this and put a new patch soon for review.
16:50:29 <pc_m> NOTE: I found that when I run the functional tests locally, some StrongSwan tests failed. It appears that for rootwrap (of which I know little of) clients are trying to talk to the rootwrap daemon using the same socket (instead of unique sockets). It causes some failures. When run in the gate, it works fine. Someone looked at it during the mid-cycle and couldn't figure out what was going on.
16:50:53 <pc_m> Aish: ice, looking forward to seeing more tests there.
16:51:02 <pc_m> ice -> Nice
16:51:23 <Aish> ;) But, even when running dsvm-functional I am facing some issues
16:51:29 <Aish> related to rootwrap.
16:52:03 <pc_m> Kyle added pythn34 UT support, but several files are not being tested, as they fail with 3.4. Anyone interested can look into updating there.
16:52:18 <pc_m> Aish: That seems to run fine for me.
16:52:43 <madhu_ak> sure, could you post me a link to python34 UT support?
16:53:34 <madhu_ak> also, I need to look into rootwrap issue (happening to me as well) and see how the jenkins is actually passing the test
16:53:43 <pc_m> madhu_ak: #link https://bugs.launchpad.net/neutron/+bug/1480326
16:53:44 <openstack> Launchpad bug 1480326 in neutron "neutron-vpnaas: Enable python34 support" [Low,New] - Assigned to Li Ma (nick-ma-z)
16:54:07 <pc_m> Essentially, several files were excluded from 3.4 UT. They are listed there.
16:55:01 <Aish> pc_m  Oh, I see. So here is the error I am facing. Not sure if it is due to the plugin issue. https://gist.github.com/AishwaryaT/1352f555660f43c7ec2a
16:55:01 <pc_m> madhu_ak: Would love to see functional tests working reliably from local systems.
16:55:19 <madhu_ak> sure, will take a look at it and (of course shall ping you when in need)
16:55:49 <pc_m> madhu_ak: may be blind leading the blind, if you ask for help from me :)
16:56:11 <madhu_ak> sure
16:56:44 <madhu_ak> from the gist that Aish posted, (based on my experience, I suspect q-vpn screen is not running)
16:57:45 <madhu_ak> looks like we are running out of time
16:58:19 <pc_m> madhu_ak: Aish; Not sure. Look at the q-svc and q-vpn logs. I think this is the issue I was seeing, where it cannot open the socket, because another client is using the socket (to reootwrap daemon).
16:58:35 <pc_m> yeah. Will end now.
16:58:40 <pc_m> #endmeeting