15:00:22 #startmeeting manila 15:00:26 Meeting started Thu Feb 11 15:00:22 2021 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:29 The meeting name has been set to 'manila' 15:00:34 o/ 15:00:38 Hi 15:00:43 courtesy ping: ganso vkmc lseki carloss andrebeltrami felipe_rodrigues esantos 15:00:46 Hi 15:00:50 o/ 15:00:52 o/ 15:00:53 o/ 15:01:17 hello o/ 15:01:19 hi 15:01:48 hi 15:01:50 hi 15:01:58 Hi 15:02:21 #topic Announcements 15:02:40 a look at where we are in the release cycle: 15:02:46 #link https://releases.openstack.org/wallaby/schedule.html 15:03:02 today's feature proposal freeze 15:03:20 All new Manila features must be proposed and substantially completed, with unit, functional and integration tests by the end of the week. 15:03:39 deadlines are thursday of the week ^ 15:04:11 however, we'll be okay if you want to sneak in any changes by EOW 15:04:32 :) 15:04:41 o/ 15:04:42 hi 15:05:13 feature freeze (for manila-ui and manila) and client release is in 4 weeks 15:05:44 so we'll need all that time to ensure feature patches are working as intended, and cause no regressions 15:06:16 that's all i had in terms of announcements, we'll touch upon reviews in a bit - any one else got any news they want to share? 15:06:33 gouthamr: yes 15:06:48 floor's yours dviroel 15:06:55 almir-okato: joined our team. welcome almir-okato 15:07:03 \o/ 15:07:07 nice! welcome, almir-okato 15:07:07 welcome almir-okato 15:07:23 welcome almir-okato! :D 15:07:23 thanks!! 15:07:37 hope to see him pushing some code for manila :) 15:07:37 but should help us also with cinder patches 15:08:14 :) 15:08:34 great! ty for the intro dviroel 15:08:58 yes, I'm new to openstack world, but I hope contribute the best I can in the near future 15:09:09 almir-okato++ 15:09:16 almir-okato++ welcome 15:09:27 Welcome almir-okato 15:09:42 thanks guys :) 15:10:34 almir-okato: you'll find a friendly group here to help you get up to speed - friendliest some would say :D - glad to have you 15:10:42 any other announcements? 15:11:23 let's switch to other regular programming 15:11:27 #topic Reviews needing feedback 15:11:37 #link https://etherpad.opendev.org/p/manila-wallaby-review-focus (Wallaby cycle review focus etherpad) 15:12:07 a couple of things merged, and some others close to merging - all good progress! 15:12:59 added new ones today ;) 15:13:29 ah i see, lines 86-107 now 15:13:40 okay, do we need to talk about any of these in particular? 15:14:44 thanks for adding the manila-ui ones, disap? vkmc? 15:15:03 disap 15:15:29 * vkmc waits for disap 15:15:38 ok so, we can do this together 15:15:55 last week we were blocked by a dependency breaking our integration tests gate 15:16:02 this is for share shrinking feature addition 15:16:11 it's now unblocked 15:16:50 and we can proceed reviewing the patches we have on the queue 15:16:54 ++ 15:17:02 share resize is priority, that's disap's internship project 15:17:03 good work with the horizon team! 15:17:19 so if you can take a look, that would be very appreciated 15:17:34 #link https://review.opendev.org/c/openstack/manila-ui/+/767017 (Addition of share shrinking feature to Manila-UI) 15:17:51 and we also have the api microversions bumps patches, right now I was reviewing api v2.42, v2.43 15:17:57 and disap is working in v2.44 15:18:14 those are the main changes 15:18:38 that need reviewing 15:20:00 thanks vkmc - others, please sign up on the etherpad if you are reviewing these changes 15:20:48 alright, any other reviews that need attention? 15:22:00 There are a number of OSC/manilaclient changes: https://review.opendev.org/q/project:openstack%252Fpython-manilaclient+status:open 15:23:02 i'm looking to revive vkmc's effort of replacing our use of keystoneclient with keystoneauth 15:23:08 #link https://review.opendev.org/c/openstack/python-manilaclient/+/647538 15:23:26 i'm hoping this is a good set of changes to merge for the upcoming release of the client 15:23:59 ofcourse it is a lot to review :) so def need all hands on deck, or any number you can spare! 15:24:37 alright lets move on.. 15:24:44 #topic Bugs (vhari) 15:24:59 o/ vhari - you're up! 15:25:07 gouthamr, aye :) 15:25:26 starting with 2 new bugs .. 15:25:27 #link https://bugs.launchpad.net/manila/+bug/1915237 15:25:28 Launchpad bug 1915237 in OpenStack Shared File Systems Service (Manila) "Share migration with NetApp fails compatibility check due to encryption" [Undecided,Confirmed] 15:25:45 needs initial triage 15:26:08 yep, i just confirmed that the issue happens 15:26:20 dviroel++ 15:26:37 thanks dviroel - a low, rc bug? 15:26:52 gouthamr: yes 15:27:05 is it just the volume move API that's affected though? 15:27:37 gouthamr: not sure, we need to consider bring a ONTAP 9.0 to our ci 15:27:57 and also, take a look on ontapi doc 15:28:05 which might be easier :) 15:28:13 ack 15:29:08 dviroel, should be assign it to you for intial work ? :) 15:29:10 vhari: you can assign this one to me 15:29:30 dviroel, awesome ! 15:29:35 next up #link https://bugs.launchpad.net/manila/+bug/1915094 15:29:36 Launchpad bug 1915094 in OpenStack Shared File Systems Service (Manila) "[Netapp] Stale pools data is not removed from cache after timeout" [Undecided,New] 15:31:12 thanks for reporting this issue vhari - i can confirm this behavior 15:31:37 humm 15:31:41 however, i don't think it's the driver at play - the scheduler's up-to-date with the latest information from the backend 15:32:06 however, the GET scheduler-stats/pools API looks at cached information 15:32:33 and that cache isn't getting updated per the latest update 15:32:50 gouthamr, ack that's what we noted from the scheduler logs 15:33:06 so it doesn't really affect provisioning 15:33:34 teh workaround is to bounce the scheduler service, and the get-pools info is refreshed because the cache is cleared 15:34:10 however, the fix ought to be that the cache is updated on each update from the backend 15:35:54 since it's an admin API, and doesn't affect provisioning, we can tag this low, can be convinced if someone thinks this ought to be a medium bug 15:36:26 gouthamr, +1 there is a workaround 15:36:51 anyone interested to take this one? 15:37:52 🦗 15:38:02 :) 15:38:21 * gouthamr squints to see the emoji in his dark themed client 15:38:42 🦨 15:38:58 ah, a popular intellectual insect :P 15:39:45 alright, vhari - lets target this to rc1, and low, and i'll take it 15:40:04 gouthamr++ 15:40:06 :) 15:40:10 :) 15:40:30 neeeeext #link https://bugs.launchpad.net/manila/+bug/1855391 15:40:31 Launchpad bug 1855391 in OpenStack Shared File Systems Service (Manila) "if all backend down, the status of share will stuck in "extending" when we extend an share" [Medium,In progress] - Assigned to haixin (haixin77) 15:40:50 this was looped out couple time .. a patch was out .. 15:41:30 target m-3 .. do we think we need anything to move forward ? 15:42:13 nope, looks like the fix needs to be rebased and reviewed 15:42:46 gouthamr, ack 15:42:54 * dviroel brb 15:42:59 #link https://bugs.launchpad.net/manila/+bug/1867030 15:43:00 Launchpad bug 1867030 in OpenStack Shared File Systems Service (Manila) "Force delete does not work if share service is down" [Medium,Confirmed] 15:43:04 * gouthamr adds it to the review focus etherpad 15:43:26 waiting for feedback on this issue 15:44:07 yes - this one is a corner case usage of the service 15:44:59 an example here is if you decide to decommission your storage while you still have manila shares on it 15:45:14 you'd disable/remove the corresponding share service 15:45:28 and that makes deletions hard 15:45:46 * dviroel back 15:46:06 a true corner case, since we don't expect the share service to be down indefinitely at any time 15:46:14 except when it's deliberate 15:46:25 gouthamr, ack 15:46:53 gouthamr, continue to track as a Med ? 15:47:12 a "manila-manage share delete" would be a better solution 15:47:26 basically a tool to clean up a zombie share 15:47:33 without ever hitting the backend 15:49:13 vhari: yes, i'll add these thoughts back to the bug, and see if we can tag this a low-hanging-fruit 15:49:26 gouthamr, cool 15:49:42 gouthamr, thanks.. that's a wrap for bugs today :) 15:50:11 if we do provide a way to directly delete from the database, we should probably include an additional guardrail - need to think what that can be 15:50:32 with share deletion when it's in a share group, we force users to provide the share group id 15:51:02 as a way to confirm their intent, and prevent fat fingering 15:51:08 ack, thank you vhari 15:51:14 #topic Open Discussion 15:51:22 gouthamr, yw .. updates made ! 15:52:54 anything else for today? 15:53:44 alright, that's a wrap... thanks everyone! 15:53:54 see you in #openstack-manila, and here next week! 15:53:58 #endmeeting