Thursday, 2023-09-28

*** chuanm3 is now known as chuanm05:58
*** chuanm8 is now known as chuanm06:07
*** dasm is now known as Guest155507:16
*** Guest1555 is now known as dasm14:48
carloss#startmeeting manila15:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'manila'15:00
haixino/15:00
carlosscourtesy ping: dviroel felipe_rodrigues vhari gouthamr carthaca msaravan pulluri15:00
carthacahi15:01
gouthamro/15:01
caiquemello[m]o/15:01
vharihi15:01
felipe_rodrigueso/15:01
thiagoalvoravelo/15:02
gireesho/15:02
msaravano/15:03
dviroelo/15:04
carlosso/ hello everyone15:04
carlossgood quorum15:04
carlosslet's get started15:04
carlosstoday's meeting agenda:15:05
carloss#link https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting15:05
carloss#topic Announcements15:06
carlossSchedule and Deadlines:15:06
carloss#link https://releases.openstack.org/bobcat/schedule.html (Bobcat release schedule)15:06
carloss1 week to go until the final Bobcat release15:07
carlosswe are in a good shape so far15:08
carlossin the next week, as usual, the foundation is promoting the OpenInfra live15:08
carlossand in this episode, we will have some project representatives talking about big accomplishments of the projects during the Bobcat release15:09
carlossI will be proudly presenting the Manila highlights15:09
carlossthe live will start at 14 UTC - one hour before this meeting15:09
carlossunsure if we will be able to keep the live within the 1 hour that it is scheduler15:10
carlosss/scheduler/scheduled15:10
* carloss m-sch is taking over carloss' head15:11
carlossso: 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 things15:12
gouthamrsure no problem carloss15:12
carlossthanks gouthamr 15:12
carlossthat's all I had for $topic - is there an announcement you would like to share with us?15:13
carlosstaking silence as no15:17
carloss#topic Bobcat Bugsquash15:17
carlossso, this is just a quick follow-up on the bugsquash15:17
carloss#link https://etherpad.opendev.org/p/manilabobcatbugsquash15:17
carlosswe managed to close 9 out of all the bugs in the etherpad list, which is a good progress within the last week15:18
carlosswe can share more in-depth stats15:19
carlossbut I wanted to ask you: is there something you'd like to discuss about the bugs on that list?15:19
carlossa change you proposed and you'd like to get some reviewers' attention?15:19
gireeshbug link https://bugs.launchpad.net/manila/+bug/1996907 is fixed now, gouthamr suggested to cherry-pick to different branch, that also done 15:21
gireeshjust need to one more round of sanity testing. i think if all ok we can merge this changes 15:21
gireeshhttps://review.opendev.org/c/openstack/manila/+/88521315:22
gireeshabove is the patch link 15:22
gouthamrthanks 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 folks15:23
gouthamrs/the only way to know/the only way for us non NetApp reviewers to know/15:24
msaravanYeah.. 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:25
gouthamrthank you15:26
carlossoh, and I see the change is still on stable/xena15:26
carlosscould you please propose it on master, so we can follow the backporting procedure?15:26
carthacait seems it is cherrypicked to master https://review.opendev.org/c/openstack/manila/+/89675915:27
carlossah, okay - sorry about that15:28
carlossonly saw the xena link15:28
gireeshthanks, carthaca for putting the link 15:29
carthacaNo, 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 think15:29
carlossyep - the commit message has the "cherry-picked from" marker15:30
gireeshso I need to abandon my patch and first merge to master and then cherry pickup to other branches   15:31
carlossI 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 do15:34
gireeshok, thanks will do that 15:35
carlossand as you have the backports in place, just reusiung the changes and modify the "cherry-picked from" to match the previous commits should do15:36
carlossnp15:36
gireeshthanks, will take care of it 15:37
carlossthanks gireesh 15:37
carlossokay, so I believe we can go to the next topic15:38
carloss#topic Hiding security service details15:38
carlossthis is related to an issue reported a while ago15:39
carloss#link https://bugs.launchpad.net/manila/+bug/181731615:39
carlossand gouthamr and I chatted about it earlier this week15:39
carlosswe wanted to bring this up again15:39
carlossthere was a fix proposed a while ago:15:41
carloss#link https://review.opendev.org/c/openstack/manila/+/766519 (Remove password field from security service)15:41
carlossit basically does an API bump so that starting from a version, it will stop displaying the security service password15:41
felipe_rodriguesit partially fixes the problem 15:41
carlossbut that would not be ideal in our understanding15:41
carlossfelipe_rodrigues: yep15:42
felipe_rodriguesfrom the security view, the problem isn't solved.. 15:42
carlosswith would not be ideal I mean:15:43
carlossyou'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 fix15:43
carloss> from the security view, the problem isn't solved.. 15:43
carlossyep - password would still be stored in plain text, which was the initial issue15:43
carlossgouthamr: would you like to add something?15:44
gouthamri agree this is a partial fix15:45
gouthamrbut, it does resolve a good part of the problem15:46
gouthamrso lets treat it as two separate issues.. 15:46
gouthamrsince Eduardo's stepped away, is there anyone that can pick up this fix and complete it?15:47
felipe_rodriguesI can take it. it seems an interesting issue15:48
carloss++ for separate issues15:48
gouthamrwe 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 secret15:48
felipe_rodriguesso, should we remove the bump version removing from all versions and solve the conflicts ? 15:48
carlossthanks felipe_rodrigues - yeah, we'd just need to remove the API bump and do the redacting bits15:49
gouthamrfelipe_rodrigues: not remove, i agree with carthaca/carloss that we would obfuscate it 15:49
carlossand the conflicts15:49
felipe_rodriguessorry, remove or not remove ? 15:50
gouthamrremove != redact :) 15:50
carlossdo not remove the field, just obfuscate it, but it shouldn't be something only for a specific API version15:51
carlossso we don't need to do the API version bump15:51
carlossand we'll be backporting it15:51
felipe_rodriguesnice. Remove API version bump and solve conflicts. got it!15:52
gouthamrwhat we mean is, the "password" field must be present in the API responses, it should have a value set to "******" or something15:52
carloss^15:52
carlossthanks!15:52
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 secret15:52
carloss++ on this15:52
carthacaI would vote for doing both: removing in a newer microversion has also benefits15:53
carthacaIf it is anyhow redacted, there is not much value in having it15:54
carthacaBut I'm also fine with letting the clients make that decision :)15:55
carlosscarthaca:  yeah... feasible too15:55
carlossmaking it redacted is good because it would be something backportable15:56
felipe_rodriguesI 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
carlossfelipe_rodrigues: nope, new API would not be backportable15:57
felipe_rodriguesgot it! thanks all15:57
carlossso 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 possible15:58
carlossso: let's go for redacting and making the removal a part of the C PTG alongside the other discussion part with the barbican approach15:59
carlossis it okay?15:59
felipe_rodriguesok16:00
carlossack16:00
carlosswe're at the top of the hour16:00
carlosslet's wrap up16:00
carlosssorry for not having time for bug triaging vhari - and thanks for putting the list together16:01
carlosswe can get some extra time to do it next week16:01
carlossthank you everyone for participating16:01
carlosssee you on #openstack-manila16:01
carloss#endmeeting16:01
opendevmeetMeeting ended Thu Sep 28 16:01:39 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:01
opendevmeetMinutes:        https://meetings.opendev.org/meetings/manila/2023/manila.2023-09-28-15.00.html16:01
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/manila/2023/manila.2023-09-28-15.00.txt16:01
opendevmeetLog:            https://meetings.opendev.org/meetings/manila/2023/manila.2023-09-28-15.00.log.html16:01

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!