15:00:26 <bswartz> #startmeeting manila
15:00:27 <openstack> Meeting started Thu Jun 29 15:00:26 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:31 <openstack> The meeting name has been set to 'manila'
15:00:31 <bswartz> hello all
15:00:31 <kaisers_> o/
15:00:35 <dustins> \o
15:00:36 <gouthamr> hello o/
15:00:42 <ganso> hello
15:00:43 <markstur> hi
15:00:49 <toabctl> hi
15:00:51 <jungleboyj> @!
15:00:53 <tbarron> hi
15:00:54 <zhongjun> hi
15:01:03 <jungleboyj> Argh!  No pewp bot here.
15:01:04 <jungleboyj> o/
15:01:10 <jprovazn> hi
15:01:11 <bswartz> jungleboyj: the bot still isn't in this channel
15:01:29 <xyang> hi
15:01:42 <bswartz> #topic announcements
15:01:45 <gouthamr> we've our first action item
15:01:56 <bswartz> so this is week R-9
15:02:05 <jungleboyj> gouthamr:  Already done.  I pinged Walt.
15:02:10 <bswartz> we're 4 weeks from feature freeze, 2 weeks from feature proposal freeze
15:02:12 <gouthamr> jungleboyj: nice :)
15:02:38 <bswartz> next week I think we should consider canceling this meeting
15:02:48 <bswartz> I personally won't be able to make it
15:02:55 <zhongjun> why
15:02:57 <bswartz> and I imagine some of you will be on vacation
15:03:07 <bswartz> zhongjun: US Holiday
15:03:24 <zhongjun> Oh, Happy US Holiday
15:03:42 <jungleboyj> We celebrate our country by blowing up parts of it.
15:03:44 <bswartz> that being said, if someone wants to run the meeting in my absence, that would be fine
15:04:25 <bswartz> everyone think cancelling next week makes sense?
15:05:07 <gouthamr> +1
15:05:11 <dustins> Works for me
15:05:17 <bswartz> okay
15:05:32 <bswartz> let's move on to the agenda then
15:05:39 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:05:54 <bswartz> #topic Revisit priorities for Pike
15:06:23 <bswartz> so as zhongjun has pointed out to me, we have a lot of patches that aren't getting reviews
15:06:57 <bswartz> we've lost some core reviewers and others have had to decrease their involvement
15:07:38 <zhongjun> I pointed out to a few guys :) Sorry for bother your guys :)
15:07:43 <bswartz> I think it makes sense to take a look at the list of approved spec and reconsider if we really want to keep them all targeted for Pike or whether some should be pushed
15:08:40 <bswartz> #link https://specs.openstack.org/openstack/manila-specs/
15:09:04 <bswartz> also we have to consider new drivers
15:09:05 <zhongjun> We did it when we review specs
15:09:36 <bswartz> zhongjun: yes we drew a cut line when we reviewed and approved specs at milestone 1
15:09:50 <bswartz> now we have less resources than we did at that time, it makes sense to cut deeper
15:10:47 <bswartz> the alternative is to just keep the list as it is and people will review what they're able to and the rest will slip by accident
15:11:09 <bswartz> my priority continues to be ipv6
15:11:43 <bswartz> let's take a quick look at the others and see where they stand
15:12:08 <bswartz> the share groups quota work is done and ready for review
15:12:28 <bswartz> it's a 1000 line patch
15:13:10 <bswartz> the ceilometer integration has 3 +2s
15:13:17 <tbarron> i think it's ready for workflow, anyone have issues with that?
15:13:40 <zhongjun> It is not have tempest test
15:13:54 <zhongjun> I am not sure is it ok for this
15:14:00 <bswartz> how do you tempest test something with no API impact?
15:14:01 <tbarron> zhongjun: so we have asked what sort of tempest test is right for this?
15:14:20 <bswartz> it needs some kind of functional test, but tempest seems like the wrong place
15:14:35 <tbarron> we don't want to break manila tempest b/c of test on ceilometer behavior
15:14:56 <tbarron> is there black box behavior to test here?
15:15:04 <zhongjun> API: create share.. then maybe get RPC message
15:15:15 <tbarron> that's not black box
15:15:27 <bswartz> tbarron it could be done
15:15:36 <bswartz> we could install a special listener that tempest can talk to
15:15:51 <bswartz> then send and API, and check that the listener got the message it wanted
15:16:06 <bswartz> that would treat manila like a black box
15:16:25 <tbarron> I don't necessarily object, but is this a good use of our resources for this one?
15:16:44 <bswartz> the main hurdle would be adding the text fixture to listen
15:16:48 <zhongjun> But I am not have strong idea for tempest test
15:16:49 <tbarron> I worry about us slipping into pedantry.
15:16:54 <bswartz> I'm curious how other projects test notifications
15:16:56 <zhongjun> just through it out
15:17:12 <bswartz> if they have tests at all, they may have code we could borrow
15:17:19 <tbarron> sure
15:17:23 <bswartz> if they don't have tests, then maybe there's a good reason for it
15:17:32 <bswartz> (or maybe it's just laziness)
15:17:34 <tbarron> cinder doesn't have tests for this, I looked
15:17:44 <tbarron> but that doesn't answer the question
15:17:46 <tbarron> :)
15:17:48 <bswartz> yeah
15:18:10 <tbarron> anyways, we digress from your main question.
15:18:13 <jungleboyj> :-)
15:18:24 <jungleboyj> tbarron:  We can borrow from you when you are done.
15:18:28 <gouthamr> we should add the manila tests and then go back and add cinder ones
15:18:31 * gouthamr runs
15:18:36 <bswartz> I don't want to spend much time on this topic, but yes some kind of functional testing is desired
15:18:50 <gouthamr> i agree this can't be tested from manila_tempest_tests
15:18:55 <bswartz> since it's not a straightforward tempest test to add, we might punt until later
15:19:03 <bswartz> let's move on
15:19:10 <bswartz> ensure share has a patch
15:19:28 <bswartz> it's 336 lines and failing jenkins
15:19:45 <bswartz> zhongjun: how high of a priority is this one for you?
15:19:51 <bswartz> #link https://review.openstack.org/#/c/457545/
15:20:00 <zhongjun> ipv6
15:20:20 <bswartz> it's not essential
15:20:24 <bswartz> for ipv6
15:20:30 <zhongjun> wait a minute
15:21:01 <zhongjun> like filter: https://review.openstack.org/#/c/462468/   gathering  usage size  https://review.openstack.org/#/c/465055/   ipv6   https://review.openstack.org/#/c/406776/  ensure share https://review.openstack.org/#/c/457545/
15:21:03 <bswartz> it's nice to have because of the ability to just add a ipv6 export to an existing share, but it's not required for ipv6
15:21:04 <zhongjun> my list
15:21:28 <bswartz> is that in priority order (your priorities)?
15:21:35 <zhongjun> yes
15:21:40 <bswartz> okay
15:21:46 <bswartz> let's cover like filter
15:22:01 <bswartz> 230 lines and failing jenkins
15:22:21 <bswartz> looks like gate-manila-tempest-minimal-dsvm-dummy-ubuntu-xenial failed
15:22:43 <bswartz> it was passing earlier today
15:22:51 <bswartz> maybe a recent change broke it
15:23:07 <bswartz> I agree this should be an easy one
15:23:17 <tommylikehu> most of the codes looks good and we already have this feature in cinder. So I guess we can spend some time to make it right?
15:23:22 <bswartz> for the sake of getting things off the plate, let's prioritize reviews of this smaller patch
15:23:49 <gouthamr> zhongjun: please rebase that patch on top of the export-locations filter patch...
15:23:53 <zhongjun> yes, I submit one in my home, The jenkins is correct befor
15:23:56 <zhongjun> before
15:24:13 <bswartz> okay
15:24:22 <bswartz> usage reporting
15:24:33 <bswartz> just 62 lines
15:24:43 <bswartz> have any drivers implemented this?
15:25:32 <zhongjun> bswartz: no drivers
15:25:38 <bswartz> hmm
15:25:54 <bswartz> we need first party driver support for this at least
15:26:13 <zhongjun> bswartz: dummy driver :)
15:26:23 <bswartz> dummy driver must support EVERYTHING
15:26:24 <tbarron> :)
15:26:28 <bswartz> we need actual functional support in a real driver
15:26:47 <bswartz> it should be easy to add it to lvm or generic
15:27:02 <bswartz> if it's not easy, then that tells us something about the feature
15:27:20 <zhongjun> yes, add it in lvm
15:27:29 <bswartz> okay moving on
15:28:10 <bswartz> ipv6 is very important, and I think if anything of zhongjun's should not make it in pike, it should be the ensure share stuff, we can put that at the bottom of the list
15:28:15 <bswartz> there are 2 other specs
15:28:22 <bswartz> share type quotas
15:28:32 <tbarron> that one is quite far along
15:28:44 <bswartz> it's partly merged
15:28:51 <tbarron> but gouthamr and vponmaryov have to have a meeting of the minds
15:28:58 <bswartz> currently there's a 2249 line patch
15:29:01 <tbarron> so it could be a while :)
15:29:23 <bswartz> vponmaryov isn't here today unfortunately
15:29:28 * tbarron is really just joking on that last remark
15:29:41 <bswartz> gouthamr might need to make the changes he wants himself
15:29:45 <gouthamr> one sided fight this
15:29:53 <zhongjun> ipv6 also important for us
15:30:20 <bswartz> I feel like the type quotas is more or less done
15:30:25 <bswartz> we need to settle the open debate
15:30:40 <bswartz> gouthamr: disagreements like the one in that patch should be put on meeting agendas so we can address them
15:30:44 <gouthamr> i thought we did that last week
15:30:49 <bswartz> >_<
15:30:53 <gouthamr> bswartz: both patches :)
15:31:25 <bswartz> okay I'll have to read the history because I don't remember this one specifically
15:31:40 <bswartz> lastly, the user messages spec
15:31:47 <bswartz> it has a raft of patches associated with it
15:32:04 <jprovazn> yea, though only the first one is bigger
15:32:17 <gouthamr> i was testing that one last night.. ^
15:32:24 <gouthamr> i'll wrap up my review today
15:32:34 <bswartz> jprovazn: is it "done" as far as you're concerned?
15:32:49 <jprovazn> yes, I think it's good to be merged
15:32:56 <tbarron> we do have a pedantic microversion issue to work out
15:32:58 <gouthamr> jprovazn zhongjun: there'll be a merge conflict on export-locations and user-messages,
15:33:07 <tbarron> but it's good to go otherwise
15:33:07 <bswartz> tbarron: what is that?
15:33:19 <tbarron> jprovazn: why don't you answer?
15:33:32 <jprovazn> sec, let me send a link to the comment about microversion
15:33:35 <zhongjun> gouthamr: yes
15:33:39 <tommylikehu> guess which one get merged earlier
15:33:59 <jprovazn> https://review.openstack.org/#/c/471438/8/manila/api/v2/messages.py
15:34:19 <jprovazn> so I split out user messages stuff into more patches
15:34:44 <jprovazn> the thing is that sorting patch changes api introduced in the first "big" user messages patch
15:34:48 <bswartz> okay so is the underlying issue the authorship?
15:35:02 <bswartz> because that's easily solved with a Co-Authored-By line in the commit
15:35:20 <gouthamr> zhongjun: you shouldn't need to microversion changes to teh API that will land back-to-back
15:35:28 <jprovazn> bswartz, yes, authorship is the main reason
15:35:30 <gouthamr> zhongjun: the same API*
15:35:55 <jprovazn> if you really want, I can squash both patches together
15:35:55 <bswartz> gouthamr: actually that's the whole point of microversions (as opposed to versioning the API by release)
15:36:04 <gouthamr> something about user messages and authorship in openstack
15:36:12 <bswartz> 2 patches that both change the API should have 2 version bumps
15:36:26 <gouthamr> bswartz: what.. but they're only split for logical reasons
15:36:37 <gouthamr> bswartz: we've certainly done that before
15:36:38 <bswartz> gouthamr: nobody else knows that
15:37:06 <bswartz> gouthamr: other splits have been done in ways such that only 1 patch actually changes the API
15:37:25 <zhongjun> gouthamr:  Do you mean user message's APIs?
15:37:30 <bswartz> the underlying assumption of microversions, is that someone might deploy any given commit from master
15:37:44 <gouthamr> zhongjun: yes
15:37:59 <bswartz> we all know that fairly unrealistic, but the community seems to stand by this assumption
15:38:04 <tbarron> so rather than waste too many cycles on this probably we should just squash?
15:38:08 <gouthamr> bswartz: i don't agree.. this confuses users... when patch 1 merges, we'll logically merge the follow on patch too
15:38:15 <bswartz> I would say +1 for squash
15:38:25 <bswartz> solve the authorship problem with a Co-Authored-By line
15:38:31 <zhongjun> gouthamr: If it will be merged at the same manila version, then it is ok.
15:38:32 <jprovazn> ACK, I'll squash them
15:38:37 <gouthamr> not opposed to squashing them..
15:38:37 <bswartz> I'm confident that ameade has already forgotten about this patch
15:38:57 <tbarron> doing the extra microversioning on this to meet a formal rule is a waste of resources
15:39:04 <bswartz> ameade: ;-)
15:39:06 <gouthamr> +
15:39:06 <gouthamr> 1
15:39:11 <gouthamr> ameade whoo
15:39:28 <markstur> don't poke ameade. he might show up
15:39:34 <bswartz> ikr
15:39:54 <ganso> tbarron: +1
15:39:58 <bswartz> okay so hopefully this one will be ready for merge after the squash happens
15:39:59 <ameade> boo!
15:40:06 <bswartz> gah!
15:40:09 <jungleboyj> Ahhhhh!
15:40:12 <markstur> ameade: lol.  hi
15:40:20 <gouthamr> ameade: risen again
15:40:21 <ameade> too busy to read what yall are talking about lol
15:40:35 <jprovazn> ameade, hi! :) discussing your patch
15:40:36 <jungleboyj> Ah the consultant's life.
15:40:43 <bswartz> see I told you he wouldn't mind
15:41:01 <bswartz> okay so what about new drivers
15:41:06 <ameade> I have a patch? lol
15:41:27 <bswartz> I don't have a list of the new drivers for pike at my fingertips
15:41:30 <ganso> ameade: your legacy
15:42:12 <gouthamr> there were two with no CI/passing CI: Infortrend and Veritas
15:42:15 <bswartz> #link openstack.org/#/c/465846/
15:42:21 <vponomaryov> bswartz: https://review.openstack.org/#/c/472190/
15:42:24 <bswartz> #link https://review.openstack.org/#/c/472190/
15:42:28 <gouthamr> Veritas looks like they weren't aiming for pike..
15:43:05 <bswartz> can't find any others
15:43:18 <bswartz> did they merge?
15:43:48 <ganso> bswartz: I don't think there were other new drivers
15:43:56 <tbarron> cephfs-nfs merged
15:43:57 <gouthamr> CEPH had a new protocol... merged.
15:43:58 * markstur looks in lost+found
15:44:08 <bswartz> k
15:44:27 <bswartz> alright then that covers the major priorities for the rest of pike
15:44:38 <bswartz> there are some smaller things too
15:44:59 <bswartz> let's move on though
15:45:09 <bswartz> #topic bug squash?
15:45:31 <bswartz> I'm thinking that we should start a habit of bug squash days
15:46:12 <bswartz> not only would it be good to get together from time to time and fix a bunch of bugs, but it would help us get on the same page about quality issues and challenges related to testing
15:46:32 <jprovazn> +1
15:46:39 <bswartz> traditionally bug squashes are scheduled for sometime after feature freeze before the RC
15:46:43 <dustins> +1
15:47:18 <bswartz> so I wanted to first gauge interest and see if anyone wants to volunteer to coordinate it
15:47:31 <bswartz> I'm thinking something virtual, hopefully a whole day
15:47:49 <bswartz> althought with timezone issues some people might only be able to attend part of it
15:48:21 <bswartz> and assuming people want to do this, we need to figure out what conflicts we need to schedule around
15:48:21 <zhongjun> I'd like to try it
15:48:45 <bswartz> I don't think we can schedule it today, but by next meeting I'd like to have enough information that we can put it on the calendar
15:49:19 <bswartz> remember that PTG this cycle will happen right at the end of the release like Ocata
15:49:37 <bswartz> and we agreed to do a virtual PTG for Queens
15:49:57 <bswartz> so we'll be meeting the week before or after the Denver meetup
15:50:11 <bswartz> that's another even that needs scheduling
15:50:39 <bswartz> #link https://releases.openstack.org/pike/schedule.html
15:51:04 <bswartz> we should be looking at R-4 or R-3 for bug squash days
15:51:38 <jprovazn> hmmm, I guess there will be bunch of PTOs these weeks
15:51:50 <bswartz> indeed
15:52:18 <bswartz> because of that, anyone who wants to participate in a bug squash day should send me the days that won't work for them
15:52:30 <bswartz> assuming you have you vacation plans for August
15:52:43 <bswartz> we'll see if we can find a day that works for most people
15:52:59 <bswartz> looks like Denver will happen at R+2 for Pike
15:53:06 <bswartz> so more breathing room than we had with Ocata
15:53:27 <bswartz> anyways that's all I had
15:53:31 <bswartz> #topic open discussion
15:53:38 <bswartz> we have a few more minute if anyone has another topic
15:53:51 <tbarron> ok let's go back to the functional tests and the telemetry review
15:54:02 <tbarron> do we have a framework for these to use?
15:54:22 <bswartz> tbarron: so the design here is that we send notifications which in theory anyone can consume right?
15:54:36 <tbarron> correct
15:54:36 <bswartz> how hard is it to write a "hello world" notification listener?
15:54:59 <tbarron> that's not really what I'm asking, i'm asking
15:55:08 <tbarron> does manila have a framework for functional tests
15:55:54 <bswartz> not in the way that cinder does
15:56:02 <tbarron> it's a good idea that we should have one, but it seems another project to take on
15:56:11 <bswartz> although the cinder approach hurt my brain tbh
15:56:15 <bswartz> hurts*
15:56:31 <tbarron> from a practical standpoint we should test that this works end to end, but
15:56:48 <tbarron> the likelihood of breakage and the consequences of breakage are low
15:57:02 <tbarron> and the value of the feature getting in is high
15:57:09 <bswartz> the idea that I had was to actually test this in tempest, with a simple listener
15:57:27 <tbarron> I don't like doing thiis in tempest at all
15:57:36 <bswartz> It would be a net-new thing to write, which is why I wouldn't insist on doing it now
15:57:51 <tbarron> adding a "simple listener" to tempest seems a nightmare, not b/c of the listener but b/c of tempest
15:57:55 <bswartz> what's your objection to doing it in tempest?
15:58:02 <tbarron> that ^^
15:58:07 <tbarron> maybe I'm wrong though.
15:58:08 <vponomaryov> tbarron: it can be added to manila tempest plugin
15:58:13 <dustins> Tempest doesn't really seem like the place for it, though
15:58:14 <vponomaryov> tbarron: don't see problem here
15:58:29 <dustins> Granted, I don't really know where the correct place is, but it seems odd to me
15:58:33 <bswartz> well there is the issue that tempest isn't set up to interact with the backend of the cloud, where this kind of listener would reside
15:58:35 <tbarron> tempest is fragile enough as it is
15:58:50 <bswartz> installing the listener would necessarily involve modification of config files
15:58:55 <tbarron> i want us to work on *real* problems
15:59:07 <tbarron> of which there are many
15:59:13 <tbarron> not on pedantic stuff
15:59:22 <tbarron> that doesn't add much value
15:59:28 <bswartz> tbarron: it sounds like you're arguing for simply not testing this feature for now
15:59:45 <tbarron> we should test it manually
15:59:47 <bswartz> if so I don't have a problem with that
16:00:08 <bswartz> but it shouldn't stop us from planning how to test it correctly in an automated way
16:00:15 <tbarron> and if someone invests energy to build a good functioonal test framework this would be a candidate for that
16:00:30 <tbarron> bswartz: ack
16:00:36 <bswartz> because such a test would have value for not only us, but also cinder and every other service that does notifications and doesn't test them
16:01:05 <bswartz> okay we've hit our time limit
16:01:11 <bswartz> thanks everyone
16:01:18 <bswartz> #endmeeting