Hey Brett, Thanks for testing on stein!
Would it be possible for you to test other/newer releases as well? I'm asking because fixes for older releases have to land on newer releases as well, if applicable, which needs verification too, but it seems testing for this bug is on short supply; so if you're still running hot with it, that would be great, if at all possible. And I'd imagine that releases on UCA that still have an Ubuntu release supported (e.g., ussuri -> focal) depend on the fix landing on the Ubuntu release as well. (Sorry, I know it's a lot to ask; don't shoot the messenger :) just trying to get this fix released, and I realize it's been sitting/waiting on testing for a long while, until you showed up! ;) Thanks! Mauricio P.S.: if that helps, it looks like Train isn't needed/supported anymore [1], unless the fix is required for upgrades. [1] https://ubuntu.com/about/release-cycle#ubuntu-openstack-release- cycle -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915678 Title: [SRU] iSCSI+Multipath: Volume attachment hungs if sessiong scanning fails Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive stein series: Fix Committed Status in Ubuntu Cloud Archive train series: Fix Committed Status in Ubuntu Cloud Archive ussuri series: Fix Committed Status in Ubuntu Cloud Archive victoria series: Fix Committed Status in os-brick: Fix Released Status in python-os-brick package in Ubuntu: Fix Released Status in python-os-brick source package in Bionic: Fix Committed Status in python-os-brick source package in Focal: Fix Committed Status in python-os-brick source package in Hirsute: Fix Released Status in python-os-brick source package in Impish: Fix Released Status in python-os-brick source package in Jammy: Fix Released Bug description: [Impact] * If some commands like "iscsiadm -m session" fail, the thread can abort immediately without updating any counters like failed_logins or stopped_threads properly, because there are no try-except block to catch exceptions. * The main thread keeps waiting until these counters are updated, and this results in stuck of volume attachment process. [Test Case] * Deploy Cinder with a backend that uses an iSCSI driver and configure Multipath * Attach a volume to an instance (first attachment for a period * See log line like: 2021-12-01 00:23:24.044 2679 WARNING os_brick.initiator.connectors.iscsi [...] iscsiadm stderr output when getting sessions: iscsiadm: No active sessions. * Volume attachment never completes * Passing test: Log line appears but volume attachment succeeds. [Where problems could occur] * Change primarily introduces error handling and doesn't change implementation details. As such we may see an error condition logged. --- Original Description --- Currently we execute login to iscsi portals and device discovery in multiple threads concurrently when multipath is enabled. However if some commands like "iscsiadm -m session" fail, the thread can abort immediately without updating any counters like failed_logins or stopped_threads properly, because there are no try-except block to catch exceptions. However the main thread keeps waiting until these counters are updated, and this results in stuck of volume attachment process. This issue was initially reported in downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1923975 , and maybe is caused by a bug in iscsiadm command. However we should handle the error more properly because current behavior requires operators to restart services like cinder-volume to resolve the stuck. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1915678/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : [email protected] Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
