15:00:22 <tbarron> #startmeeting manila
15:00:23 <openstack> Meeting started Thu Jun 28 15:00:22 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:26 <openstack> The meeting name has been set to 'manila'
15:00:43 <dustins> \o
15:00:47 <tbarron> manila courtesy ping: gouthamr zhongjun xyang markstur toabctl bswartz ganso erlon tpsilva vkmc vgreen erlon
15:00:48 <zhongjun__> Hi
15:00:50 <ganso> hello
15:00:52 <bswartz> .o/
15:01:02 <vkmc> o/
15:01:27 * tbarron waits a minute
15:01:55 <tbarron> Hi all
15:02:09 <tbarron> between World Cup and a long weekend for many here in the US
15:02:19 <tbarron> we may not have very many folks today
15:02:27 <dustins> Slackers :)
15:02:42 <tbarron> agenda: https://wiki.openstack.org/wiki/Manila/Meetings
15:03:00 <tbarron> #Topic: Announcements
15:03:19 <bswartz> Long weekend?
15:03:27 <tbarron> I just want to make sure everyone saw the email from ttx w.r.t. PTG
15:03:41 <tbarron> bswartz: well, 4 July is midweek next week so
15:03:55 <tbarron> people here tend to take off before, after, or on both ends
15:04:17 * bswartz needs to take more vacation...
15:04:38 <tbarron> #link: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131881.html
15:04:55 <tbarron> There's a picture attached that shows the proposed schedule
15:05:07 <tbarron> manila would meet Monday and Tuesday
15:05:22 <tbarron> cinder, nova, tripleo, etc. Wed through Friday
15:05:41 <tbarron> anyone have fundamental issues with that proposal?
15:05:43 <ganso> was this change from what we had in Dublin (Tue and Fri) suggested?
15:06:14 <tbarron> ganso: I don't recall suggesting it, but honestly I prefer the continuity
15:06:28 <bswartz> The only downside I see is conflict with Monday cross-project sessions. In Dublin there weren't many sessions that were important for us
15:06:50 <bswartz> And the set of people who care about cross project stuff at all is small
15:07:03 <bswartz> So it seems like a good change
15:07:06 <ganso> the advantage I see in Tue and Fri is that on Friday we can discuss things that we saw in other projects throughout the week
15:07:07 <tbarron> yeah, if we see some that are really important maybe we can take a break or something
15:08:03 <tbarron> ganso: good point, so if we do Monday Tuesday then we'll need to make an effort to collect those issues and bring them to this meeting, #openstack-manila, dev mail list, etc.
15:08:44 <bswartz> Or Friday afternoon when the Cinder people have worn themselves out
15:08:50 <tbarron> We're going to need to bring some stuff back from PTG anyways since not everyone will be able to attend in person
15:09:17 <tbarron> Yeah, we could informally synchronize at the Friday afternoon cinder session
15:09:29 <tbarron> though I suspect some of us will already be at the airport
15:09:51 <tbarron> I'm not hearing any fundamental objections to Monday-Tuesday, right?
15:09:58 <bswartz> +1
15:10:12 <tbarron> Main implication, plan to fly in Sunday or earlier, not Monday morning
15:10:38 <tbarron> #topic: stable/branch gates
15:10:57 <tbarron> They aren't as stable as we'd like so I'll make an etherpad with issues
15:11:19 <tbarron> in pike the lvm voting job is failing
15:11:33 <tbarron> I noticed it with
15:11:53 <tbarron> #link https://review.openstack.org/#/c/576227/
15:12:11 <tbarron> which led to a global requirements review for stable/pike
15:12:27 <tbarron> #link https://review.openstack.org/#/c/578558/
15:13:10 <tbarron> This is a bit of a precedent setter but in discussion in the requirements meeting yesterday
15:13:31 <tbarron> the req folks decided that with long term releases we're going to have to do stuff like this
15:13:52 <tbarron> stable/<branch> requirements get frozen with everything working then
15:14:15 <tbarron> over the lifetime of the branch the OS underneath may change with accompanying libraries
15:14:20 <tbarron> libvirt in this case
15:14:42 <tbarron> so that requirements on stuff like libvirt-python have to change
15:15:15 <tbarron> Anyways, I'll send out an etherpad for gate issues and would like to engage all y'all's help keeping it up to date
15:15:23 <tbarron> Anything else on this topic?
15:15:44 <tbarron> #topic review focus
15:16:06 <tbarron> as agreed last week I made a review focus etherpad and announced it on the dev list
15:16:19 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-review-focus
15:16:29 <zhongjun__> Thanks
15:16:34 <tbarron> Please use it to see what needs review and
15:16:47 <tbarron> sign up to review some of the reviews there
15:17:38 <tbarron> bswartz: gouthamr thanks for doing review stuff this week
15:17:46 <tbarron> also anyone else I may have missed
15:18:10 <tbarron> Let's keep momentum so we don't have last-minute crunch.
15:18:27 <tbarron> Reminder: Milestone 3 is 26 July
15:18:35 <bswartz> So I raised the question of functional tests for the metadata stuff
15:18:44 <tbarron> feature freeze, driver merge deadline
15:18:49 <bswartz> zhongjun__: you said that the patch was coming "soon"
15:19:16 <bswartz> Can I assume that we don't plan to merge the medatachanges until that tempest plugin change is ready?
15:20:09 <zhongjun__> Yeah, “as soon as possible “
15:20:28 <zhongjun__> I am coding
15:20:43 <bswartz> If so I'll hold off on the +2
15:20:48 <tbarron> zhongjun__ is good at coding and chatting at the same time
15:20:49 <bswartz> And I'll run the tests when they're ready
15:21:24 <tbarron> sounds good
15:21:33 <tbarron> anything else on this topic?
15:21:52 <tbarron> #topic bugs
15:21:57 <tbarron> dustin you are up
15:22:11 <dustins> tbarron: Awesome, thanks
15:22:27 <dustins> #link: https://etherpad.openstack.org/p/manila-bug-triage-pad
15:23:01 <dustins> Let's start with the stuff to follow up on
15:23:07 <dustins> #link: https://bugs.launchpad.net/manila/+bug/1762900
15:23:07 <openstack> Launchpad bug 1762900 in Manila "tearDownClass manila_tempest_tests.tests.api.test_share_networks_negative.ShareNetworksNegativeTest Failed" [High,Triaged] - Assigned to Tom Barron (tpb)
15:24:08 <tbarron> As you see gouthamr followed up on this one
15:24:17 <bswartz> Is gouthamr out today?
15:24:17 <dustins> Yeah, was just gonna say
15:24:42 <tbarron> maybe just sleeping
15:24:57 <dustins> hehehe
15:25:08 <tbarron> anyways, this one is waiting for a response to his question from the bug submitter
15:25:14 <dustins> We can come back to this next week then
15:25:17 * bswartz pokes gouthamr with a moderately sharp stick
15:25:22 <dustins> Doesn't seem critically urgent
15:25:49 <tbarron> someone set its importance to High :D
15:26:10 <tbarron> someone who likes tempest a lot
15:26:27 <tbarron> but yeah we can move along
15:26:35 * dustins smacks forehead because past self once again was a dolt
15:26:39 <vkmc> hmm, if only we had that person
15:26:40 <dustins> #link https://bugs.launchpad.net/manila/+bug/1760644
15:26:40 <openstack> Launchpad bug 1760644 in Manila "API reference contains mistakes" [High,Triaged] - Assigned to Victoria Martinez de la Cruz (vkmc)
15:26:53 <dustins> vkmc: I know you need more things to do :)
15:27:19 <vkmc> working on that, I'm afraid we need to go over the whole API to make sure docs are correct
15:27:26 <vkmc> so I kinda left that aside
15:27:33 <tbarron> I don't like this bug because it's too open-ended.
15:27:36 <vkmc> yeah
15:27:47 <tbarron> not clear when it would ever be fixed
15:27:49 <vkmc> it's almost as broad as "fix the docs"
15:28:10 <dustins> Heh, not wrong on all accounts
15:28:24 <tbarron> we've merged several api doc fixes since it was opened
15:28:25 <vkmc> I can submit a small fix for the two items the reporter mentions though
15:28:56 <tbarron> vkmc: that seems reasonable and close the bug then with a comment to open new specific bugs as issues are encountered
15:29:01 <vkmc> s/POST/GET and list share params
15:29:08 <dustins> +1
15:29:10 <vkmc> but... Also, some request options have descriptions clearly copy-pasted from POST methods (e.g is_public).
15:29:13 <vkmc> not sure how to address
15:29:58 <dustins> Not exactly a small effort
15:30:13 <vkmc> yeah... I was trying to look for an efficient way to check the whole api
15:30:14 <dustins> vkmc: I'm willing to help you out with the audit/fixes/etc
15:30:16 <tbarron> vkmc: just fix the couple obvious things and ask the submitter to open new bugs for anything else.
15:30:19 <vkmc> but we need to go to the code directly
15:30:27 <vkmc> tbarron++
15:30:28 <vkmc> sounds good
15:30:41 <vkmc> dustins, awesome!
15:31:19 <tbarron> and of course feel free to fix any other stuff you see while you are in there, but don't postpone fixing the obvious for more investigation
15:31:20 <dustins> #link https://bugs.launchpad.net/manila/+bug/1755795
15:31:20 <openstack> Launchpad bug 1755795 in Manila "manila_tempest_tests.tests.scenario.test_share_basic_ops create share failed because share type not found" [Undecided,New]
15:31:32 <dustins> The ever-popular "un-suck the scenario tests" one
15:31:47 <bswartz> No no, this is the default share type one
15:32:02 <bswartz> It's not related to scenario tests
15:32:13 <dustins> That's not what the title says
15:32:13 <bswartz> The test just needs to make sure it creates the share type it plans to use
15:32:27 <bswartz> (and cleans it up after)
15:32:33 <vkmc> oh the default share type one strikes again
15:32:39 <dustins> But yes, you're right bswartz
15:32:46 <tbarron> vkmc: can you update this bug to indicate that your review WIP addresses its concern?
15:32:53 <vkmc> tbarron, sure thing
15:33:08 <dustins> Thanks, vkmc
15:33:19 <tbarron> maybe add Related-bug: tag in your commit msg for this bug too
15:33:45 <vkmc> cool
15:33:56 <dustins> Alright on to some new ones
15:34:02 <dustins> #link https://bugs.launchpad.net/manila/+bug/1778971
15:34:02 <openstack> Launchpad bug 1778971 in OpenStack Global Requirements "stable/pike libvirt / python-libvirt incompatability" [Undecided,New]
15:34:32 <tbarron> dustins: that's the one I linked to earlier, looks like requirements team is going to merge the fix
15:34:45 <dustins> tbarron: Sweet
15:35:12 <dustins> So we can move on then
15:35:25 <dustins> #link https://bugs.launchpad.net/manila/+bug/1778975
15:35:26 <openstack> Launchpad bug 1778975 in Manila "Quota Update API does not Require a Quota Value to Update" [Low,Triaged]
15:35:57 <dustins> This came from gouthamr, vgreen and I messing around with the Quota APIs the other day
15:36:37 <gouthamr> o/
15:36:40 <dustins> It comes from an ambiguity in the API, where the quota update API lists all quota values that can be updated as optional parameters
15:37:03 <dustins> Which means that we can generate a request that has an empty body that does nothing
15:37:32 <dustins> Which isn't technically wrong, but can be confusing to users who see that a command succeeded that may or may not have side effected something
15:38:01 <tbarron> dustins: do you think this empty-body-in-request issue is quota specific or may exist in other apis too?
15:38:17 <dustins> Good question
15:38:34 <dustins> Maybe something I can look out for while helping vkmc with the API doc clean up
15:39:15 <tbarron> should we be erroring out or somehow warning on these?  or do we figure that api users should just know what they are doing?
15:39:40 <tbarron> dustins: can we get to this situation from the client or from horizon?
15:39:53 <dustins> That's partially why I brought this up, it isn't technically wrong to issue a request with nothing to update, but could cause confusion
15:39:58 <gouthamr> the json schema validation change may help us do the right thing here
15:40:25 <gouthamr> dustins: it is wrong, if you're expecting it to do anything :)
15:40:28 <tbarron> gouthamr: I'm going to try out that patch in the coming week ...
15:40:40 <dustins> tbarron: Yeah, if you do "manila quota-update <project_id>" or "manila quota-update <project_id> --share-type <type>" it will not error out
15:40:53 <gouthamr> tbarron: yes, i started reviewing it with this bug in mind, but it looks like there are no follow on patches
15:41:11 <tbarron> gouthamr: they're probably waiting for us to merge the first one
15:41:33 <tbarron> gouthamr: which so far looks good to me but I just wanted to try it and see that it does no harm
15:41:39 <gouthamr> oh, sure
15:42:04 <gouthamr> yeah, we should have some tempest tests
15:42:18 * dustins grins
15:42:37 <tbarron> so are folks agreeing that empty body should produce an error?
15:42:56 <dustins> I think it should, yes
15:42:56 <gouthamr> +1
15:43:05 <zhongjun__> I agree
15:43:07 <ganso> +1
15:43:39 <tbarron> ok, someone other than dustin please run the commands above and mark the bug confirmed
15:43:57 <dustins> Sounds good
15:44:20 <tbarron> and we can use it as a guinea pig with the json schema validation
15:44:37 <dustins> Even better :)
15:44:47 <dustins> #link https://bugs.launchpad.net/manila/+bug/1777647
15:44:47 <openstack> Launchpad bug 1777647 in Manila "gluster nfs job always fails" [Medium,New]
15:45:07 <gouthamr> #action: gouthamr confirm LP 1778975
15:45:07 <openstack> Launchpad bug 1778975 in Manila "Quota Update API does not Require a Quota Value to Update" [Low,Triaged] https://launchpad.net/bugs/1778975
15:45:14 <gouthamr> what's gluster
15:45:48 <tbarron> gouthamr: thanks for the AI
15:46:12 <tbarron> on the gluster issue I was hoping to entice some of the folks who are using it to fix
15:46:16 <tbarron> our gate job
15:46:33 <bswartz> Do we know who those folks are?
15:46:41 <tbarron> the glusterfs devstack plugin tries to download a version of gluster that is no longer in the PPA
15:46:44 <tbarron> way old
15:47:10 <tbarron> bswartz: well we know China Mobile has been doing great work with gluster in their own fork
15:47:29 <tbarron> bswartz: but otherwise I don't know who
15:48:00 <bswartz> Why a fork? Is there a reason not to collaborate with upstream gluster?
15:48:10 <tbarron> so dustins not sure what to do about this one atm
15:48:25 <tbarron> bswartz: we politely asked that question at summit
15:48:26 <bswartz> If they do upstream work too, then it's reasonable for them to fix the PPA and fix the driver
15:48:53 <bswartz> If not, then perhaps gluster support is not going to continue in the future
15:49:04 <tbarron> bswartz: currently they don't appear to be authorized to propose their work upstream though as individuals they would like to do so.
15:49:09 <tbarron> bswartz: yes, that is the issue
15:49:11 <zhongjun__> As I know. They may don’t have enough time to fix upstream bug
15:49:17 <dustins> tbarron: I guess we can leave it be for now? I don't know of anyone doing upstream stuff with Gluster at the moment
15:49:18 <bswartz> Oh it's a legal problem
15:49:36 <tbarron> bswartz: dunno exactly why, legal or time or resources or ...
15:49:45 <bswartz> dustins: we can't just leave a job that fails constantly
15:50:11 <tbarron> I think lots of folks find it more economical short term to just do their own forks rather than deal with the hassle of upstream reviews
15:50:12 <bswartz> Turn the job off, and paint a scarlet letter on the driver
15:50:17 <dustins> bswartz: Right, so can we just kill the job?
15:50:55 <tbarron> dustins: bswartz: eventually we'll do that, just want to keep options open a little while
15:51:08 <tbarron> I'd love to have another production quality open source
15:51:14 <bswartz> It's extremely rude to the rest of the openstack community to consume resources running something that's broken and we don't intend to fix
15:51:16 <tbarron> software defined back end than ceph
15:51:47 <tbarron> W.r.t. scarlet letters there are a number of back ends that should get them.
15:51:52 <bswartz> tbarron: +1
15:52:12 <tbarron> What do folks think about adding a WARNING at init time for drivers that don't ever pass CI
15:52:32 <tbarron> we have decided not to kick them out of the codebase
15:52:41 <tbarron> but warning would be fair I think.
15:52:41 <bswartz> I'd prefer docs in the source code
15:52:56 <bswartz> Warnings will create backport issues if the status ever changes
15:53:14 <tbarron> ah, good point I think
15:53:42 <tbarron> but we are digressing from current #topic, we can return to the digression in a future meeting
15:53:46 <bswartz> It's sufficient to say, "Nobody is paid to maintain it, we believe it's broken. Use are your own risk"
15:54:26 <tbarron> dustins: more bugs?
15:54:30 <dustins> Yup!
15:54:46 <dustins> #link https://bugs.launchpad.net/manila/+bug/1777551
15:54:46 <openstack> Launchpad bug 1777551 in Manila "all_tenants value is not handled correctly" [Undecided,New] - Assigned to jiaopengju (pj-jiao)
15:54:50 <bswartz> s/Use are/Use at/
15:55:11 <tbarron> there is a fix proposed in https://review.openstack.org/#/c/576332/
15:55:23 <tbarron> and active review
15:55:29 * tbarron thanks gouthamr
15:55:44 <dustins> So this one's in progress it seems
15:56:01 * dustins updates bug
15:56:30 <dustins> Alright, next one
15:56:35 <dustins> #link https://bugs.launchpad.net/manila/+bug/1772029
15:56:35 <openstack> Launchpad bug 1772029 in Manila "ganesha library: update of export counter and rados object url index object racy" [Undecided,New] - Assigned to Ramana Raja (rraja)
15:57:12 <tbarron> this one is in progress and will be addressed in the ceph_volume_client outside openstack proper
15:57:36 <tbarron> i'll mark it in progress
15:57:56 <dustins> tbarron: already did
15:58:15 <tbarron> oh ganesha library will also need an update, but after ceph_volume_client
15:58:24 <tbarron> dustins: ty
15:58:30 <dustins> Of course!
15:58:53 <dustins> Think that's all for me today, the other bugs in the list already have assignees
15:59:10 * dustins updates their status
15:59:13 <tbarron> #topic open discussion
15:59:16 <tbarron> time check
15:59:26 <tbarron> just note anything and we can go to
15:59:34 <tbarron> #openstack-manila to continue as
15:59:35 <bswartz> meeting next week?
15:59:36 <tbarron> needed
15:59:46 <bswartz> yes/no/maybe?
15:59:53 <tbarron> bswartz: are you on holiday thursday?
15:59:57 <tbarron> anyone else?
16:00:00 <bswartz> unknown
16:00:11 <tbarron> I plan to be here if there are others.
16:00:14 <bswartz> No plans at this time, but I'll take some time off TBD
16:00:22 <gouthamr> i might be off too.. tbd
16:00:28 <tbarron> kk
16:00:34 <tbarron> let's go to #openstack-manila
16:00:40 <tbarron> #endmeeting