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
