Bug#764005: targetcli: Upgrade issues from 2.1-1
Thanks Chris, I'll take a look at it in the coming days! Best, -- Jerome On 12/17/2014 11:03 PM, Chris Boot wrote: On 17 Dec 2014, at 21:11, Chris Boot bo...@bootc.net wrote: On 17 Dec 2014, at 13:56, Ritesh Raj Sarraf r...@debian.org wrote: On 10/07/2014 03:54 PM, Jerome Martin wrote: On 10/07/2014 12:21 PM, Ritesh Raj Sarraf wrote: On Tuesday 07 October 2014 03:49 PM, Ritesh Raj Sarraf wrote: Okay!! Thanks to both of you. I will prepare something next week. My only request is if (other) users can test it in time. By the way, Jerome, do you still plan on a newer release of the LIO stack ? Or is this, the one I pushed to Debian, good from your point of view ? Yes, an update is on its way. This should not impact the iSCSI use-case too much, the aim will be updates to the HW fabrics support mostly, along with a few minor bug-fixes here and there. Jerome: Based on what we last talked, I went ahead and created tarballs accordingly. I now have a beter LIO stack with proper versioning. I have pushed it to experimental as Debian Jesssie is in freeze. rrs@learner:/var/tmp/Debian-Build/Result$ sudo targetcli [sudo] password for rrs: targetcli 3.0.pre4.1~ga55d018 (rtslib 3.0.pre4.1~g1b33ceb) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. / ls o- / . [...] o- backstores .. [...] | o- fileio ... [0 Storage Object] | o- iblock ... [0 Storage Object] | o- pscsi [0 Storage Object] | o- rd_mcp ... [0 Storage Object] o- ib_srpt ... [0 Targets] o- iscsi . [0 Targets] o- loopback .. [0 Targets] o- qla2xxx ... [0 Targets] o- tcm_fc [0 Targets] o- vhost . [0 Targets] / exit Comparing startup and running configs... Startup config is up-to-date. 19:23 ♒♒♒ ☺ rrs@learner:/var/tmp/Debian-Build/Result$ This looks much better. Chris: If you have some time, you may want to play with this version, from experimental ?? Hi Ritesh, This version is much better, but still doesn’t work with my qla2xxx targets unfortunately. When saving the configuration, I get: ConfigError: Unknown value type 'qla2xxx_wwn' when validating 21:02:00:e0:8b:d1:67:2c Hi Ritesh, Jerome, I wrote a patch that appears to fix this for me, through admittedly I haven’t tested it very extensively yet: https://github.com/Datera/rtslib/pull/5 https://github.com/bootc/rtslib/commit/727c345bd18137c424e4fba62bfab7bcfabfc024 That allows the configuration to be saved, at least. I haven’t yet tested manipulating targets (creating/changing/removing them) or rebooting my server to see whether they get restored correctly, but targetcli appears to make the right noises so far. HTH, Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764340: targetcli: On new install exit or configure etc. fail due to missing /var/target/policy
On 10/16/2014 07:49 PM, Ritesh Raj Sarraf wrote: Thank you for this bug report. I'm just replying to say that I'll look into these issues very soon. THanks. Excellent. Jerome: In case if you have time, there recently have been a couple of bug reports filed against targetcli, for the newer version. I haven't looked at them at all, but if you have time, you may want to look at them too. Some of them may be related to upstream code. Thanks for the heads up, I'll be looking into those shortly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764005: targetcli: Upgrade issues from 2.1-1
Hi Chris et al.,
On 10/05/2014 05:45 PM, Chris Boot wrote:
From my perspective, it would be nice to keep the old tcm_node and lio_node
tools around. I know that they are deprecated but there are a lot of tools
around that rely on them.
Do you have any particular examples of such tools?
Are these actual packaged tools or in the wild user scripts that you
know/assume exist? The feedback I have had from multiple users pointed
out a wide usage of rtslib API used from python, but not really the
ancient *_node tools.
However, I guess it is a good thing to keep it around for now if it
provides better support for existing configurations.
The migration from the lio-utils to targetcli startup scripts could possibly be
done by removing the init script from lio-utils and replacing it with the one
in targetcli. You would need a NEWS and/or a high priority debconf notification
to ensure people are aware of the change, and possibly leave saving the current
configuration to the user even.
I am just afraid that leaving this entirely up to the user would not be
very reliable. In any case, note that I have documented the process in
the README.md file found in targetcli 3.x branch, see the github page
for a nice endering of this: https://github.com/Datera/targetcli
This also documents what the initscript does when it detects a migration
scenario. Ritesh, do you plan on keeping the initscript as is or are
there special Debian-specific arrangements to be made?
In any case, be aware that the upstream initscript does have provision
for upgrade, the only blocking point being to ensure that the legacy
config will stay up when installing the package.
Certainly stopping the target when removing lio-utils seems very wrong indeed,
especially as there isn’t a daemon involved. I’ve always thought the lio-utils
{pre,post}{inst,rm} scripts shouldn’t attempt to run the init scripts at all.
Agreed.
So here is what I think:
1. A new version of lio-utils with:
a) the init script removed
b) Recommends: targetcli = [new version]
c) a NEWS.Debian entry and/or debconf prompt about transitioning to
targetcli
2. A new version of targetcli/rtslib with:
a) 'dh_installinit --no-start’ to not break running targets
b) Breaks: lio-utils [new version]
c) Replaces: lio-utils [new version]
d) a NEWS.Debian entry and/or debconf prompt about transitioning to
targetcli
e) the other bugs fixed that make them unusable...
That way, in theory, one gets the new de-fanged version of lio-utils during the
upgrade which keeps the current targets running. The new targetcli comes along,
and can either write out its own config based on the running targets or the
user can be prompted to do so.
I like that. It means on a scratch install, you can have a system
without lio-utils, and on a system with legacy lio-utils, the upgrade
should work and you can uninstall lio-utils afterwards if needed.
Ritesh, if you implement that in control, please send me a patch so that
I can push it upstream. Ultimately, I would like to have the same
debian/* files as in the maintainer package.
Kind Regards,
--
Jerome
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764005: targetcli: Upgrade issues from 2.1-1
On 10/07/2014 12:21 PM, Ritesh Raj Sarraf wrote: On Tuesday 07 October 2014 03:49 PM, Ritesh Raj Sarraf wrote: Okay!! Thanks to both of you. I will prepare something next week. My only request is if (other) users can test it in time. By the way, Jerome, do you still plan on a newer release of the LIO stack ? Or is this, the one I pushed to Debian, good from your point of view ? Yes, an update is on its way. This should not impact the iSCSI use-case too much, the aim will be updates to the HW fabrics support mostly, along with a few minor bug-fixes here and there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764005: targetcli: Upgrade issues from 2.1-1
On 10/05/2014 09:37 AM, Ritesh Raj Sarraf wrote: Thanks for the bug report. Jerome: How can we ensure to have the old 2.x settings / targets in 3.x ? Manually, this is easy. But to automate package upgrade is bit of a brain-twister. I haven't found yet a good way to do it. Basically, the config format is completely different, so we need to start the new initscript and save the config (in the new version) while the target is running. But removing the previous package actually stops it... And there is no way to reload the old config after the upgrade because that depends on lio-utils, which we want to get rid of... We would need a way to tell the upgrade process NOT to stop the 2.x target service when removing the old package, but I did not find a way to do that. Any idea ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764005: targetcli: Upgrade issues from 2.1-1
One more thought... I think the Debian way would be to have a transition package containing lio-utils, and modify the initscript to account for it. The initscript would check on first start if we are in an upgrade scenario (no new config, an old lio-utils config present), invoke the transition lio-utils code to start the targets and then dump the config in the new format. But that would involve keeping around the lio-utils code just for that one-shot usage... And I hate the idea of having a dependency on it just for that. WDYT? On 10/05/2014 10:30 AM, Jerome Martin wrote: On 10/05/2014 09:37 AM, Ritesh Raj Sarraf wrote: Thanks for the bug report. Jerome: How can we ensure to have the old 2.x settings / targets in 3.x ? Manually, this is easy. But to automate package upgrade is bit of a brain-twister. I haven't found yet a good way to do it. Basically, the config format is completely different, so we need to start the new initscript and save the config (in the new version) while the target is running. But removing the previous package actually stops it... And there is no way to reload the old config after the upgrade because that depends on lio-utils, which we want to get rid of... We would need a way to tell the upgrade process NOT to stop the 2.x target service when removing the old package, but I did not find a way to do that. Any idea ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
On 09/21/2014 12:14 PM, Michael Prokop wrote: * Jerome Martin [Sat Sep 20, 2014 at 07:57:47PM +0200]: I could use (read desperately require :-) ) tests and reports myself, so please guys, I will be working on the upstream code next week, now is a good time to fill my inbox with reports :-) Kernel version is always one critical piece of information for testing, so please remember to include it! Sure, I'll test my use-cases ASAP and will report back for sure. Thanks for your work, highly appreciated. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
Excellent, thanks Ritesh! On 09/20/2014 11:28 AM, Ritesh Raj Sarraf wrote: On Friday 19 September 2014 03:40 PM, Ritesh Raj Sarraf wrote: On Thursday 18 September 2014 05:56 PM, Jerome Martin wrote: Well, obviously I missed that deadline, and am planning on being on it full-time next week, with the goal to release for distros at the end of the week. This i going to be solely bugfixes and more hardware targets validation tests. The delay is due to both personal issues (it's amazing how a sick kid can crush your productivity to ashes, even for a minor throat infection...) and some delays in getting access to the proper test hardware for some of the validation tests. Can you push your changes to the repo at least? I will prep something out of that. The current lio-utils build has broken and I don't want to spend time there. I'd instead bring in the new targetcli which would invalidate the old lio-utils. I just pushed configshel 1.5 into experimental. Next in line is rtslib and targetcli (both from git tip). Once all are in experimental, and we have some test results, I'll push it to unstable. -- Ritesh Raj Sarraf RESEARCHUT -http://www.researchut.com Necessity is the mother of invention. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
Hi Ritesh, On 09/20/2014 11:39 AM, Ritesh Raj Sarraf wrote: By the way, are there plans on fixing this ? E: python-rtslib: non-standard-dir-in-var var/target/ W: python-rtslib: file-in-unusual-dir var/target/fabric/ib_srpt.spec W: python-rtslib: file-in-unusual-dir var/target/fabric/iscsi.spec W: python-rtslib: file-in-unusual-dir var/target/fabric/loopback.spec W: python-rtslib: file-in-unusual-dir var/target/fabric/qla2xxx.spec W: python-rtslib: file-in-unusual-dir var/target/fabric/tcm_fc.spec W: python-rtslib: file-in-unusual-dir var/target/fabric/usb_gadget.spec I have added a lintian override for now. From what I recall, we didn't want to change it because this same path was consumed in the kernel component of LIO. Yes, the problem is that the kernel side uses this path unfortunately. We could relocate policy and fabric to /var/lib/target, but that would mean keeping both /lib/target and /var/target around for now, as the kernel will use that for storing alua metadata in /var/target/alua. However, what about relocating now, and keeping around a symlink to /var/target, created in post-install? This way, as soon as Nic can push the relocation to /var/lib/alua, we are ready and just have to remove the symlink from packaging. I am cc'ing the ML on this one. Best, -- Jerome -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
On 09/20/2014 01:24 PM, Ritesh Raj Sarraf wrote: On Saturday 20 September 2014 02:58 PM, Ritesh Raj Sarraf wrote: I just pushed configshel 1.5 into experimental. Next in line is rtslib and targetcli (both from git tip). Once all are in experimental, and we have some test results, I'll push it to unstable. Okay!! All of the new components of LIO, i.e. configshell, rtslib and targetcli are now in Debian experimental. Now the quality of these packages depend on user testing and bug reports. Excellent. Michael: Since you (and others on this bug report) have interest in LIO, I'd request if you folks can give the version in experimental a test. At this time, I do not have the resources to test an LIO stack. I could use (read desperately require :-) ) tests and reports myself, so please guys, I will be working on the upstream code next week, now is a good time to fill my inbox with reports :-) Kernel version is always one critical piece of information for testing, so please remember to include it! -- Jerome Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
Hi, On 09/18/2014 12:36 PM, Michael Prokop wrote: Hi, * Jerome Martin [Tue Aug 12, 2014 at 12:05:18PM +0200]: Hi Ritesh, Sorry for the late reply, I am on vacation right now. I am aiming at first week of September for the final release. Will keep you posted :-) The merge effort will not be carried out for this one, though, and it still is to be decided how we will version it etc. Any news here, Jerome or Ritesh? Well, obviously I missed that deadline, and am planning on being on it full-time next week, with the goal to release for distros at the end of the week. This i going to be solely bugfixes and more hardware targets validation tests. The delay is due to both personal issues (it's amazing how a sick kid can crush your productivity to ashes, even for a minor throat infection...) and some delays in getting access to the proper test hardware for some of the validation tests. I'm just worried because I'd like to see targetcli in Debian/jessie. :) Yes, I would love that too :-) Thanks for caring and asking! ;-) Thanks! regards, -mika- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
Hi Ritesh, Sorry for the late reply, I am on vacation right now. I am aiming at first week of September for the final release. Will keep you posted :-) The merge effort will not be carried out for this one, though, and it still is to be decided how we will version it etc. Best Regards, -- Jerome On 08/11/2014 10:43 AM, Ritesh Raj Sarraf wrote: On 08/09/2014 01:05 PM, Ritesh Raj Sarraf wrote: On 08/09/2014 03:31 AM, Aurelien Jarno wrote: On Wed, Jun 04, 2014 at 12:16:06PM +0530, Ritesh Raj Sarraf wrote: For the sake of users who may land on this bug report. lio-utils is deprecated upstream. Users are advised to switch to targetcli. lio-utils may soon be removed from the Debian repositories. Even if lio-utils is deprecated, targetcli depends on it. Ignoring this bug just mean we currenyl don't have scsi target support in Jessie, which is be a pitty. No. It is on my list and will be fixed very soon.. Personal stuff has delayed it but soon I'll be resuming work on it. Jerome, When do you plan the 3.0 release ? I see you and Andy talking on merges and newer designs. Please let me know the timelines when you plan a release. Debian will freeze in 2 months and I'd like to push the newer stack as soon as possible. -- Ritesh Raj Sarraf |http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
