Bug#764005: targetcli: Upgrade issues from 2.1-1
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 ?? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#764005: targetcli: Upgrade issues from 2.1-1
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 The full output from my session is below: targetcli 3.0.pre4.1~ga55d018 (rtslib 3.0.pre4.1~g1b33ceb) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. / ls o- /
Bug#764005: targetcli: Upgrade issues from 2.1-1
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
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#764005: targetcli: Upgrade issues from 2.1-1
Control: severity -1 serious This is a regression, and breaks upgrading systems using targetcli for storage. It's RC. /release-team-hat -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- 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
Control: tag -1 help Right now I'm occupied with personal commitments. If anyone is willing to help, please do. NMUs welcome too. If you'd like to co-maintain, please send me a request on Alioth. https://alioth.debian.org/projects/linux-target There are 2 parts to this bug. 1. Upgrade issues. I haven't looked into it. But there is some details in this bug report, on how to tackle it. 2. There are reports about the targets not being saved. When trying to save, it results in an exception. FTR, with fileio, the configs save fine. Based on conversation with Jerome (upstream developer), I had plans on pushing a new git revision into experimental. Unfortunately, that has not happened yet. On 12/15/2014 04:46 PM, Jonathan Wiltshire wrote: Control: severity -1 serious This is a regression, and breaks upgrading systems using targetcli for storage. It's RC. /release-team-hat -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#764005: targetcli: Upgrade issues from 2.1-1
[ adding CCs I missed when I replied ] On 5 Nov 2014, at 09:55, Ritesh Raj Sarraf r...@researchut.com wrote: Hello Chris, On 10/08/2014 01:09 AM, Chris Boot wrote: I won't reset it, but the bug report covered other points that make targetcli unusable for me at the moment even ignoring the upgrade issue. I will try to resolve all the major issues. But I am not going to be looking into the upgrade issue for now, due to lack of time. I'd be happy to take patches though. Even with the obvious missing dependencies installed, I can't saveconfig or exit from targetcli. THis should be fixed with python-rtslib 3.0+git0.86e46bc6-4 upload Hi Ritesh, Things do indeed seem better now, but still not quite right… Leaving my existing configuration loaded (by manually preventing the lio-utils postrm script from stopping the targets) and upgrading targetcli gives me the following now instead: tarquin bootc # targetcli targetcli GIT_VERSION (rtslib GIT_VERSION) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. / ls o- / . [...] o- backstores .. [...] | o- fileio ... [0 Storage Object] | o- iblock .. [3 Storage Objects] | | o- dietrich [/dev/vg_data/lio_dietrich activated] | | o- ripley_data ... [/dev/vg_data/lio_ripley activated] | | o- ripley_ssd . [/dev/vg_tarquin/lio_ripley activated] | 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 ... [2 Targets] | o- 21:00:00:e0:8b:91:67:2c ... [enabled] | | o- acls .. [1 ACL] | | | o- 21:00:00:1b:32:15:f4:1b . [2 Mapped LUNs] | | | o- mapped_lun0 ... [lun0 (rw)] | | | o- mapped_lun1 ... [lun1 (rw)] | | o- luns . [2 LUNs] | | o- lun0 ... [iblock/ripley_ssd (/dev/vg_tarquin/lio_ripley)] | | o- lun1 . [iblock/ripley_data (/dev/vg_data/lio_ripley)] | o- 21:01:00:e0:8b:b1:67:2c ... [enabled] | o- acls .. [1 ACL] | | o- 21:00:00:1b:32:10:26:46 .. [1 Mapped LUN] | | o- mapped_lun0 ... [lun0 (rw)] | o- luns .. [1 LUN] | o- lun0 .. [iblock/dietrich (/dev/vg_data/lio_dietrich)] o- tcm_fc [0 Targets] / saveconfig WARNING: Saving tarquin current configuration to disk will overwrite your boot settings. The current target configuration will become the default boot config. Are you sure? Type 'yes': yes Saving new
Bug#764005: targetcli: Upgrade issues from 2.1-1
On 11/16/2014 04:02 PM, Chris Boot wrote: Hi Ritesh, Things do indeed seem better now, but still not quite right… Leaving my existing configuration loaded (by manually preventing the lio-utils postrm script from stopping the targets) and upgrading targetcli gives me the following now instead: tarquin bootc # targetcli targetcli GIT_VERSION (rtslib GIT_VERSION) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. This GIT_VERSION things is something I'd like to fix. But given the freeze I'm not sure if an exception will be allowed. My plan is to get a new version in experimental (as about how me and Jerome have discussed) and then maybe ask Release Team for an exception. / ls o- / . [...] o- backstores .. [...] | o- fileio ... [0 Storage Object] | o- iblock .. [3 Storage Objects] | | o- dietrich [/dev/vg_data/lio_dietrich activated] | | o- ripley_data ... [/dev/vg_data/lio_ripley activated] | | o- ripley_ssd . [/dev/vg_tarquin/lio_ripley activated] | 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 ... [2 Targets] | o- 21:00:00:e0:8b:91:67:2c ... [enabled] | | o- acls .. [1 ACL] | | | o- 21:00:00:1b:32:15:f4:1b . [2 Mapped LUNs] | | | o- mapped_lun0 ... [lun0 (rw)] | | | o- mapped_lun1 ... [lun1 (rw)] | | o- luns . [2 LUNs] | | o- lun0 ... [iblock/ripley_ssd (/dev/vg_tarquin/lio_ripley)] | | o- lun1 . [iblock/ripley_data (/dev/vg_data/lio_ripley)] | o- 21:01:00:e0:8b:b1:67:2c ... [enabled] | o- acls .. [1 ACL] | | o- 21:00:00:1b:32:10:26:46 .. [1 Mapped LUN] | | o- mapped_lun0 ... [lun0 (rw)] | o- luns .. [1 LUN] | o- lun0 .. [iblock/dietrich (/dev/vg_data/lio_dietrich)] o- tcm_fc From you logs, it is not very clear whether you are using an FC target. Are you ? Can you please confirm your configuration ? [0 Targets] / saveconfig WARNING: Saving tarquin current configuration to disk will overwrite your boot settings. The current target configuration will become the default boot config. Are you sure? Type 'yes': yes Saving new startup configuration saveconfig worked for me. But, of course, I hadn't configured any real service. I just tested it with fileio.
Bug#764005: targetcli: Upgrade issues from 2.1-1
Hello Chris, On 10/08/2014 01:09 AM, Chris Boot wrote: I won't reset it, but the bug report covered other points that make targetcli unusable for me at the moment even ignoring the upgrade issue. I will try to resolve all the major issues. But I am not going to be looking into the upgrade issue for now, due to lack of time. I'd be happy to take patches though. Even with the obvious missing dependencies installed, I can't saveconfig or exit from targetcli. THis should be fixed with python-rtslib 3.0+git0.86e46bc6-4 upload -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#764005: targetcli: Upgrade issues from 2.1-1
Control: severity -1 important @Chris: Are you okay if I downgrade this? With severity grave it will be a candidate for removal. I understand the data loss situation during upgrades, but for users deploying it fresh, it is a non-issue. Please reset to grave if you disagree. My intent is to have LIO target for Jessie, available. On Sunday 05 October 2014 02:00 PM, 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... Is this save functionality available and ready to test, in the new 3.x series that in now in the archive ? Sorry, I ask this because I don't have the resources to test these myself. If that functionality is in, then yes, we could fix it the way you and Chris have proposed. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention.
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
Okay!! Thanks to both of you. I will prepare something next week. My
only request is if (other) users can test it in time.
On Tuesday 07 October 2014 03:32 PM, Jerome Martin wrote:
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
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
Bug#764005: targetcli: Upgrade issues from 2.1-1
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 ? -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention.
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 07/10/2014 10:19, Ritesh Raj Sarraf wrote: Control: severity -1 important @Chris: Are you okay if I downgrade this? With severity grave it will be a candidate for removal. I understand the data loss situation during upgrades, but for users deploying it fresh, it is a non-issue. Please reset to grave if you disagree. My intent is to have LIO target for Jessie, available. Hi Ritesh, I won't reset it, but the bug report covered other points that make targetcli unusable for me at the moment even ignoring the upgrade issue. Even with the obvious missing dependencies installed, I can't saveconfig or exit from targetcli. HTH, Chris -- Chris Boot deb...@bootc.net PGP: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE -- 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
Thanks for the bug report. Jerome: How can we ensure to have the old 2.x settings / targets in 3.x ? On Saturday 04 October 2014 11:00 PM, Chris Boot wrote: Package: targetcli Version: 3.0+git0.7e32595e-2 Severity: grave Justification: renders package unusable Dear Maintainer, The upgrade from targetcli 2.1-1 removes all targets and makes targetcli unusable. 1. Removing lio-utils disables/removes all targets from the kernel. This is a serious problem on something like a storage server. 2. Once you can manage to run targetcli (see #XX), you are greeted with an error: This RTSRoot does not exist in configFS. tarquin bootc # targetcli This RTSRoot does not exist in configFS. targetcli GIT_VERSION (rtslib GIT_VERSION) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. 3. Performing an 'ls' lists no available target modules and only the pscsi backstore module: / ls o- / [...] o- backstores . [...] o- pscsi ... [0 Storage Object] / 4. When you try to exit, targetcli tries to look in /var/target/policy and explodes because that directory doesn't exist: / exit Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 990, in run_interactive self._cli_loop() File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 820, in _cli_loop self.run_cmdline(cmdline) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 934, in run_cmdline self._execute_command(path, command, pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 909, in _execute_command result = target.execute_command(command, pparams, kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 103, in execute_command pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/node.py, line 1416, in execute_command result = method(*pparams, **kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 115, in ui_command_exit config = Config() File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 133, in __init__ self._load_policy() File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 140, in _load_policy for path in os.listdir(self.policy_dir) OSError: [Errno 2] No such file or directory: '/var/target/policy' / 5. If you create the directory you still can't exit because of the error described in point 2: / exit This RTSRoot does not exist in configFS. / The only way to escape this seems to be to kill targetcli from another window. 6. 'service target stop' followed by 'service target start', then re-entering targetcli allows all the various target types to become available again. 7. Trying to exit at this point (without making any changes) bombs out again: / exit Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 990, in run_interactive self._cli_loop() File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 820, in _cli_loop self.run_cmdline(cmdline) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 934, in run_cmdline self._execute_command(path, command, pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 909, in _execute_command result = target.execute_command(command, pparams, kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 103, in execute_command pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/node.py, line 1416, in execute_command result = method(*pparams, **kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 119, in ui_command_exit config.load_live() File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 562, in load_live source=source, allow_new_attrs=True) File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 190, in _load_parse_tree token = self.validate_obj(token, cur) File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 385, in validate_obj raise ConfigError(Unknown object type: %s % obj_type) ConfigError: Unknown object type: fabric / I am now trying to get my targets running again, which I am having to do by using the bits of targetcli that work and manual changes in /sys/kernel/config/target. I can't 'savechanges' in targetcli either. I am not impressed. HTH, Chris -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh
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#764005: targetcli: Upgrade issues from 2.1-1
Hi,
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.
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.
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.
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.
HTH,
Chris
On 5 Oct 2014, at 09:35, Jerome Martin j...@netiant.com wrote:
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#764005: targetcli: Upgrade issues from 2.1-1
Package: targetcli Version: 3.0+git0.7e32595e-2 Severity: grave Justification: renders package unusable Dear Maintainer, The upgrade from targetcli 2.1-1 removes all targets and makes targetcli unusable. 1. Removing lio-utils disables/removes all targets from the kernel. This is a serious problem on something like a storage server. 2. Once you can manage to run targetcli (see #XX), you are greeted with an error: This RTSRoot does not exist in configFS. tarquin bootc # targetcli This RTSRoot does not exist in configFS. targetcli GIT_VERSION (rtslib GIT_VERSION) Copyright (c) 2011-2014 by Datera, Inc. All rights reserved. 3. Performing an 'ls' lists no available target modules and only the pscsi backstore module: / ls o- / [...] o- backstores . [...] o- pscsi ... [0 Storage Object] / 4. When you try to exit, targetcli tries to look in /var/target/policy and explodes because that directory doesn't exist: / exit Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 990, in run_interactive self._cli_loop() File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 820, in _cli_loop self.run_cmdline(cmdline) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 934, in run_cmdline self._execute_command(path, command, pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 909, in _execute_command result = target.execute_command(command, pparams, kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 103, in execute_command pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/node.py, line 1416, in execute_command result = method(*pparams, **kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 115, in ui_command_exit config = Config() File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 133, in __init__ self._load_policy() File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 140, in _load_policy for path in os.listdir(self.policy_dir) OSError: [Errno 2] No such file or directory: '/var/target/policy' / 5. If you create the directory you still can't exit because of the error described in point 2: / exit This RTSRoot does not exist in configFS. / The only way to escape this seems to be to kill targetcli from another window. 6. 'service target stop' followed by 'service target start', then re-entering targetcli allows all the various target types to become available again. 7. Trying to exit at this point (without making any changes) bombs out again: / exit Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 990, in run_interactive self._cli_loop() File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 820, in _cli_loop self.run_cmdline(cmdline) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 934, in run_cmdline self._execute_command(path, command, pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/shell.py, line 909, in _execute_command result = target.execute_command(command, pparams, kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 103, in execute_command pparams, kparams) File /usr/lib/python2.7/dist-packages/configshell/node.py, line 1416, in execute_command result = method(*pparams, **kparams) File /usr/lib/python2.7/dist-packages/targetcli/ui_node.py, line 119, in ui_command_exit config.load_live() File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 562, in load_live source=source, allow_new_attrs=True) File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 190, in _load_parse_tree token = self.validate_obj(token, cur) File /usr/lib/python2.7/dist-packages/rtslib/config.py, line 385, in validate_obj raise ConfigError(Unknown object type: %s % obj_type) ConfigError: Unknown object type: fabric / I am now trying to get my targets running again, which I am having to do by using the bits of targetcli that work and manual changes in /sys/kernel/config/target. I can't 'savechanges' in targetcli either. I am not impressed. HTH, Chris -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages targetcli depends on: ii python 2.7.8-1 ii python-configshell 1.5+git0.0827baa6-2 ii python-rtslib 3.0+git0.86e46bc6-2 targetcli recommends no
