15:00:18 <carloss> #startmeeting manila
15:00:18 <opendevmeet> Meeting started Thu Jun 13 15:00:18 2024 UTC and is due to finish in 60 minutes.  The chair is carloss. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:18 <opendevmeet> The meeting name has been set to 'manila'
15:00:39 <carloss> courtesy ping: dviroel vhari gouthamr carthaca msaravan pulluri ashrodri
15:00:53 <dviroel> o/
15:01:22 <kpdev> hi
15:01:41 <ashrodri> o/
15:01:44 <carthaca> hi
15:01:44 <gouthamr> o/
15:02:03 <vhari> hi
15:02:08 <haixin> o/
15:02:21 <jayaanand> hi
15:02:38 <ccokeke[m]> Hello
15:02:59 <gireesh> hi
15:03:22 <msaravan> Hi
15:04:05 <carloss> hello everyone!
15:04:10 <carloss> good quorum, let's get started
15:04:32 <carloss> our meeting agenda for today:
15:04:38 <carloss> #link https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:05:35 <carloss> #topic Announcements
15:05:41 <carloss> Schedule and Deadlines
15:05:52 <carloss> #link https://releases.openstack.org/dalmatian/schedule.html
15:06:42 <carloss> we're 2 weeks away from spec freeze and 4 weeks away from our bugsquash
15:08:55 <carloss> for spec freeze, I think we are in the right path and some details of the two specs being proposed are being hashed out
15:09:09 <carloss> thank you everyone that managed to share their thoughts on the specs
15:09:31 <kpdev> i would like to have more thoughts on spec
15:10:09 <kpdev> earlier reviewers mentioned that metadata update should be considered as superset of share properties. And should be applicable for all possible share operations e.g. shrink, extend etc.
15:11:12 <kpdev> so if set property x in share type extra spec and then similar property in share metadata, the share metadata value would overwrite property x from share type (which is applicale for all shares of that type)
15:11:23 <kpdev> how best can we achieve this ?
15:13:22 <gouthamr> ( have to read this through; I haven’t looked at these comments yet)
15:13:37 <kpdev> that would be helpful
15:14:55 <carloss> I think that we need to think of something in the lines of: do we want the share type capability to be modified for a specific share?
15:14:57 <gouthamr> it could get very confusing to users if share type extra specs and metadata are both visible and are both mutable
15:15:45 <ashrodri> is overriding share type spec with share metadata a user capbility, or admin?
15:16:17 <kpdev> few are admin only and rest for all users.
15:16:26 <gouthamr> not all share type extra specs are tenant visible - and those that are visible, and mutable are copied over to the share currently - for example: create_share_from_snapshot_support - the idea is that if the share type is modified, and the value of such a spec is changed, it doesn’t affect existing shares
15:17:17 <gouthamr> users know the behavior within an existing share because there’s a corresponding “property” (not in the metadata table, but an immutable metadata of sorts) on the share itself
15:18:09 <gouthamr> so id think we need a similar mechanism if we’re starting to throw in more such concepts through (user modifiable) metadata
15:19:27 <gouthamr> I wonder, kpdev - is your use case entirely around modifying what’s in share type extra specs today ? have you considered a “retype” sort of workflow instead of this approach?
15:19:54 <kpdev> my spec was just forward metadata update to backend driver and perform action if possible
15:20:01 <gouthamr> we don’t have retype - but, cinder does and there were requests to add that feature in the pst
15:20:25 <kpdev> but recent reviews are inclined to use metadata not only in update but also for all possible share operations.
15:21:04 <gouthamr> I see; thanks for the call out… I will take a look and comment
15:21:05 <kpdev> and also use that metadata as properties uniqeu to that share, which means it will override the properties of share that comes from share_type of that share
15:23:23 <carloss> gouthamr: thanks :)
15:23:35 <carloss> let's continue the discussion in the spec
15:23:35 <gouthamr> ^ i can't think of the overlapping properties...
15:26:06 <gouthamr> > let's continue the discussion in the spec
15:26:06 <gouthamr> +1
15:26:39 <carloss> #topic Review focus
15:26:45 <carloss> #link https://etherpad.opendev.org/p/manila-dalmatian-review-focus
15:26:59 <carloss> I have cleared up  some things in our review focus etherpad
15:28:05 <carloss> and I need to populate it with some more fixes
15:28:20 <carloss> this for example:
15:28:31 <carloss> #link https://review.opendev.org/c/openstack/manila/+/912777 (Fix for our pylint job)
15:28:47 <carloss> our pylint job has been broken for a while and I'm trying to fix it
15:29:03 <carloss> haixin kpdev ashrodri: can I have your eyes on this change?
15:29:10 <ashrodri> yes
15:29:23 <carloss> thank you!
15:29:26 <haixin> sure
15:30:16 <carloss> thanks
15:31:52 <carloss> just added two other fixes from kpdev to the list
15:32:15 <carloss> msaravan gireesh jayaanand: can we have your eyes on
15:32:26 <carloss> #link https://review.opendev.org/c/openstack/manila/+/920382 (NetApp - Fix share revert to snapshot)
15:32:31 <carloss> ?
15:32:50 <gireesh> sure
15:32:51 <msaravan> Yes, kpdev pinged us.. we'll work on it today/tomorrow.
15:33:16 <carloss> thank you! :)
15:33:43 <msaravan> Was occupied with lot of customer queries/solution.. last week.. good thing is, they all wanted Manila..and they love our tenancy model - DHSS=True for datacenter.
15:35:31 <carloss> msaravan: good stuff, DHSS=True is indeed very nice :D
15:36:11 <carloss> is there another change you would like to bring up during this meeting?
15:37:51 <carloss> going once..
15:37:56 <carloss> going twice..
15:38:02 <carloss> #topic Bug Triage
15:38:08 <carloss> vhari: o/ floor is yours
15:38:17 <vhari> hi
15:38:21 <carloss> #link https://etherpad.opendev.org/p/manila-bug-triage-pad-new (Bug triage etherpad)
15:38:21 <vhari> lets dive in
15:38:25 <vhari> #link https://bugs.launchpad.net/manila/+bug/2069230
15:40:03 <vhari> global id will help API tracing b'n manila and other services
15:40:26 <vhari> so this is an ask, long pending
15:40:31 <gouthamr> +1
15:40:43 <vhari> seems easy to implement?
15:40:51 <gouthamr> medium prio i think
15:41:04 <carloss> #link https://etherpad.opendev.org/p/dalmatian-ptg-manila-sap#L72 (Discussion of the topic at the PTG)
15:41:06 <vhari> ack
15:41:17 <vhari> plenty of examples ^^
15:41:24 <carloss> yeah, we are starting to get more attention to this
15:41:28 <carloss> ++ on medium prio
15:42:03 <vhari> lhf?
15:42:16 <gireesh> can we add https://bugs.launchpad.net/tempest/+bug/2069125 bug also in list
15:42:31 <gireesh> one of the customer is hitting this issue
15:42:46 <gireesh> we need to correct few field for this bug
15:42:52 <gireesh> I am working on this
15:44:23 <carloss> vhari: yes, sounds like lhf
15:45:11 <gouthamr> the global request id thing?
15:45:21 <gouthamr> probably not a LHF in our terms
15:45:58 <vhari> gouthamr, ack
15:47:26 <vhari> is anyone interested in taking this? :)
15:47:52 <carloss> gireesh: yep, we can add it to the list :D
15:48:05 <gireesh> sure
15:48:35 <vhari> if no other thoughts .. next up
15:48:39 <vhari> #link https://bugs.launchpad.net/manila/+bug/2069270
15:49:11 <vhari> gireesh++ I added the bug to the list
15:49:34 <carloss> vhari: sorry, previous bug might be a good challenge for someone looking for some fun... ashrodri would you be willing to take a look at it?
15:50:04 <gireesh> thanks vhari
15:50:10 <vhari> np, carloss I updated bug notes
15:50:20 <carloss> thanks
15:50:20 <ashrodri> ill take a look, thanks vhari
15:50:30 <vhari> ashrodri++ awesome
15:50:35 <carloss> ashrodri ++ :D
15:51:27 <vhari> have a few minutes to char about ^^ 2069270
15:51:36 <vhari> looking for minro triage atm
15:52:12 <carloss> might be a bit of an ignorance of mine, but would 2069270 apply to manila as well?
15:53:04 <vhari> or NetApp only?
15:54:10 <carloss> I was thinking likely cinder-only
15:54:55 <carloss> I remember at least when we were managing volumes, we checked if they had luns
15:55:05 <carloss> and if there were, we'd block the operation
15:55:22 <carloss> #link https://opendev.org/openstack/manila/src/commit/d773353502cd8932c31581cfbc3b80846067fe68/manila/share/drivers/netapp/dataontap/cluster_mode/lib_base.py#L2094
15:55:58 <carloss> netapp volumes (aka shares in Manila :p)
15:56:13 <carloss> gouthamr: I might be completely wrong here ^
15:56:29 * gouthamr is looking
15:57:00 <vhari> gireesh I moved #link https://bugs.launchpad.net/manila/+bug/2069270 to next week list
15:57:24 <gireesh> sure
15:57:40 <vhari> if you would like earlier discussions, pls bring it up in #openstack-manila
15:58:17 <vhari> gireesh, ty for sharing the bug
15:58:40 <gireesh> ur welcome
15:58:44 <gouthamr> carloss: sorry was in another meeting
15:58:53 <carloss> gireesh++ :)
15:58:55 <gouthamr> carloss: yeah that bug doesn't look relevant to manila
15:59:03 <carloss> gouthamr: np
15:59:07 <gouthamr> but, gireesh would probably know better :)
15:59:40 <gouthamr> basically it says we should name LUNs according to a different standard; the netapp driver in manila doesn't create any LUNs - all good
15:59:48 <carloss> yep
16:00:49 <carloss> alright, so we are at the top of the hour
16:01:05 <gireesh> i need to go through to this bug, I think saravana was looking into this bug
16:01:21 <carloss> sure, thank you! please update the bug accordingly
16:01:30 <carloss> and validate if the issue is indeed manila related
16:02:06 <carloss> gireesh: as vhari said, if you'd like to discuss the bug you brought up earlier, please bring it up in #openstack-manila
16:02:10 <carloss> let's wrap up
16:02:17 <carloss> thank you for participating
16:02:24 <gireesh> sure
16:02:24 <carloss> let's get back to #openstack-manila
16:02:37 <carloss> #endmeeting