15:02:21 #startmeeting cinder_bs 15:02:21 Meeting started Wed Apr 13 15:02:21 2022 UTC and is due to finish in 60 minutes. The chair is enriquetaso. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:21 The meeting name has been set to 'cinder_bs' 15:02:30 Welcome to the Cinder Bug Meeting 15:02:32 Hi 15:02:37 hi 15:02:38 Four new bugs reported in this period of two weeks. Not bad. 15:02:45 o/ 15:02:49 You can check the full report here: 15:02:49 #link http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028171.html 15:02:58 #topic Encryptor connect_volume not changing the symlink 15:03:04 #link https://bugs.launchpad.net/os-brick/+bug/1967790 15:03:23 This is a high importance bug that we discussed last week. 15:03:23 Feel free to review geguileo patch:: 15:03:23 #link https://review.opendev.org/c/openstack/os-brick/+/836391 15:04:21 i'll be reviewing it 15:04:51 thanks eharney 15:05:06 moving on.. 15:05:15 #topic cinder-manage db sync fails due to row size too large 15:05:20 Francesco Pantano proposed openstack/devstack-plugin-ceph master: Deploy with cephadm https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/826484 15:05:21 #link https://bugs.launchpad.net/cinder/+bug/1968746 15:05:29 i've been thinking about this one 15:05:35 Running the cinder-manage db sync to upgrade to Xena from Wallaby resulted in error. The reporter has cluster since Kilo and  fix the problem manually changing row_format from 'Compact' to 'Dynamic' by running: ALTER TABLE volumes ROW_FORMAT=DYNAMIC; 15:05:39 probably a "won't fix" 15:05:43 Not sure if this is a particular case or if I should close the bug. 15:05:46 thanks rosmaita 15:06:09 i think maybe the thing to do is put a statement somewhere in our docs about what versions we test with/support 15:06:21 basically the db versions packaged with the supported operating systems 15:06:30 because new versions of mysql don't hit this? 15:06:36 right 15:06:47 makes sense to me 15:07:17 #action: add statement of the mysql version supported 15:07:26 but, it's good to have the bug because it does bring up some issues that maybe we need to pay attention to 15:07:37 enriquetaso: assign the bug to me and i will follow up 15:08:04 done 15:08:07 thanks brian! 15:08:11 thanks! 15:08:15 #topic Concurrent migration of vms with the same multiattach volume fails 15:08:21 #link https://bugs.launchpad.net/cinder/+bug/1968645 15:08:30 Attaching one volume to multiple vms and trying to migrate all the vms at the same time fails. The report mentioned that the reason for the failure of vm migration is that the multiattach volume status changes to attaching after the vm migration process. At this time, when another vm migrates, it is judged that the volume status is attaching, which leads to the execution of attachment_create fail. 15:08:30 No fix proposed to master yet. 15:09:07 I'm not sure if we have a tempest test for a case like this one 15:09:57 i suspect not, that's quite a scenario 15:10:16 though kind of a common scenario, i guess, when you look at it 15:10:28 i suspect that a fix stopping this from the Nova side might be a better short term goal than a Cinder fix, but not sure 15:11:07 stopping the migration ? 15:11:16 eharney: +1 15:11:19 this happens because our state management with multiattach volumes is stretched in odd ways when using multiattach 15:11:26 enriquetaso: not allowing 2 concurrent migrations that share a volume 15:11:27 i'm not sure we can do much about it without large API changes 15:11:53 enriquetaso: I confirm we don't have a tempest test for that 15:12:05 right, a more tactical fix in Nova like what geguileo suggests seems much easier 15:12:15 we may be able to make it work with current API, but it would still be a Nova fix 15:12:40 cool, maybe I can add a comment with all this discussion on the bug report and see what nova team thinks 15:13:00 +1 15:13:11 this should probably also be documented a known issue somewhere since it would be a problem for evacuations etc 15:13:16 enriquetaso: I would literally either kick it to the nova component or add the nova component to the bug 15:13:40 geguileo, the nova component is already added 15:13:56 because I think it may just be an issue that Nova needs to wait a second and then it would work 15:14:00 enriquetaso: ok 15:14:18 #action: document this as known issue 15:14:27 it may just be that there's a race condition between the 2... 15:14:43 or maybe not... 15:14:58 I don't remember clearly the state transitions of the volume in that case :-( 15:15:45 excellent 15:16:11 I'll add a comment on the bug report tho 15:16:16 Last one 15:16:21 #topic reimage_volume failure message action does not exist 15:16:28 #link https://bugs.launchpad.net/cinder/+bug/1968170 15:16:36 so, one note on this one 15:16:51 sure 15:17:05 it's just broken code, and i found this trivially with pylint 15:17:16 we are missing out on finding such things because our pylint gate job is not very useful 15:17:17 pylint++ 15:17:30 i might change it soon to make it do what it actually should do 15:17:51 #action: update pylint job 15:18:08 Marked as low-hanging-fruit in case interns are looking for small bugs. 15:18:10 the behavior of it only looking at files that your patch touches is just confusing to people, and it means that we merge broken things and then never see the messages 15:18:32 that's bad :( 15:18:40 and then someone touches a file two years later and sees a bunch of failures unrelated to what they were actually doing 15:18:44 it's not great 15:19:44 We have a plan to fix it then, thanks Eric 15:19:53 #topic Open Discussion 15:20:08 Feel free to proposed any bug here 15:25:24 OK, nothing. See you next week! 15:25:35 #endmeeting