15:01:13 #startmeeting manila 15:01:15 Meeting started Thu Apr 2 15:01:13 2020 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:18 The meeting name has been set to 'manila' 15:01:19 o/ 15:01:20 o/ 15:01:22 o/ 15:01:28 hi 15:01:29 Hi 15:01:31 hello! 15:01:32 hi :) 15:01:36 o/ 15:01:46 courtesy ping: xyang toabctl ganso amito lseki 15:01:55 o/ 15:01:58 hey lseki 15:02:09 Agenda: https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting 15:02:25 ganso! I saw you in cinder and thought you might love them more than us. 15:02:27 hello everyone o/ 15:02:30 * tbarron is relieved 15:02:30 o/ 15:02:46 tbarron: rofl 15:02:49 lol 15:02:53 #topic Announcements 15:03:29 I hope everyone is staying home and staying healthy 15:03:47 We're quietly approaching feature freeze for the Ussuri release 15:03:52 that's exactly in one week 15:03:58 #link: https://releases.openstack.org/ussuri/schedule.html 15:04:21 * ganso is in a conflicting meeting 15:05:14 we'll discuss patches in a bit, but, this milestone is a freeze for all new features/api changes - we'll also be making releases for python-manilaclient and manila-ui 15:05:38 ganso: ack 15:06:30 i'd like to not have any exceptions - but, we're living in exceptional times, so if you feel like some work of yours is going to be delayed, please let me know either on irc or via the openstack-discuss mailing list 15:07:14 no other announcements for today, it's busy around here :) 15:07:26 anyone else got any? 15:08:04 #topic Tracking our work 15:08:10 #link https://etherpad.openstack.org/p/manila-ussuri-review-focus 15:08:53 lets go down that list 15:08:53 Support query user message by timestamp 15:09:20 thanks for reviewing this, i see two patches workflowed 15:09:40 #link: https://review.opendev.org/#/c/716848/ 15:09:40 haixin added a test patch: 15:10:02 no rush to get this one in, we've time beyond feature freeze to merge tests too 15:10:11 [Unity] Manage/unmanage share server/share/snap 15:10:31 unity CI seems problematic 15:11:06 yes, dviroel suggested a fix yesterday, i'm not sure how far that's progressing 15:11:31 or rather, maybe it is working, catching issues since the code under review is changing in response 15:12:07 ack, that too - its a good thing to insist for tempest test coverage 15:12:16 gouthamr: I recommend that we not rush merge but allow exception if needed *if* consistent effort continues to be applied 15:12:23 it's an isolated feature 15:12:28 back end specific 15:12:38 yeah, we'll keep this at the top of the backlog 15:12:42 +1 15:12:50 Graduate share groups feature 15:12:55 #link https://review.opendev.org/#/q/topic:bp/graduate-share-groups-feature+(status:open+OR+status:merged) 15:13:19 I haven't personally gotten to this, but, it's been up there for a bit 15:13:42 oh boy, looks like we've had no eyes besides carloss 15:13:55 dviroel vkmc - can you please take a look 15:14:16 gouthamr, will do 15:14:22 gouthamr: sure 15:14:26 awesome thank you 15:14:29 gouthamr: vkmc reviewed the manila one, I have addressed the answers 15:14:40 ty vkmc dviroel 15:14:44 thanks carloss, I'll review again 15:14:55 ah i missed that, ty vkmc carloss 15:14:59 Tenant based quotas for share replicas and replica sizes 15:15:07 #link https://review.opendev.org/#/q/topic:bp/limit-share-replicas-per-share+(status:open+OR+status:merged) 15:15:39 this is proceeding well i presume, you'll need to rebase because of the microversion bump 15:15:48 currently reviewing these changes, also did some QA that I'll comment on the etherpad 15:16:02 I have got a new review from dviroel few minutes ago. will address it today. thanks for the review and qa dviroel 15:16:12 good stuff... 15:16:23 s/will address it today/will address the answers today 15:16:24 Create share from snapshot in another pool or backend 15:16:43 #link https://review.opendev.org/#/q/topic:bp/create-share-from-snapshot-in-another-pool-or-backend+(status:open+OR+status:merged) 15:17:10 some good conversations happened wrt this one 15:17:52 I've uploaded a new patch on the core change, adding the check that we talked yesterday 15:17:53 vkmc, tbarron, i know there were plans to build on this for cephfs - so can you please take a look as well? 15:18:07 +1 15:18:59 cool dviroel - lets aim to merge early next week, if we can satisfy ourselves 15:19:12 gouthamr: ack, ty 15:19:33 there's a driver implementation from NetApp: 15:19:35 #link https://review.opendev.org/#/c/712642/ 15:19:41 it's related 15:20:03 yeah, kinda part of the same bunch 15:20:16 cool, that's all from this pile 15:20:53 do we have any python-manilaclient changes and manila-ui changes besides the ones called out above, that need to be there in our ussuri release? 15:21:51 i know we're still looking at a bunch of changes maaritamm proposed, we can opportunistically get those into this release, but, i don't think we need to rush them all through next week 15:22:02 (o/ maaritamm) 15:22:31 also gather that the manila-ui gate's currently broken 15:22:47 +1 15:23:30 huh, tenant quotas? 15:23:57 oh well, i'll report a launchpad bug and find vkmc 15:24:00 i mean owners 15:24:19 :) 15:24:20 haha 15:24:23 we had ui breakage before when core horizon did something with quotas 15:24:36 I'm checking out that one... I'm digging into config files for the gate and latest changes in dependencies 15:24:49 we were relying on horizon internals allegedly, might have some of that still 15:24:57 believe so yes 15:25:05 weird thing is that errors cannot be reproduced locally 15:25:09 oh 15:25:12 I'm finding really funny stuff on the way as well 15:25:18 not even running the same unit tests? 15:25:25 jaja 15:25:33 gremlins 15:25:38 :D 15:25:40 smurfs 15:25:51 gouthamr: i ran same unit tests and don't hit it, but I was on fedora 15:26:03 I ran those on bionic, same we are using in the gate 15:26:30 vkmc++ 15:26:39 still no clue though 15:26:45 but will let you know when I find something 15:27:05 currently looking the diff on horizon :) 15:27:10 maybe horizon folks can tell us if there's any recent change on their side that could explain it 15:27:12 jinx 15:27:14 concerning, thank you for chasing this down vkmc 15:27:37 client change: https://review.opendev.org/#/c/712543/ looks close to merge 15:28:12 andrebeltrami: I think you could make carthaca happy pretty easilly on that one 15:28:32 it will need to change, tbarron 15:28:43 ^ this one will need to be update, microversion will be bumped 15:28:59 @tbarron for sure! 15:29:03 ok, picky picky picky 15:29:11 yep, bear with these microversion churns 15:29:43 cool, please pop anything else that you need reviewed on the review etherpad 15:29:52 * gouthamr speaks to those reading meeting logs too 15:30:08 #link: https://etherpad.openstack.org/p/manila-ussuri-review-focus (Review Focus Etherpad for Ussuri Feature Freeze) 15:30:37 moving on 15:30:41 #topic Driver interface changing with new snapshot cloning behavior 15:30:55 okay, snapshot cloning, it's a term now 15:31:10 #link https://review.opendev.org/#/c/709697/ 15:31:47 we discussed this patch, so this is an informational update 15:32:00 the create_share_from_snapshot driver interface is changing 15:32:18 the change will be updating all in-tree drivers 15:32:28 and break any out-of-tree drivers 15:32:42 we don't know who/how many of them exist 15:33:09 we don't often make these kind of changes lightly 15:33:52 dviroel: i think it's fitting to send a note to openstack-discuss when you get a chance regarding this, what do you think? 15:34:20 gouthamr: agree, its a good idea. Will do 15:35:00 gouthamr: lets wait a little bit to see if will be approved :) 15:35:20 thank you, in general i think it's a good idea to hand down the source/parent share - we should have always done it 15:36:15 dviroel: ack, we should do around feature freeze 15:36:37 anything else about $topic? 15:36:46 #topic Bugs (vhari) 15:36:51 #link: https://etherpad.openstack.org/p/manila-bug-triage-pad-new (Bug Triage etherpad) 15:36:56 o/ vhari 15:36:59 you're up 15:37:01 gouthamr, \o 15:37:11 gouthamr, let's look at a few new ones 15:37:20 #link https://bugs.launchpad.net/manila/+bug/1870280 15:37:21 Launchpad bug 1870280 in Manila "[RFE] add user message for share creation failure because of no share-type" [Undecided,New] 15:38:01 heh 15:38:05 hmm, its a bug that we don't currently have a user message for this 15:38:15 gouthamr, we also hit this in our setup recently 15:38:55 its an classic asynchronous failure, and a non-privileged user is left wondering what they did wrong 15:40:11 you could think the bug's in two places: lack of user message 15:40:27 and python-manilaclient not preventing you from this issue 15:40:47 manila-ui sort of prevents you from hitting this 15:41:13 it reads share types from the server and makes it mandatory to pick one when creating a share 15:42:00 we could argue that it's probably unhelpful if there are no share types in that drop down, head scratcher - but, at least you don't wonder why your shares aren't going to error 15:42:07 with no explanation 15:42:52 vhari: lets triage this - i think its medium priority, and a low-hanging-fruit 15:43:11 gouthamr, ack 15:43:16 I don't see why we can't fail that synchronously 15:43:30 only difference is i think its a clear bug, not an RFE on manila 15:44:01 ganso: we could, but it'd involve slowing down the POST /shares API to retrieve share types 15:44:57 ganso: we don't commit the default share type to the database, so all share types must be retrieved and filtered 15:45:03 gouthamr: yea, the API does a bunch of DB queries today to perform validations. This would be one more 15:45:39 ganso: true, this was my initial assumption looking at the issue 15:45:55 gouthamr: oh I see there is no way the DB can know which share type is the default, so the query is not efficient 15:46:52 yes, it's possible to add that check - but, in a multi-tenant cloud, this behavior may be intentional 15:47:02 cloud administrators may not have a default share type 15:47:23 well, since changing the default share type currently requires a restart, I don't see why we cannot save it in the database. Even if we change it to not require a restart later we could trigger an update whenever it would detect and apply the config change 15:48:08 ganso: hmm, as a share type attr? or a separate table? 15:48:09 gouthamr: that's even better for that scenario, we would fail immediately if the share type is not specified 15:48:25 gouthamr: share type attr sounds fine to me 15:49:20 ganso: it'd be a multi-row update, and you're assuming that config is changed in all places at the same time? 15:50:00 we're slipping into design discussion, but i think we're onto something ganso 15:50:12 lets update the bug with these notes 15:50:31 i'll hold off on the "low-hanging-fruit" classification until we have arrived at a conclusion 15:51:12 vhari: perhaps pencil this in for revisiting in a few weeks, based off the discussion on the bug? 15:51:27 gouthamr, makes sense .. 15:51:45 moving on.. #link https://bugs.launchpad.net/manila/+bug/1869712 15:51:46 Launchpad bug 1869712 in Manila "Increased schedule time for non thin_provisioned backends" [Medium,New] - Assigned to Jose Castro Leon (jose-castro-leon) 15:52:23 this is new and has a proposed fix 15:52:40 vhari: this one has been triaged, we had a fix, but had to be reverted 15:52:43 floating out in case additional discussions 15:52:43 #link https://review.opendev.org/#/c/716683/ 15:52:57 gouthamr, ack 15:53:00 the revert hasn't merged yet, it's been stuck in the gate 15:53:43 josecastroleon will be reworking the solution based off a finding regarding some share backend capabilities being reported as either booleans or lists 15:54:50 gouthamr, will add note to the bug 15:55:06 gouthamr, that's a wrap for bugs - more next week 15:55:37 thank you vhari 15:55:42 #topic Open Discussion 15:55:50 anytime gouthamr :) 15:56:03 carthaca: I saw you hit an old bug: https://bugs.launchpad.net/manila/+bug/1475351 15:56:04 Launchpad bug 1475351 in Manila "Bug: AttributeError: 'module' object has no attribute 'snapshot_delete'" [Undecided,Confirmed] 15:56:39 was the next one in vhari's list 15:56:52 timely then 15:57:04 :) 15:57:10 it's nearly 5 years old - at this point it's a feature 15:57:15 edge case like the bug 15:58:06 carthaca: ack, i think we can reproduce this bug with faking a db lock timeout exception like the real one you hit 15:58:19 implementing 'delete_snapshot' would be a feature change then 15:58:24 and it's interesting, it's possible even with share creation 15:58:56 delete_snapshot <> snapshot_delete 15:59:01 carthaca: haha, nope, i just mean the discussion on that bug kinda dead-ended before you revived it 15:59:35 sure, it is a joke :) 15:59:42 carthaca: :) 15:59:52 okay, we'll see if anyone picks up the bug 16:00:02 we're out of time 16:00:21 please review stuff for feature freeze 16:00:26 and stay healthy 16:00:31 thanks for attending o/ 16:00:37 #endmeeting