15:01:36 <gouthamr> #startmeeting manila
15:01:36 <opendevmeet> Meeting started Thu Oct 14 15:01:36 2021 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:36 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:36 <opendevmeet> The meeting name has been set to 'manila'
15:01:38 <gouthamr> courtesy ping: ganso vkmc dviroel carloss tbarron felipe_rodrigues ecsantos vhari fabiooliveira
15:01:42 <felipe_rodrigues> o/
15:01:44 <fabiooliveira> o/
15:01:47 <ecsantos[m]> o/
15:01:48 <carloss> o/
15:01:48 <simondodsley> o/
15:01:49 <kafilat> o/
15:01:55 <nahimsouza> hi
15:01:58 <LeoCampelo> o/
15:02:02 <caiquemello> o/
15:02:07 <vhari> o/
15:02:18 <haixin> o/
15:02:28 <gouthamr> hello everyone o/ thanks for joining!
15:02:35 <gouthamr> lets get started..
15:02:40 <gouthamr> #topic Announcements
15:03:24 <gouthamr> a couple of call outs regarding next week's PTG
15:03:36 <tbarron> o/
15:03:45 <gouthamr> please see the updated timeslots for the various topics on our planning etherpad
15:03:47 <gouthamr> #link https://etherpad.opendev.org/p/yoga-ptg-manila-planning
15:04:35 <gouthamr> ^ this is different from last week - and hopefully the final schedule should work
15:05:15 <gouthamr> our meetup will be held on Zoom
15:05:38 <vkmc> o/
15:05:47 <gouthamr> you should be able to get onto the zoom call by clicking on the slot here:
15:05:50 <gouthamr> #link https://ptg.opendev.org/ptg.html
15:07:43 <gouthamr> carloss: thank you for running the last week's meeting :)
15:08:19 <carloss> my pleasure gouthamr :)
15:08:48 <gouthamr> as carloss mentioned last week, we'll begin PTG with a retrospective, a discussion about project health and plans at 1400 UTC on Monday, 18th Oct
15:08:52 <gouthamr> #link https://etherpad.opendev.org/p/manila-xena-retrospective
15:09:23 <gouthamr> ^ please add your thoughts there by that meeting
15:10:45 <gouthamr> i'll send out an email to openstack-discuss canceling next week's irc meeting since it overlaps with the manila meeting
15:11:45 <gouthamr> as we've done a few times in the past, we'll also drop the IRC meeting for the week after (28th Oct '21)
15:13:11 <gouthamr> if anyone finds other relevant PTG discussions happening elsewhere, please feel free to link them on the planning etherpad
15:14:40 <gouthamr> the foundation published the openstack user survey responses on to the mailing list
15:14:47 <gouthamr> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025340.html (2021 User Survey Project Specific Feedback Responses)
15:15:25 <gouthamr> you'll notice we had several questions on this survey (and somehow retained our old question from prior surveys as well)
15:16:20 <gouthamr> we'll analyze this together next week; it is encouraging to see an increase in respondents over the past surveys
15:16:57 <gouthamr> that's all the announcements i had... anyone else got any?
15:17:59 <gouthamr> #topic Stale bug triage
15:18:13 <gouthamr> #link https://ethercalc.openstack.org/kxz9jz7tuopk
15:18:53 <gouthamr> this has been a recurring topic for the past few weeks - we're attempting to re-triage bugs that haven't been updated in a long time (>3 years)
15:19:28 <gouthamr> we thought we could do a couple together as a team in today's meeting
15:19:56 <gouthamr> vhari: which ones do we go after?
15:20:11 <vhari> gouthamr, they are on LP etherpad
15:20:21 <vhari> #link https://bugs.launchpad.net/manila/+bug/1631314
15:20:30 <vhari> we can take a look at ^^
15:21:06 <vhari> We picked two to review today https://etherpad.opendev.org/p/manila-bug-triage-pad-new
15:21:13 <vhari> L:11-12
15:23:49 <gouthamr> hmm, no test code's changed - so this still gets encountered every now and then
15:24:42 <gouthamr> its not a real world scenario either - i.e., our tests are trying to do something for the sake of verifying a behavior per all the notes in the bug report
15:25:27 <gouthamr> dviroel's probably occupied - i wonder if this is an opportunity for this tempest decorator: https://docs.openstack.org/tempest/latest/library/decorators.html#tempest.lib.decorators.unstable_test
15:25:37 <gouthamr> #link https://docs.openstack.org/tempest/latest/library/decorators.html#tempest.lib.decorators.unstable_test (tagging unstable tempest tests)
15:26:46 <gouthamr> example usage: https://opendev.org/openstack/tempest/src/branch/master/tempest/scenario/test_network_advanced_server_ops.py#L267
15:28:00 <carloss> sounds like a good approach
15:28:18 <carloss> would avoid rechecks on this known issue
15:28:53 <fabiooliveira> I could add this tag on the tests
15:29:07 <gouthamr> great, thank you fabiooliveira
15:29:10 <carloss> fabiooliveira++
15:30:25 <gouthamr> ive dropped the asignee, can you grab the bug fabiooliveira
15:30:47 <gouthamr> we can target this to yoga-1
15:31:13 <vhari> fabiooliveira++
15:32:18 <vhari> gouthamr,  so a quick hint for stale bug reviewers ..
15:32:24 <vhari> the idea is not to triage the bug during our review, rather  update it approriately
15:32:24 <vhari> for example  this is the case where the bug is still relevant ..
15:32:24 <vhari> the reviewer  would add a comment to the bug  as such
15:32:24 <vhari> the comment will then  remove the bug from stale -> to be triaged  list
15:32:44 <gouthamr> ++
15:32:46 <vhari> next on the stale bug
15:32:48 <vhari> #link  https://bugs.launchpad.net/manila/+bug/1660825
15:33:32 * gouthamr scratches his head a bit
15:35:29 <tbarron> is the idea here that the manager would pass a dictionary of capability k/vs from the share type into the driver as another argument in, e.g. driver.create_share() ?
15:36:05 <tbarron> so then the driver would never have to do database lookups?
15:36:10 <gouthamr> yes
15:36:12 <gouthamr> i think so
15:36:52 <tbarron> This would require the change just mentioned in the manager, and then drivers that do the lookups would each need to change, right?
15:37:11 <gouthamr> true
15:37:20 <gouthamr> here's an example of such a lookup: https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/zfsonlinux/driver.py#L403
15:37:26 <tbarron> The first change could just go in pretty easily I think.  Drivers could just ignore it.
15:37:36 <felipe_rodrigues> I've seen some code in netapp side retrieving the specs using the type id
15:37:50 <felipe_rodrigues> because it is not passed down
15:37:57 <tbarron> Are there other DB lookups in drivers other than capabilities from share types?
15:38:02 <gouthamr> ack - drivers get the provisioning call, and they lookup the share type for the other capabilities
15:38:02 <felipe_rodrigues> QoS
15:38:12 <tbarron> I like drivers not doing DB lookups.
15:38:33 <felipe_rodrigues> tbarron++
15:39:03 <tbarron> or worse, db updates
15:40:39 <gouthamr> so adding the extra specs blob as share_instance['capabilities'] should solve this issue
15:41:46 <gouthamr> (and all the driver updates)
15:41:48 <tbarron> i see, no need for a separate argument on the calls into the driver.
15:42:53 <gouthamr> yes; if we can avoid changing the driver interface signature, it makes things easier
15:43:14 <felipe_rodrigues> If the problem is the round trip to the db, there are more info from the type that we normally use.. only passing the capabilities down would fix just part of problem...
15:44:28 <gouthamr> felipe_rodrigues: what else are we missing?
15:45:34 <felipe_rodrigues> all extra specs..
15:45:58 <gouthamr> ah, yes
15:46:09 <felipe_rodrigues> actually, the majority of NetApp round trip to the db is to retrieve the extra specs.. for the capabilities, I've not seen much
15:46:39 <felipe_rodrigues> Anyway, a get to db I dont see as a big issue... as tbarron said, updates must be avoid
15:47:22 <gouthamr> ah, yes - vkmc's update to the description adds that piece; we need all of the extra-specs since not all of them are in the share/instance models
15:48:23 <gouthamr> cool, vhari - so this issue still exists and is multi-part
15:48:44 <vhari> gouthamr, ack
15:48:55 <vhari> gouthamr, that's all we had for stale bugs
15:49:06 <gouthamr> its tagged Wishlist - which *could* mean RFE, but lets add that tag also
15:49:30 <vhari> gouthamr, will do
15:49:32 <gouthamr> the manager piece seems like a good first issue for someone trying to learn the code base
15:50:05 <gouthamr> we can update drivers separately in subsequent patches
15:50:14 <tbarron> +1
15:51:30 <gouthamr> great, i think we have time for triaging new bugs?
15:51:49 <gouthamr> #topic Bug Triage (vhari)
15:52:27 <vhari> gouthamr, not reviewing patches
15:52:45 <vhari> :) if so lets take a look at #link https://bugs.launchpad.net/manila/+bug/1900755
15:53:37 <vhari> we had one new bug this week which is in progress .. ^^ bugs was added to etherpad
15:53:49 <gouthamr> thanks vhari
15:53:55 <gouthamr> "Seems like NetApp driver is not raising the error "SecurityServiceFailedAuth". We need to fix NetApp driver."
15:54:53 <gouthamr> #link https://review.opendev.org/c/openstack/manila/+/764489 (Add exception for insufficient privileges when using security services)
15:54:58 <gouthamr> was tagged a partial fix
15:55:15 <gouthamr> gah, my bad
15:55:40 <gouthamr> i'll re-open this bug
15:56:10 <gouthamr> ecsantos[m]: were you working on the netapp driver portion of this bug-fix?
15:57:57 <felipe_rodrigues> From what I know, we've not started working on it...
15:58:26 <gouthamr> ack, ty felipe_rodrigues.. i've set this back to "in progress"
15:58:36 <ecsantos[m]> gouthamr: yes I was, some time ago. I'm yet to work on a backport to Victoria that was asked in IRC, but it shouldn't be too much work
15:59:26 <gouthamr> ecsantos[m]: great, ty..
16:00:41 <gouthamr> glad you bubbled this up, vhari (and for noticing this kiran pawar) - in my fervent insecurity about our bug bot, i missed the "partial-bug" call out in the commit message
16:01:06 <vhari> gouthamr, yw :D
16:01:16 <gouthamr> we're at the hour
16:01:30 <gouthamr> if you have more to chat, please hop on over to #openstack-manila
16:01:34 <gouthamr> thank you all for attending
16:01:48 <fabiooliveira> :D
16:01:58 <gouthamr> excited to see you all at the PTG next week!
16:02:02 <gouthamr> #endmeeting