15:00:21 <carloss> #startmeeting manila
15:00:21 <opendevmeet> Meeting started Thu Jun 27 15:00:21 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:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:21 <opendevmeet> The meeting name has been set to 'manila'
15:00:34 <haixin> o/
15:00:39 <carloss> courtesy ping: dviroel vhari gouthamr carthaca msaravan pulluri ashrodri
15:00:53 <vhari> o/
15:00:54 <carthaca> hi
15:01:05 <gireesh> hi
15:01:21 <msaravan> hi
15:01:33 <gouthamr> hello o/
15:02:13 <jayaanand> hi
15:03:33 <ashrodri> o/
15:03:37 <chuanm> hi
15:04:10 <ccokeke[m]> Hello
15:04:18 <carloss> o/ hello everyone! good quorum
15:04:21 <carloss> let's get started
15:04:32 <carloss> our meeting agenda for today:
15:04:33 <carloss> #link https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:05:20 <carloss> first up
15:05:22 <carloss> #topic Announcements
15:05:28 <carloss> Schedule and Deadlines
15:05:43 <carloss> #link https://releases.openstack.org/dalmatian/schedule.html (Dalmatian release schedule)
15:06:15 <carloss> This is our spec freeze week
15:06:38 <carloss> We are currently targeting two specs for this deadline
15:06:50 <carloss> thank you everyone for providing feedback on the specs!
15:07:59 <carloss> I think we are getting close, but we still need to close some details on the two specifications
15:08:36 <carloss> Add spec lite for resource metadata backend operations
15:08:36 <carloss> #link https://review.opendev.org/c/openstack/manila-specs/+/916595
15:08:54 <carloss> and
15:08:54 <carloss> Add spec for ensure shares
15:08:54 <carloss> #link https://review.opendev.org/c/openstack/manila-specs/+/915480
15:09:32 <carloss> in case we can't hash out all of the details over this week, update and merge the specs
15:09:39 <carloss> we can have a one week extension
15:10:31 <carloss> that's all I had on the spec freeze deadline
15:11:37 <carloss> also, according to our first bugsquash event for this release is happening in two weeks
15:12:23 <carloss> it will happen in the week of Jul 08 to Jul 12
15:12:56 <carloss> do you have any considerations to share on the dates? if a majority of us won't be able to spend the time in that week, we can discuss new dates close to this one
15:13:51 <carloss> I think we can follow the same format as before: using a shorter contribution period, i.e. starting on Wednesday and ending on a Friday
15:14:36 <carloss> any suggestions? thoughts?
15:15:40 <carloss> taking silence as no
15:16:28 <carloss> we will discuss it again in the next meeting
15:16:36 <carloss> and the last announcement I'd like to share:
15:16:57 <carloss> the release naming process is open!
15:17:38 <gouthamr> (next week's meeting is a holiday in the US)
15:18:18 <carloss> oh, maybe we can discuss this in openstack-manila earlier then?
15:18:30 <carloss> and send the email with at least 1 week notice
15:18:35 <gouthamr> ++
15:18:51 <carloss> gouthamr: thanks
15:18:59 <carloss> so on the release naming process: you might have received this email: 2025.1 E OpenStack Release Naming Poll
15:19:29 <carloss> please make your vote count
15:19:44 <carloss> and help us chose what is going to be the next release name
15:19:50 <carloss> #link https://civs1.civs.us/cgi-bin/results.pl?id=E_d8469898c60545f2 (Voting poll results)
15:20:02 <carloss> current leader is Epoxy, but Ermine is very close
15:20:18 * carloss thinks Ermine is as close as we can get from a Zorilla :p
15:20:51 <carloss> so please participate in the voting process :)
15:21:02 <carloss> that's all I had for announcements. Do you have something you'd like to share?
15:22:05 <carloss> taking silence as no...
15:22:07 <carloss> #topic Review Focus
15:22:28 <carloss> #link https://etherpad.opendev.org/p/manila-dalmatian-review-focus (Dalmatian review focus etherpad)
15:23:33 <carloss> so as I said, this is spec freeze week, and we have some specs waiting to be merged
15:23:42 <carloss> I think both are fine in terms of people reviewing
15:23:55 <carloss> is there any concern that showed up on the reviews and you would like to bring up in this meeting?
15:26:48 <carloss> alright
15:27:14 <carloss> let's try to keep up with the reviews in the specs and aim to merge them this week
15:27:31 <carloss> if we can't, then I think merging them by the end of the next week would not be that bad
15:28:32 <carloss> is there another change you'd like to get some reviewers attention?
15:29:27 <carloss> #topic Bug Triage (vhari)
15:29:38 <carloss> #link https://etherpad.openstack.org/p/manila-bug-triage-pad-new (Bug Triage etherpad)
15:29:44 <vhari> ty carloss :)
15:30:01 <carloss> np
15:30:08 <carloss> thankfully launchpad is working today
15:30:11 <vhari> so all recent manila bugs are in progress - thanks to all contributors :)
15:30:24 <vhari> ack
15:30:46 <vhari> #link https://bugs.launchpad.net/python-manilaclient/+bug/2068631
15:31:32 <vhari> looking for minor triage
15:34:22 <vhari> maybe a good low-hanging-fruit
15:35:02 <carloss> nice use case, thanks for the bug report carthaca
15:35:17 <carloss> this will require some changes in the API, but I think they are not major changes
15:35:24 <carloss> so +1 for low-hanging fruit
15:35:55 <carloss> in reality, I think this already works if we specify source share server id among the filters
15:36:05 <carthaca> API changes are not required for that one, this is client only ;)
15:36:25 <carloss> yeah
15:36:27 <carloss> #link https://github.com/openstack/manila/blob/master/manila/api/v1/share_servers.py#L74
15:36:35 <carloss> this ^ should get us covered
15:37:11 <carloss> is there anyone willing to give this fix a try?
15:37:43 <carloss> likely a good candidate for bugsquash too :)
15:37:55 <vhari> carloss++
15:39:07 <vhari> if anyone is interested pls assign the bug to yourself :)
15:39:16 <carloss> so prio can be low, as it is an RFE, we can target it to m-3
15:39:50 <vhari> ack
15:39:57 <vhari> jumping to next bug https://bugs.launchpad.net/python-manilaclient/+bug/2068732
15:43:25 <carloss> hmm, interesting
15:43:43 * carloss looks at the code
15:43:44 <carthaca> That one is about a very interesting API, because the ID of the share server you can specify in the url is an ID of an object that can already be gone xD
15:46:28 <carloss> yeah, a bit weird to think in that sense
15:46:41 <carloss> I think this is happening in the CLI because of this: https://github.com/openstack/python-manilaclient/blob/85f21732176ed6218e4b8b64ac3261dd40f54c7a/manilaclient/osc/v2/share_servers.py#L539
15:47:04 <carloss> we are trying to look up the share server before we send the request
15:47:41 <carloss> which makes sense when the share server still exists, but doesn't when the migration was successful
15:47:48 <carloss> and the former share server was deleted
15:49:23 <carloss> > yeah, a bit weird to think in that sense
15:49:23 <carloss> I mean, the operation sounds confusing, but I think that's the expected behavior at the end
15:49:32 <carloss> xD
15:50:27 <carloss> iirc the get progress works for both source and destination
15:50:32 <carloss> in this case, I think we would need to:
15:51:13 <carloss> - try to get the share server that was specified
15:51:13 <carloss> - if not found, we send a request to get share servers and filter by the source share server ID
15:51:28 <carloss> - and then send the request to Manila using the destination share server
15:52:02 <carloss> it will add a couple more steps for the OSC to perform and the operation can end up taking some seconds, but I think it would work
15:52:30 <carloss> > - if not found, we send a request to get share servers and filter by the source share server ID
15:52:30 <carloss> if none was found, then we just say the share server wasn't found
15:52:33 <carloss> carthaca: wdyt?
15:53:17 <carloss> > iirc the get progress works for both source and destination
15:53:17 <carloss> I meant you can specify either the source or the destination share server id in the request, and it should work just fine
15:53:21 <carloss> lemme double check that
15:53:23 <carthaca> the migration get progress API works with the source share server id, no need to do additional calls, I would say
15:56:05 <carloss> yeah... I was confused because I remember we at least had the discussion of trying to make the get progress call work with both source and destination share server ids
15:57:30 <carloss> so this could and could not be a low hanging fruit. I'd say we can try dropping the share server lookup and sending the request directly to Manila
15:57:44 <carloss> the share/api is handling that just fine
15:58:12 <carloss> so I'd say this is also a low hanging fruit, and we can target this to the client release milestone
15:58:39 <carloss> carthaca: is there anyone from SAP willing to work on this?
15:59:03 <carloss> if not, we can try to find volunteers or bringing this up at the bugsquash too
16:00:05 <carloss> time check :)
16:00:06 <carthaca> sorry, I don't have volunteers right now
16:00:12 <carloss> carthaca: no worries
16:00:20 <carloss> we can look for people that can fix the bug
16:00:22 <carloss> thanks for the bug report
16:00:57 <carloss> vhari: thank you for working on the list of bugs for this week
16:01:15 <vhari> yw carloss
16:01:21 <carloss> let's get back to #openstack-manila
16:01:24 <carloss> #endmeeting