15:01:32 <bswartz> #startmeeting manila
15:01:33 <openstack> Meeting started Thu Jun  8 15:01:32 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:37 <openstack> The meeting name has been set to 'manila'
15:01:48 <bswartz> hello all
15:01:52 <tbarron> hi
15:01:54 <ganso> hello
15:01:55 <vponomaryov> hello
15:01:56 <dustins_> \o
15:01:59 <zhongjun> hi
15:02:01 <vkmc> o/
15:02:01 <tommylikehu> hi
15:02:02 <markstur> hi
15:02:02 <xyang2> hi
15:02:13 <bswartz> #topic announcements
15:02:14 <dustins> \o (as me.prime)
15:02:28 <bswartz> Milestone 2 is TODAY
15:02:39 <bswartz> I'll be pushing tags this afternon
15:03:00 <bswartz> I was hoping to merge a few more things first
15:03:16 <bswartz> but I feel we're okay with what we have at this milestone
15:03:27 <bswartz> the hard decisions always come at milestone 3
15:04:03 <tbarron> can we merge https://review.openstack.org/#/c/471849/ first?
15:04:33 <bswartz> done
15:04:53 <tbarron> ty
15:05:00 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:05:29 <bswartz> well the agenda says milestone 2, but I actually mean both 2 and 3
15:05:35 <bswartz> #topic milestone 2
15:05:57 <bswartz> #link https://review.openstack.org/#/c/446583/
15:06:06 <bswartz> thanks tbarron for workflowing that
15:06:51 <tbarron> yw
15:06:52 <bswartz> anything else that we need to look at before tagging pike-2?
15:07:32 <bswartz> okay
15:07:36 <bswartz> #topic milestone 3
15:07:43 <bswartz> #link https://specs.openstack.org/openstack/manila-specs/#pike-approved-specs
15:08:20 <bswartz> so we need to do a review of where all of these approved specs stand
15:08:45 <bswartz> my top priority is the ipv6 one, which we carried over from ocata
15:09:58 <bswartz> I think we should get back to using launchpad for tracking blueprints against milestones
15:10:28 <bswartz> I've been very bad about that, since we started using the specs process to define what's in/out of a release
15:10:52 <bswartz> but for milestone 3 I'll make sure all the in-progress BPs are targetted
15:11:22 <bswartz> anyone have stuff targeted for milestone 3 that they know won't get done or is done and needs attention now?
15:11:37 <vponomaryov> #link https://specs.openstack.org/openstack/manila-specs/specs/pike/add-share-groups-quota.html ?
15:11:41 <vponomaryov> is under risk
15:12:35 <bswartz> okay
15:12:52 <bswartz> we could probably find a new own for that if you can't finish it vponomaryov
15:13:34 <bswartz> however please try your best!
15:13:40 <vponomaryov> )
15:14:01 <bswartz> okay moving on
15:14:07 <bswartz> #topic IPv6 testing
15:14:26 <bswartz> so the problem we had back in ocata was Ubuntu-related
15:14:35 <bswartz> and I know tbarron did some work on centos gate jobs
15:14:44 <tbarron> vkmc did
15:14:55 <bswartz> oh sorry
15:15:04 <zhongjun> bswartz: yes, vkmc and tbarron proposed https://review.openstack.org/#/c/443737/(Add a job exercises the lvm driver on devstack with an IPv6 export location.)
15:15:04 <zhongjun> But ben gave that a -1(reason: I don't like this model of having separate v4/v6 jobs at all. All the jobs should run both.). Then Ben proposed a approach that allow 2 or more export IPs for LVM driver  https://review.openstack.org/#/c/444479/
15:15:04 <bswartz> s/tbarron/vkmc/
15:15:36 <tbarron> with my moral support :)
15:15:45 <bswartz> yeah I want both IP types in the same job too, but that would depend on some driver enhancements
15:15:46 <zhongjun> bswartz: I have some questions
15:16:11 <bswartz> I worked on that a few months ago but my efforts got stalled when I saw how much code sharing there was between generic and LVM
15:16:23 <zhongjun> bswartz: But now, we only enable IPv6 or IPv4 of network. We cannot enable both IPv6 and IPv4 of network in manila.
15:16:23 <vkmc> tbarron, moral support is a must when it comes to ipv6 :D
15:16:24 <bswartz> I couldn't easily add the feature to one without doing both
15:16:58 <bswartz> tbarron: the centos job is currently nonvoting -- is there a reason for that?
15:17:23 <bswartz> ^ vmkc
15:17:27 <tbarron> bswartz: just wanted to have someone say: that works, make it voting, first
15:17:27 <bswartz> ^ vkmc
15:17:46 <bswartz> what's the historic record for that job?
15:17:53 <bswartz> has it proved reliable?
15:17:56 <vkmc> so... that was the first step for the centos job with ipv6
15:18:09 <tbarron> lvm fails randomly on both xenial and centos platforms from time to time
15:18:11 <vkmc> we did it for ipv4, non voting... and the next step was to add ipv6 non voting
15:18:18 <vkmc> and then make the two of them, voting
15:18:41 <bswartz> okay I would prefer to make the current centos job voting now, if it's stable
15:19:06 <zhongjun> vkmc: Two job or ipv4 and ipv6 in one job?
15:19:09 <tbarron> I don't see a difference here: http://ci-watch.tintri.com/project?project=manila
15:19:19 <bswartz> and then add IPv6 support to both existing jobs, but perhaps disable it in ubuntu for reasons discussed above
15:19:26 <vkmc> zhongjun, for ipv4 and ipv6 in one job we would need bswartz change
15:19:49 <bswartz> okay if my multi-IP support change is the thing holding this up then I'll make that my next priority
15:20:18 <tbarron> we had separate jobs so it would be clear which was being used also
15:20:21 <bswartz> aside from that, was there any other good reason to make ipv6 a separate job?
15:20:24 <zhongjun> vkmc, bswartz: We also need to change this patch,(https://review.openstack.org/#/c/406776/) if we want to add ipv4 and ipv6 in one job
15:20:41 <vkmc> zhongjun, yes
15:20:48 <bswartz> agreed
15:20:48 <tbarron> bswartz: how do we know it's the ipv6 export location that is exercised if we are doing both in the same job?
15:21:09 <tbarron> bswartz: of course the infra should support both anyways
15:21:17 <bswartz> tbarron: similar to how we cover both NFS and CIFS in a single job -- we'll have tests for both
15:21:26 <tbarron> bswartz: kk
15:21:33 <bswartz> the ipv6 tests will need to be disable-able
15:21:41 <bswartz> but we of course won't disable them in the gate
15:22:00 <bswartz> just for ubuntu
15:22:18 <bswartz> and that's only until ubuntu picks up newer nfs-utils bits from debian
15:22:36 * bswartz looks forward to 18.04
15:23:22 <bswartz> it's also possible we'll find another solution for xenial + ipv6
15:24:06 <bswartz> maybe a ppa for xenial containing backported bits from zesty or artful (depends when ubuntu picked up the newer bits)
15:24:49 <bswartz> okay anything else on ipv6 testing?
15:24:55 <zhongjun> Should we test DHSS=true and false?
15:25:18 <bswartz> #action bswartz finish the multi-IP support for LVM driver
15:25:22 <vponomaryov> zhongjun: not tested = doesn't work
15:26:00 <bswartz> zhongjun yes for sure
15:26:28 <bswartz> but it doesn't matter to me so much if the coverage comes from the generic driver or some other driver
15:27:06 <bswartz> eventually we'll get ipv6 support in generic, but that's not essential as far as I'm concerned
15:27:52 <bswartz> #topic open discussion
15:27:57 <bswartz> any other topics for today?
15:28:18 <bswartz> you guys know the cinder team usually spends half their meeting or more on the open discussion topic
15:28:44 <bswartz> you guys are slacking off on bringing surprise agenda items to these meetings
15:28:47 <bswartz> :-)
15:29:37 * bswartz notices that ubuntu artful STILL doesn't have newer nfs-utils bits
15:30:28 <bswartz> there's still time to fix that though -- I'll go pester them over in #ubuntu-devel
15:30:49 <bswartz> okay I guess that's it for today
15:31:23 <bswartz> there's no other commits that we're waiting on so one these current ones in the gate merge I'll push tags
15:31:25 <bswartz> thanks all
15:31:35 <bswartz> #endmeeting