[Bug 975604] New: YaST reuses the same iblock node for all iSCSI LIO targets
http://bugzilla.opensuse.org/show_bug.cgi?id=975604 Bug ID: 975604 Summary: YaST reuses the same iblock node for all iSCSI LIO targets Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: All OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers@suse.de Reporter: avsco@mail.ru QA Contact: jsrain@suse.com Found By: --- Blocker: --- When iSCSI targets are configured by `yast iscsi-lio-server`, only a single backstore node “iblock_0” is created and then shared between all blockdev items (logical volumes that back the targets). It is easy to spot because `targetcli ls /backstores/iblock` displays a warning for each item: “LEGACY: SHARED HBA”. Indeed, `/etc/target/tcm_setup.sh` and `/etc/target/lio_setup.sh` refer to “iblock_0” only, but they are simply generated by `/usr/lib/python2.7/site-packages/tcm_dump.py` as the current kernel configuration dump after YaST module finishes its job. I cannot pinpoint the exact location of problematic code, but at least it can be seen that `/usr/share/YaST2/modules/IscsiLioData.rb` has hardcoded string literals "iblock_0/" and "fileio_0/" at line 1090. Current workaround is to adjust `tcm_setup.sh` and `lio_setup.sh` by hand. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=975604
Per Jessen
http://bugzilla.opensuse.org/show_bug.cgi?id=975604
Imobach Gonzalez Sosa
http://bugzilla.opensuse.org/show_bug.cgi?id=975604
http://bugzilla.opensuse.org/show_bug.cgi?id=975604#c5
--- Comment #5 from Anton Samsonov
The lio-utils are not yet deprecated, although the targetcli interface is much easier to use for customers. Personally, I would like to see us to using targetcli instead of lio-utils in YaST, but we are currently evaluating replacing targetcli with targetcli-fb, which is the current "best" API, so no use changing YaST for now.
If you are looking forward to rewrite that module substantially, please, consider adding an option for choosing where to get the configuration from: 1. live state of kernel module ("running config"), - the current behavior; 2. configuration files on disk ("startup config"). The first option is great and intuitive, but it leads to disastrous results in case something went wrong and the configuration (or its part) was not successfully loaded: the user is presented with the current state only, which may be totally empty or missing some parts, and any attempt to apply the changes leads to those once failed parts to be lost forever. That is where the second options comes in, allowing the user to fix the problem and try again. However, the second option might be as dangerous as the first one if used blindly, because it will discard any temporary changes introduced manually or by scripts. Therefore it may be practical to display the difference between running config and startup config, if any, so the user could make the choice concisely. Moreover, if that is feasible, it would be nice to have an option to leave those differences intact, i. e. only apply the changes made to startup config without removing any extra settings. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com