14:00:47 <whoami-rajat> #startmeeting cinder
14:00:47 <opendevmeet> Meeting started Wed Apr 13 14:00:47 2022 UTC and is due to finish in 60 minutes.  The chair is whoami-rajat. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:47 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:47 <opendevmeet> The meeting name has been set to 'cinder'
14:00:55 <whoami-rajat> #topic roll call
14:00:57 <simondodsley> hi
14:00:58 <enriquetaso> hi
14:01:00 <jungleboyj> o/
14:01:12 <eharney> hi
14:01:14 <geguileo> hi! o/
14:02:07 <tosky> hi
14:02:10 <whoami-rajat> let's wait a couple of minutes for other people to join
14:02:18 <nahimsouza[m]> o/
14:02:26 <rosmaita> o/
14:03:28 <andrebeltrami[m]> o/
14:04:08 <whoami-rajat> ok, let's get started!
14:04:15 <whoami-rajat> Welcome everyone to the first cinder meeting of Zed development cycle
14:04:21 <whoami-rajat> #link https://etherpad.openstack.org/p/cinder-zed-meetings
14:04:27 <jungleboyj> \o/
14:04:40 <whoami-rajat> good to see everyone here shortly after the PTG :)
14:04:51 <felipe_rodrigues> o/
14:04:55 <whoami-rajat> we've a lot of announcements, so let's start
14:04:57 <whoami-rajat> #topic announcements
14:05:06 <whoami-rajat> first, Add IRC nick to courtesy reminder
14:05:17 <whoami-rajat> I've already added the IRC nicks from the yoga meetings etherpad but if there are new people that would like to add their names, they can add it to the courtesy reminder list on the etherpad on L#33
14:05:52 <whoami-rajat> I will remind about the meeting in the #openstack-cinder channel few minutes before the meeting starts here
14:06:01 <whoami-rajat> so make sure, you've joined both the channels
14:06:23 <whoami-rajat> moving on
14:06:26 <whoami-rajat> next announcements, stable/victoria moving to EM
14:06:45 <whoami-rajat> so there's a mail from Elod (release PTL) that stable/victoria will be moving to EM soon
14:06:48 <whoami-rajat> stable/victoria is going to EM on 27th April, 2022, so if there are any patches you would like to get released with the last victoria release, start backporting them now
14:07:03 <whoami-rajat> #link http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028013.html
14:07:21 <whoami-rajat> more about this we will discuss in the next announcement
14:07:47 <whoami-rajat> next, Release liaison
14:08:23 <whoami-rajat> so some of you might know, I've been managing the stable releases for the last 3-4 cycles but since now I've taken up the role of PTL, if anyone is interesting in doing stable releases, they can contact me or Brian and we can guide you through the process
14:08:50 <whoami-rajat> It has to be done every couple of months and if we have enough changes to release so not a big burden, and also you don't have to be a core reviewer to do it
14:09:11 <whoami-rajat> This glance doc is a good starting point for the role and responsibilities http://docs.qstack.com.cn/glance/latest/contributor/release-cpl.html
14:09:28 <whoami-rajat> we can think about adding this to our documentation as well
14:10:07 <whoami-rajat> next, Bug squad deputy
14:10:32 <whoami-rajat> enriquetaso has been handling the bug triaging and reporting and she has been doing an excellent work!
14:10:45 <whoami-rajat> If she would like to continue, it would be great but also if she wants to move on from the responsibility, we can discuss if anyone else would like to take that role
14:11:07 <whoami-rajat> for now, i will leave the decision to enriquetaso
14:11:23 <enriquetaso> i haven't though of that :P
14:11:23 <whoami-rajat> next, Release schedule
14:11:46 <whoami-rajat> sure, you can take your time!
14:12:00 <whoami-rajat> I've proposed the Zed release schedule, you can check the patch and html rendering on the etherpad
14:12:18 <whoami-rajat> #link https://review.opendev.org/c/openstack/releases/+/837494
14:12:30 <whoami-rajat> #link https://58140b717b0fd2108807-1424e0f18ed1d65bb7e7c00bb059b2d8.ssl.cf2.rackcdn.com/837494/1/check/openstack-tox-docs/6b018f1/docs/zed/schedule.html
14:12:42 <rosmaita> the only thing i noticed is that monday of the week of milestone 2 is a holiday in the USA
14:13:01 <rosmaita> or maybe not
14:13:15 <rosmaita> the lack of grid lines on the HTML schedule may be confusing me
14:13:18 <geguileo> ooooooh, ninja release then?
14:13:44 <whoami-rajat> oh ok, but i guess we've time till friday for any deadline so only monday holiday should be fine?
14:13:46 <rosmaita> i take it back, m-2 is week of 14 july
14:14:02 <jungleboyj> Right, it is the week after the 4th of July.
14:14:18 <whoami-rajat> also Brian has a suggestion to include mid cycle events in the schedule which i think would be useful for us, I will add them and see if the release team complaints
14:14:31 <whoami-rajat> great, no conflicts!
14:14:33 <jungleboyj> That is a great idea!
14:15:06 <geguileo> +1 to include all events, mid cycle, ptg, everything
14:15:31 <whoami-rajat> sounds good, i will add them
14:15:38 <whoami-rajat> so check out the release schedule and add comments regarding date conflicts and if we should move things around
14:16:00 <whoami-rajat> next announcement, April Festival of XS Reviews rescheduled
14:16:19 <whoami-rajat> so we've Good Friday holiday coming up this week for most of the people
14:16:27 <jungleboyj> ++
14:16:34 <whoami-rajat> but this is also the 3rd week of April i.e. Festival of XS reviews week
14:16:46 <whoami-rajat> so we're planning to move it to next or next to next friday
14:16:58 <whoami-rajat> (i was surprised to know we've 5 fridays in April)
14:17:22 <whoami-rajat> the best way to decide is to get the team votes in for it
14:17:30 <enriquetaso> 29th?
14:17:39 <enriquetaso> +1
14:17:51 <whoami-rajat> Lets vote for festival of XS reviews date
14:17:51 <whoami-rajat> options are:
14:17:51 <whoami-rajat> A 22nd April, 2022
14:17:51 <whoami-rajat> B 29th April, 2022
14:17:51 <whoami-rajat> C either one of the above
14:17:52 <whoami-rajat> D need more options
14:17:58 <whoami-rajat> #startvote time for the festival of XS reviews ? A, B, C, D
14:17:58 <opendevmeet> Begin voting on: time for the festival of XS reviews ? Valid vote options are A, B, C, D.
14:17:58 <opendevmeet> Vote using '#vote OPTION'. Only your last vote counts.
14:18:09 <enriquetaso> #vote C
14:18:25 <whoami-rajat> #vote C
14:18:28 <rosmaita> #vote C
14:18:35 <eharney> #vote C
14:19:09 <sfernand> #vote C
14:19:17 <jungleboyj> #vote C
14:20:09 <whoami-rajat> let's wait 2 more minutes for everyone to get their votes in
14:20:39 <lucasmoliveira059> #vote C
14:20:43 <geguileo> #vote C
14:20:48 <ecsantos[m]> #vote C
14:21:03 <rfluisa_> #vote C
14:21:40 <rosmaita> whoami-rajat: looks like you will get to choose!
14:21:45 <whoami-rajat> ok, i guess we already have majority
14:21:46 <whoami-rajat> #endvote
14:21:46 <opendevmeet> Voted on "time for the festival of XS reviews ?" Results are
14:21:46 <opendevmeet> C (10): geguileo, rosmaita, lucasmoliveira059, rfluisa_, whoami-rajat, sfernand, eharney, enriquetaso, ecsantos[m], jungleboyj
14:22:09 <whoami-rajat> rosmaita, :D yeah, voting wasn't much helpful here
14:22:24 <rosmaita> well, at least we know everyone can make it, whichever day you pick
14:22:50 <whoami-rajat> so i propose 29th April since we're still too close to PTG and people might not like attending another 2 hour meeting this early
14:23:01 <rosmaita> works for me
14:23:06 <jungleboyj> Makes sense.
14:23:06 <whoami-rajat> rosmaita, yep, that helped
14:23:21 <whoami-rajat> great, so 29th April it is
14:23:37 <whoami-rajat> that's all i had for announcements
14:23:41 <whoami-rajat> let's move on to topics
14:23:47 <whoami-rajat> #topic Remove legacy oslo.db enginefacade
14:23:50 <whoami-rajat> rosmaita, thats you
14:24:05 <rosmaita> thanks!
14:24:30 <rosmaita> ok, Stephen Finucane, a Hero of Cinder has proposed a bunch of patches
14:24:49 <rosmaita> to update our session usage in the sqlachemy/api.py
14:25:00 <enriquetaso> \o/
14:25:04 <rosmaita> it helps in 2 ways
14:25:29 <rosmaita> we are using an oslo.db legacy enginefacade that the oslo project has deprecated way back and wants to remove
14:25:41 <rosmaita> and we may be the only ones left using it
14:25:55 <rosmaita> and, this change also helps us get ready for SQLAlechemy 2.0
14:26:03 <rosmaita> which is coming very soon
14:26:28 <rosmaita> stephen broke this into a bunch of patches so each review isn't too big
14:26:57 <rosmaita> also, the line of code count in gerrit is not very accurate because a large part of this is un-indenting python code
14:27:13 <rosmaita> the quick explanation of what the change is, is here:
14:27:28 <rosmaita> #link https://docs.openstack.org/oslo.db/latest/reference/api/oslo_db.sqlalchemy.html#module-oslo_db.sqlalchemy.session
14:27:46 <rosmaita> i put together a dashboard, but i don't know how useful it will be
14:27:57 <rosmaita> i thought there were about 15 patches in the patch set
14:28:05 <rosmaita> but there are actually more like 34
14:28:14 <geguileo> 34!!!!
14:28:31 <rosmaita> yes, it is almost a geguileo-sized set of patches!
14:28:45 <geguileo> it's waaaaay beyond my longest patch series   lol
14:28:49 <rosmaita> actually, 34 is a bit excessive, even for geguileo
14:28:53 <rosmaita> :D
14:28:57 <geguileo> true
14:29:19 <rosmaita> yeah, so best thing is to start at the bottom, and get used to the pattern, and it gets easier as you go
14:29:21 <tosky> so wait for the devstack fix to land, merge everything, wait for explosions and fix everything in the next weeks?
14:29:41 <rosmaita> which devstack fix?
14:29:53 <whoami-rajat> I think this makes sense as we're already long overdue for the alembic work which is complete but we need to get this in to safeguard our migrations against SQLAlchemy update
14:30:20 <rosmaita> ok, my proposal is that we should not merge any DB changes before we get this set merged
14:30:32 <rosmaita> because i really don't want to review this multiple times
14:31:16 <tosky> rosmaita: devstack fix because devstack was broken by a git security fix (see openstack-discuss)
14:31:39 <rosmaita> tosky: that's what i get for not reading my email this morning
14:32:12 <whoami-rajat> I will take a look once I'm done with the PTG summary (it does take time to write)
14:32:33 <geguileo> fyi I have this patch that I need to update... https://review.opendev.org/c/openstack/cinder/+/815746
14:32:38 <rosmaita> here's the devstack bug link:
14:32:43 <rosmaita> #link https://bugs.launchpad.net/devstack/+bug/1968798
14:32:44 <geguileo> because we lost that with the alembic changes
14:33:01 <rosmaita> thanks tosky
14:34:27 <tosky> geguileo: should that be merged before or after merging the other patches?
14:34:40 <rosmaita> tosky: i was about to ask that
14:34:59 <geguileo> tosky: there are probably no conflicts between the 2 things
14:35:16 <geguileo> and if there are, we should merge the others first
14:35:33 <geguileo> because resolving a merge conflict in a 34 patch series would kill our CI
14:35:39 <tosky> geguileo: but could  it be used to check if the other patches introduce regressions?
14:35:46 <rosmaita> i guess my question is, what is a good way to get these all reviewed?
14:36:03 <geguileo> tosky: not really, the check is for new features and changes to the actual DB model, which the new code should not be touching
14:36:04 <rosmaita> i am committed to reviewing all of them, but i am insane
14:37:35 <whoami-rajat> i see geguileo has a series of patches where some may conflict with stephen's chain https://review.opendev.org/q/topic:die-quota-die-base
14:37:55 <geguileo> whoami-rajat: those can wait
14:38:08 <geguileo> Since I have to make additional changes
14:38:17 <geguileo> I'll just rebase them on top of his 34 patches
14:38:36 <whoami-rajat> ok, so let's review stephen's patches as priority (at least as much as we can get in from them)
14:38:46 <whoami-rajat> and other DB changes can be reviewed/merged later
14:39:19 <rosmaita> let's revisit this next week, if there's not a lot of review action, i will set up a spreadsheet or something and we can "volunteer" specific people to review subsets of patches
14:39:43 <whoami-rajat> that sounds like a good idea
14:39:56 <rosmaita> that's all from me, unless people think 1 week is too long to wait
14:40:23 <whoami-rajat> i guess they can review changes anyway!
14:40:30 <whoami-rajat> so let's move on to next topic
14:40:33 <rosmaita> yep
14:40:34 <whoami-rajat> #topic Disable c-bak by default in CI jobs
14:40:43 <whoami-rajat> rosmaita, that's you again
14:40:56 <rosmaita> #link https://review.opendev.org/c/openstack/devstack/+/837630
14:41:03 <tosky> (sorry) I thought it was disabled long ago, we explicitly enable it in a few cinder jobs
14:41:27 <rosmaita> apparently it's enabled by default in devstack
14:42:06 <rosmaita> i guess as long as we have test coverage, it doesnt' need to be enabled by default?
14:42:44 <whoami-rajat> there's a comment by Dan saying it's causing OOM failures frequently in ceph multistore job (i assume that's in glance)
14:42:54 <rosmaita> has anyone had time to look at David Caro's patch: https://review.opendev.org/c/openstack/cinder/+/834527
14:43:05 <tosky> well, they can also disable it in the specific jobs which shows resource issues
14:43:37 <eharney> rosmaita: i looked over it a bit, it makes sense conceptually
14:45:44 <rosmaita> i don't have any more to say, just wanted people to be aware
14:46:01 <rosmaita> clarkb put a -W on the devstack patch
14:46:03 <whoami-rajat> so should c-bak be disabled/enabled by default? what is our take on this
14:46:28 <eharney> by default in CI jobs, you mean
14:46:43 <rosmaita> right
14:46:50 <whoami-rajat> yes
14:46:55 <tosky> whoami-rajat: for the record, it was disabled some time ago
14:47:40 <tosky> by default; I don't remember where and when it was reenabled, maybe when the signle integrated job was split into more integrated job (integrated-storage in our case)
14:48:12 <whoami-rajat> ok, i need to followup on the history of it then
14:48:15 <rosmaita> well, i'll leave a comment that we are looking at a possible fix
14:48:21 <eharney> i don't think it matters too much whether it's on in jobs by default, but it does mean we have to go make sure this doesn't reduce test coverage for us, or if we need to change our jobs
14:48:45 <whoami-rajat> eharney +1
14:48:49 <rosmaita> i think clark -W'd because the logs showed that somethign was using c-back
14:49:06 <rosmaita> ok, thanks, we can see what happens
14:49:22 <rosmaita> in the meantime, would be good to look at https://review.opendev.org/c/openstack/cinder/+/834527
14:49:37 <eharney> i'm not sure if the 834527 patch would even help if it's in Ceph jobs, would need to see what those are running exactly
14:50:02 <eharney> in general, if people are having OOM issues, we need bug reports
14:50:05 <rosmaita> that's a good point
14:51:37 <whoami-rajat> rosmaita, so i guess we've enough points to hold the patch as of now until we accurately know if it's a good idea or not
14:51:48 <rosmaita> sounds good to me
14:51:49 <whoami-rajat> as eharney pointed out, it shouldn't reduce our test coverage
14:51:57 <whoami-rajat> great
14:52:06 <whoami-rajat> let's move on to next topic then
14:52:13 <whoami-rajat> #topic vote on NetApp proposal to backport ONTAP REST API support
14:52:47 <whoami-rajat> so people who have attended the PTG on Thursday might be familiar with NetApp's proposal about changing their ZAPI calls to REST API calls
14:53:16 <whoami-rajat> their ask is to allow the change to be backported to the active stable branches
14:53:23 <geguileo> whoami-rajat: I don't feel good voting for this without e0ne being present (major opposition to doing it)
14:53:41 <sfernand> geguileo: ++
14:53:44 <jungleboyj> ++
14:53:50 <whoami-rajat> oh, i didn't notice, that's a good point by geguileo
14:53:52 <sfernand> I think we can recap today
14:54:00 <sfernand> And do the votes next week
14:54:08 <rosmaita> i'm on board with e0ne, i think
14:54:19 <whoami-rajat> sfernand, that also sounds good, would you like to provide a summary of it?
14:54:37 <sfernand> Yes give me a minute to type
14:54:46 <jungleboyj> Makes sense.
14:54:55 <whoami-rajat> sure
14:56:33 <sfernand> Ok, so during the ptg we discussed the possibility of backporting our old xml based calls to rest, the reason for this is because zapis will be deprecated on 2023, which means customers wouldn’t be able to upgrade ontap arrays in any older version then zed (if me merge in zed)
14:57:02 <sfernand> So the debate was around if that should be considered a new feature
14:57:19 <sfernand> Or a Bug we are trying to antecipate
14:57:58 <whoami-rajat> #link https://etherpad.opendev.org/p/zed-ptg-cinder#L431
14:57:59 <sfernand> Since it is going to directly affect rhosp deployments which currently relies on train..
14:58:20 <sfernand> During the discussion we agreed that there is no chance for train
14:58:47 <sfernand> But that could be considered for the versions we still provide new releases
14:59:07 <sfernand> Like yoga, xena, wallaby
14:59:59 <sfernand> Our idea is to backport to the active stable branches and make it possible for rhosp 17
15:00:08 <simondodsley> The next RHOSP release will be based on Wallaby so that would be the oldest version you would have to backport to (if allowed...)
15:00:24 <whoami-rajat> that's a good summary and people can also follow the PTG discussion and recording to get more familiar with it, netapp had a nice presentation as well
15:00:40 <whoami-rajat> we're out of time
15:00:44 <sfernand> Yep, and that would be enough since we could at least advice our customers to upgrade
15:00:47 <simondodsley> Although I believe RH have already frozen 17.0
15:01:13 <whoami-rajat> the last topic is by ganso requesting reviews for his backports, so check them out on the etherpad
15:01:19 <whoami-rajat> we can continue discussion next week
15:01:36 <ganso> yes please review
15:01:45 <whoami-rajat> thanks all!
15:01:47 <whoami-rajat> #endmeeting