[Bug 986172] New: [targetcli] ConfigError: Invalid storage identifier 'pscsi': expected type 'rbd', 'iblock', 'fileio', 'rd_mcp'
http://bugzilla.suse.com/show_bug.cgi?id=986172 Bug ID: 986172 Summary: [targetcli] ConfigError: Invalid storage identifier 'pscsi': expected type 'rbd', 'iblock', 'fileio', 'rd_mcp' Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: zzhou@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Problem Symptom ================= Malfunction of "saveconfig" or "exit" from targetcli, after configuring a "backstores/pscsi/dev_sda" via the command: 421-lio:/etc/target # targetcli /backstores/pscsi create dev_sda /dev/sda Where /dev/sda is an iscsi/iblock device, and been used to simulate a SCSI disk. Indeed, pscsi functionality works well so far. Error Log ================= 421-lio:/etc/target # targetcli targetcli 2.1-suse (rtslib 2.2-sle12) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. /> exit Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/configshell/shell.py", line 990, in run_interactive self._cli_loop() File "/usr/lib/python2.7/site-packages/configshell/shell.py", line 820, in _cli_loop self.run_cmdline(cmdline) File "/usr/lib/python2.7/site-packages/configshell/shell.py", line 934, in run_cmdline self._execute_command(path, command, pparams, kparams) File "/usr/lib/python2.7/site-packages/configshell/shell.py", line 909, in _execute_command result = target.execute_command(command, pparams, kparams) File "/usr/lib/python2.7/site-packages/targetcli/ui_node.py", line 103, in execute_command pparams, kparams) File "/usr/lib/python2.7/site-packages/configshell/node.py", line 1416, in execute_command result = method(*pparams, **kparams) File "/usr/lib/python2.7/site-packages/targetcli/ui_node.py", line 119, in ui_command_exit config.load_live() File "/usr/lib/python2.7/site-packages/rtslib/config.py", line 553, in load_live source=source, allow_new_attrs=True) File "/usr/lib/python2.7/site-packages/rtslib/config.py", line 190, in _load_parse_tree token = self.validate_obj(token, cur) File "/usr/lib/python2.7/site-packages/rtslib/config.py", line 381, in validate_obj ", ".join(expected_val_types))) ConfigError: Invalid storage identifier 'pscsi': expected type 'rbd', 'iblock', 'fileio', 'rd_mcp' /> Expected Behavior ================= I assume this is a valid configuration, and the error should be removed. Might be worth to book a real SCSI disk server to validate the behavior. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 Roger Zhou <zzhou@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lduncan@suse.com Assignee|bnc-team-screening@forge.pr |lszhu@suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c1 Lingshan Zhu <lszhu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #1 from Lingshan Zhu <lszhu@suse.com> --- working on it now -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c2 Lingshan Zhu <lszhu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #2 from Lingshan Zhu <lszhu@suse.com> --- it is already fixed in targetcli3.0 pre4 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c3 Roger Zhou <zzhou@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- Flags| |needinfo?(lduncan@suse.com) --- Comment #3 from Roger Zhou <zzhou@suse.com> --- It is great to know this bug was fixed in Factory. However, I would incline to reopen this since openSUSE Leap is not fixed indeed. Further thinking, it might be worth a discussion with Lee Duncan for our position in Leap. The question can be: - Whether we incline to be more aggressive to suggest Leap 42.2 Release Manager to use targetcli 3.0 in Factory, or be more safe and conservative to stay with targetcli 2.1 the same as SLE? - Also, other than this, in the end of Jun, upstream had moved 3.0 into github/open-iscsi/targetcli-fb. It makes sense to repackage this instead of Datera repo. @Lee, What do you think? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c4 Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peng.zhounix@gmail.com Flags|needinfo?(lduncan@suse.com) |needinfo?(peng.zhounix@gmai | |l.com) --- Comment #4 from Lee Duncan <lduncan@suse.com> --- (In reply to Roger Zhou from comment #3)
It is great to know this bug was fixed in Factory.
However, I would incline to reopen this since openSUSE Leap is not fixed indeed. Further thinking, it might be worth a discussion with Lee Duncan for our position in Leap. The question can be:
- Whether we incline to be more aggressive to suggest Leap 42.2 Release Manager to use targetcli 3.0 in Factory, or be more safe and conservative to stay with targetcli 2.1 the same as SLE?
- Also, other than this, in the end of Jun, upstream had moved 3.0 into github/open-iscsi/targetcli-fb. It makes sense to repackage this instead of Datera repo.
@Lee, What do you think?
Hi Roger: I am not aware of the goals of Leap 42.2, i.e. whether they want to be conservative, as SLE is, or take chances on new packages as Factory does. I believe the targetcli-3.0 stuff is a much better version than the 2.1 version, and very stable. The targetcli-fb group of packages is fairly new so I'd like to see it get some use in Factory and SLE 12 SP2 before we replace targetcli (and friends). So I suggest adding targetcli-fb and friends to 42.2 as an option, if there is still time. But I think the targetcli there should be updated to 3.0-pre4, as per factory. Also, what is the procedure for getting things in Leap? I was under the impression we just put updates in Factory and they magically migrated to Leap at some time in the future. I'm guessing now that is incorrect. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c5 --- Comment #5 from Roger Zhou <zzhou@suse.com> --- (In reply to Lee Duncan from comment #4)
(In reply to Roger Zhou from comment #3)
It is great to know this bug was fixed in Factory.
However, I would incline to reopen this since openSUSE Leap is not fixed indeed. Further thinking, it might be worth a discussion with Lee Duncan for our position in Leap. The question can be:
- Whether we incline to be more aggressive to suggest Leap 42.2 Release Manager to use targetcli 3.0 in Factory, or be more safe and conservative to stay with targetcli 2.1 the same as SLE?
- Also, other than this, in the end of Jun, upstream had moved 3.0 into github/open-iscsi/targetcli-fb. It makes sense to repackage this instead of Datera repo.
@Lee, What do you think?
Hi Roger:
I am not aware of the goals of Leap 42.2, i.e. whether they want to be conservative, as SLE is, or take chances on new packages as Factory does.
I believe the targetcli-3.0 stuff is a much better version than the 2.1 version, and very stable. The targetcli-fb group of packages is fairly new so I'd like to see it get some use in Factory and SLE 12 SP2 before we replace targetcli (and friends). So I suggest adding targetcli-fb and friends to 42.2 as an option, if there is still time. But I think the targetcli there should be updated to 3.0-pre4, as per factory.
Hi Leeman, Great on your feedback for the stable status of targetcli-3.0 stuff. At this moment, I'm not sure how the impact to the related yast modules. How the situation in Thumbleweed? Lingshan, maybe you want to have a look? As for Leap 42.2, Alpha 3 just out, Beta 2 will be Sept 20th, two months ahead. We don't have time for SLE12 SP2 for sure.
Also, what is the procedure for getting things in Leap?
To let Leap Release Manager(ludwig.nussel@suse.de) knows your position on the related packages as the role of maintainer in openSUSE. And also the public engagement in opensuse-packaging@opensuse.org is good too.
I was under the impression we just put updates in Factory and they magically migrated to Leap at some time in the future. I'm guessing now that is incorrect.
Aha, there are some complexity for Leap ;) Among thousands of Leap packages, some are core packages, some are not. The core package has to be from SLE code stream. While, there are thousands of user space packages can be from openSUSE:Factory code stream directly. In corner case, Leap could maintain the code stream on its own. Leap Release team maintains such list. More specifically in this case for targetcli-3.0 related packages, we could communicate with Leap 42.2 release team to use Factory code stream. Before that, targetcli will just follow SLE12 SP2 code stream. Not a magic now, huh ;) Thanks, Roger -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c6 --- Comment #6 from Lingshan Zhu <lszhu@suse.com> --- (In reply to Roger Zhou from comment #5)
(In reply to Lee Duncan from comment #4)
(In reply to Roger Zhou from comment #3)
It is great to know this bug was fixed in Factory.
However, I would incline to reopen this since openSUSE Leap is not fixed indeed. Further thinking, it might be worth a discussion with Lee Duncan for our position in Leap. The question can be:
- Whether we incline to be more aggressive to suggest Leap 42.2 Release Manager to use targetcli 3.0 in Factory, or be more safe and conservative to stay with targetcli 2.1 the same as SLE?
- Also, other than this, in the end of Jun, upstream had moved 3.0 into github/open-iscsi/targetcli-fb. It makes sense to repackage this instead of Datera repo.
@Lee, What do you think?
Hi Roger:
I am not aware of the goals of Leap 42.2, i.e. whether they want to be conservative, as SLE is, or take chances on new packages as Factory does.
I believe the targetcli-3.0 stuff is a much better version than the 2.1 version, and very stable. The targetcli-fb group of packages is fairly new so I'd like to see it get some use in Factory and SLE 12 SP2 before we replace targetcli (and friends). So I suggest adding targetcli-fb and friends to 42.2 as an option, if there is still time. But I think the targetcli there should be updated to 3.0-pre4, as per factory.
Hi Leeman,
Great on your feedback for the stable status of targetcli-3.0 stuff.
At this moment, I'm not sure how the impact to the related yast modules. How the situation in Thumbleweed? Lingshan, maybe you want to have a look?
As for Leap 42.2, Alpha 3 just out, Beta 2 will be Sept 20th, two months ahead.
We don't have time for SLE12 SP2 for sure.
Also, what is the procedure for getting things in Leap?
To let Leap Release Manager(ludwig.nussel@suse.de) knows your position on the related packages as the role of maintainer in openSUSE. And also the public engagement in opensuse-packaging@opensuse.org is good too.
I was under the impression we just put updates in Factory and they magically migrated to Leap at some time in the future. I'm guessing now that is incorrect.
Aha, there are some complexity for Leap ;) Among thousands of Leap packages, some are core packages, some are not. The core package has to be from SLE code stream. While, there are thousands of user space packages can be from openSUSE:Factory code stream directly. In corner case, Leap could maintain the code stream on its own. Leap Release team maintains such list.
More specifically in this case for targetcli-3.0 related packages, we could communicate with Leap 42.2 release team to use Factory code stream. Before that, targetcli will just follow SLE12 SP2 code stream. Not a magic now, huh ;)
Thanks, Roger
Hi Roger, I think there are no impact to yast target modules, we want to update targetcli packages, but yast module is still lio-utils backend now. Thanks, Zhu Lingshan -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=986172 http://bugzilla.suse.com/show_bug.cgi?id=986172#c7 Lingshan Zhu <lszhu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |UPSTREAM --- Comment #7 from Lingshan Zhu <lszhu@suse.com> --- we have targetcli fb and related packages now in SLE12 SP2 and Leap 42.2, and targetcli fb does not have such problems, see: /backstores/pscsi> create name=iscsi_sdd dev=/dev/sdd Note: block backstore recommended for SCSI block devices Created pscsi storage object iscsi_sdd using /dev/sdd /backstores/pscsi> cd / /> exit Global pref auto_save_on_exit=true Last 10 configs saved in /etc/target/backup. Configuration saved to /etc/target/saveconfig.json -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com