15:00:23 <carloss> #startmeeting manila
15:00:23 <opendevmeet> Meeting started Thu Sep 28 15:00:23 2023 UTC and is due to finish in 60 minutes.  The chair is carloss. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <opendevmeet> The meeting name has been set to 'manila'
15:00:40 <haixin> o/
15:00:51 <carloss> courtesy ping: dviroel felipe_rodrigues vhari gouthamr carthaca msaravan pulluri
15:01:00 <carthaca> hi
15:01:07 <gouthamr> o/
15:01:13 <caiquemello[m]> o/
15:01:21 <vhari> hi
15:01:28 <felipe_rodrigues> o/
15:02:13 <thiagoalvoravel> o/
15:02:55 <gireesh> o/
15:03:28 <msaravan> o/
15:04:00 <dviroel> o/
15:04:35 <carloss> o/ hello everyone
15:04:45 <carloss> good quorum
15:04:47 <carloss> let's get started
15:05:11 <carloss> today's meeting agenda:
15:05:15 <carloss> #link https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:06:14 <carloss> #topic Announcements
15:06:23 <carloss> Schedule and Deadlines:
15:06:34 <carloss> #link https://releases.openstack.org/bobcat/schedule.html (Bobcat release schedule)
15:07:03 <carloss> 1 week to go until the final Bobcat release
15:08:09 <carloss> we are in a good shape so far
15:08:44 <carloss> in the next week, as usual, the foundation is promoting the OpenInfra live
15:09:19 <carloss> and in this episode, we will have some project representatives talking about big accomplishments of the projects during the Bobcat release
15:09:34 <carloss> I will be proudly presenting the Manila highlights
15:09:47 <carloss> the live will start at 14 UTC - one hour before this meeting
15:10:35 <carloss> unsure if we will be able to keep the live within the 1 hour that it is scheduler
15:10:44 <carloss> s/scheduler/scheduled
15:11:09 * carloss m-sch is taking over carloss' head
15:12:15 <carloss> so: gouthamr vhari ashrodri - could one of you please run the next week's upstream meeting? I'm pretty sure I'll be here, but there is a chance that I will need to divide my time between two things
15:12:34 <gouthamr> sure no problem carloss
15:12:40 <carloss> thanks gouthamr
15:13:47 <carloss> that's all I had for $topic - is there an announcement you would like to share with us?
15:17:01 <carloss> taking silence as no
15:17:14 <carloss> #topic Bobcat Bugsquash
15:17:43 <carloss> so, this is just a quick follow-up on the bugsquash
15:17:52 <carloss> #link https://etherpad.opendev.org/p/manilabobcatbugsquash
15:18:55 <carloss> we managed to close 9 out of all the bugs in the etherpad list, which is a good progress within the last week
15:19:14 <carloss> we can share more in-depth stats
15:19:34 <carloss> but I wanted to ask you: is there something you'd like to discuss about the bugs on that list?
15:19:55 <carloss> a change you proposed and you'd like to get some reviewers' attention?
15:21:33 <gireesh> bug link https://bugs.launchpad.net/manila/+bug/1996907 is fixed now, gouthamr suggested to cherry-pick to different branch, that also done
15:21:56 <gireesh> just need to one more round of sanity testing. i think if all ok we can merge this changes
15:22:00 <gireesh> https://review.opendev.org/c/openstack/manila/+/885213
15:22:17 <gireesh> above is the patch link
15:23:54 <gouthamr> thanks gireesh - a note in these, the NetApp CI has failures; if there’s an infra problem, the only way to know if these changes don’t break anything is if there are approvals from other netapp folks
15:24:58 <gouthamr> s/the only way to know/the only way for us non NetApp reviewers to know/
15:25:49 <msaravan> Yeah.. NetApp CI failures are taken as priority, and we'll address them soon. For now, we'll have reviews from folks to facilitate the merge.
15:26:03 <gouthamr> thank you
15:26:09 <carloss> oh, and I see the change is still on stable/xena
15:26:28 <carloss> could you please propose it on master, so we can follow the backporting procedure?
15:27:42 <carthaca> it seems it is cherrypicked to master https://review.opendev.org/c/openstack/manila/+/896759
15:28:06 <carloss> ah, okay - sorry about that
15:28:10 <carloss> only saw the xena link
15:29:18 <gireesh> thanks, carthaca for putting the link
15:29:21 <carthaca> No, I think you are right - it should be the other way around. Proposed to master and cherry picked to xena than down the line, I think
15:30:16 <carloss> yep - the commit message has the "cherry-picked from" marker
15:31:30 <gireesh> so I need to abandon my patch and first merge to master and then cherry pickup to other branches
15:34:58 <carloss> I think on master, if you did the cherry-pick of your commit on top of the branch, only deleting the "cherry-picked from" from the commit message will do
15:35:48 <gireesh> ok, thanks will do that
15:36:08 <carloss> and as you have the backports in place, just reusiung the changes and modify the "cherry-picked from" to match the previous commits should do
15:36:27 <carloss> np
15:37:04 <gireesh> thanks, will take care of it
15:37:07 <carloss> thanks gireesh
15:38:41 <carloss> okay, so I believe we can go to the next topic
15:38:51 <carloss> #topic Hiding security service details
15:39:16 <carloss> this is related to an issue reported a while ago
15:39:18 <carloss> #link https://bugs.launchpad.net/manila/+bug/1817316
15:39:37 <carloss> and gouthamr and I chatted about it earlier this week
15:39:43 <carloss> we wanted to bring this up again
15:41:01 <carloss> there was a fix proposed a while ago:
15:41:13 <carloss> #link https://review.opendev.org/c/openstack/manila/+/766519 (Remove password field from security service)
15:41:45 <carloss> it basically does an API bump so that starting from a version, it will stop displaying the security service password
15:41:51 <felipe_rodrigues> it partially fixes the problem
15:41:57 <carloss> but that would not be ideal in our understanding
15:42:03 <carloss> felipe_rodrigues: yep
15:42:17 <felipe_rodrigues> from the security view, the problem isn't solved..
15:43:18 <carloss> with would not be ideal I mean:
15:43:18 <carloss> you'd still be able to list passwords if you used an older version in your requests, so we believe that redacting the password field from the security services would be the way to go with this fix
15:43:50 <carloss> > from the security view, the problem isn't solved..
15:43:50 <carloss> yep - password would still be stored in plain text, which was the initial issue
15:44:09 <carloss> gouthamr: would you like to add something?
15:45:51 <gouthamr> i agree this is a partial fix
15:46:42 <gouthamr> but, it does resolve a good part of the problem
15:46:53 <gouthamr> so lets treat it as two separate issues..
15:47:10 <gouthamr> since Eduardo's stepped away, is there anyone that can pick up this fix and complete it?
15:48:01 <felipe_rodrigues> I can take it. it seems an interesting issue
15:48:18 <carloss> ++ for separate issues
15:48:40 <gouthamr> we can discuss encryption and storage during the PTG perhaps.. carthaca suggested using barbican as a way for users to provide us the password as an encrypted secret
15:48:41 <felipe_rodrigues> so, should we remove the bump version removing from all versions and solve the conflicts ?
15:49:08 <carloss> thanks felipe_rodrigues - yeah, we'd just need to remove the API bump and do the redacting bits
15:49:11 <gouthamr> felipe_rodrigues: not remove, i agree with carthaca/carloss that we would obfuscate it
15:49:23 <carloss> and the conflicts
15:50:09 <felipe_rodrigues> sorry, remove or not remove ?
15:50:54 <gouthamr> remove != redact :)
15:51:08 <carloss> do not remove the field, just obfuscate it, but it shouldn't be something only for a specific API version
15:51:14 <carloss> so we don't need to do the API version bump
15:51:32 <carloss> and we'll be backporting it
15:52:09 <felipe_rodrigues> nice. Remove API version bump and solve conflicts. got it!
15:52:19 <gouthamr> what we mean is, the "password" field must be present in the API responses, it should have a value set to "******" or something
15:52:30 <carloss> ^
15:52:36 <carloss> thanks!
15:52:48 <carloss> > we can discuss encryption and storage during the PTG perhaps.. carthaca suggested using barbican as a way for users to provide us the password as an encrypted secret
15:52:48 <carloss> ++ on this
15:53:41 <carthaca> I would vote for doing both: removing in a newer microversion has also benefits
15:54:05 <carthaca> If it is anyhow redacted, there is not much value in having it
15:55:20 <carthaca> But I'm also fine with letting the clients make that decision :)
15:55:54 <carloss> carthaca:  yeah... feasible too
15:56:55 <carloss> making it redacted is good because it would be something backportable
15:57:08 <felipe_rodrigues> I think the idea is to avoid break any API caller that might read this field. If we remove the field, can we still backport ?
15:57:29 <carloss> felipe_rodrigues: nope, new API would not be backportable
15:57:59 <felipe_rodrigues> got it! thanks all
15:58:34 <carloss> so I'd be okay with doing both too - while redacting we can try to make some noise to say it will be dropped if that's the case, but would be nice to get more feedback on the removal if possible
15:59:20 <carloss> so: let's go for redacting and making the removal a part of the C PTG alongside the other discussion part with the barbican approach
15:59:46 <carloss> is it okay?
16:00:12 <felipe_rodrigues> ok
16:00:38 <carloss> ack
16:00:43 <carloss> we're at the top of the hour
16:00:54 <carloss> let's wrap up
16:01:07 <carloss> sorry for not having time for bug triaging vhari - and thanks for putting the list together
16:01:14 <carloss> we can get some extra time to do it next week
16:01:26 <carloss> thank you everyone for participating
16:01:33 <carloss> see you on #openstack-manila
16:01:39 <carloss> #endmeeting