[Bug 846945] New: open-iscsi should be updated to start when needed using systemd
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c0 Summary: open-iscsi should be updated to start when needed using systemd Classification: openSUSE Product: openSUSE 13.1 Version: RC 1 Platform: All OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: lduncan@suse.com ReportedBy: lduncan@suse.com QAContact: qa-bugs@suse.de CC: hare@suse.com, meissner@suse.com, werner@suse.com, michaelc@cs.wisc.edu, fcrozat@suse.com, fxzhang@suse.com Depends on: 821695,827654 Found By: Development Blocker: --- +++ This bug was initially created as a clone of Bug #827654 +++ +++ This bug was initially created as a clone of Bug #821695 +++ Now that open-iscsi has been integrated with systemd in openSUSE, it now has reduced functionality compared with earlier versions, a clear regression. The open-iscsi service used to be installed, when based on system V init, as enabled. As part of the integration process with systemd, open-iscsi has been modified so that it is now socket activated. This means that, in conjunction with systemd, the iscsi service need not be enabled as long as the iscsid.socket *is* enabled. If this base-level socket is enabled then systemd takes care of starting the iscsid service (and accompanying daemon) when needed. This means that if no iscsid service is being used that the iscsid daemon is never started. This is why the iscsid.socket service should be enabled by default. In addition, the new open-iscsi/systemd integration means that higher-level iscsi services, such as logging into (or out of) targets, thus establishing sessions, is now layered as an additional service on top of the iscsid.service. This new top-level service is called iscsi.service, and only worries about logging into targets if (and only if) the user has those targets in their iSCSI database as needing to be connect at boot time. This new iscsi.service service has no associated daemon, and will only activate the iscsi.service iscsid daemon if needed. Again, no load on the end-user's system. And I would argue that if the user has iscsi nodes in their database that are listed as needing to be connect "onboot", that we had better have that service enabled, or the user is not going to have a good boot experience. Again, the systemd units iscsid.socket and iscsi.service need to be enabled by default. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c1 Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Lee Duncan <lduncan@suse.com> 2013-10-21 14:52:55 PDT --- accepted, simple fix, but will have to get permission to make such a change, since the list of auto-enabled service seems to guarded like Fort Knox. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c2 Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO CC| |aj@suse.com InfoProvider| |lduncan@suse.com --- Comment #2 from Andreas Jaeger <aj@suse.com> 2013-10-22 06:29:12 UTC --- Lee, we have a policy of not enabling services by default. This policy was introduced at the time when we switched to systemd. Yes, this is a change to the old way with SysV Init. Is there a specific reason that open-iscsi needs to be enabled by default when installed? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c3 Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|lduncan@suse.com |aj@suse.com --- Comment #3 from Lee Duncan <lduncan@suse.com> 2013-10-22 15:09:43 PDT --- Andreas: I'm not clear on this new policy. Is it that no service is enabled by default, ever, from now on, or are there exceptions? I assumed the policy was designed to stop all services from enabling themselves by default, when installed, since that might not be what the user wanted in all cases. Especially if such automatic enablement means the system is bogged down using unneeded resources because daemons are running when not needed. In this case, it seems like the socket-driven model available to systemd services means that "enabling" iscsid.socket in this case causes almost no system impact. And I feel that the principle of least surprise should be that if the customer installs open-iscsi and runs "iscsiadm -m discovery ..." to find some nodes, they don't expect a message saying "the daemon is not running". The daemon should be started. In the System V Init days, there was a line in /etc/iscsi/iscsid.conf that told the open-iscsi system to start up the daemon in such cases, if needed. But that line has been removed because of systemd's socket-driven functionality. I noticed that there are more than a few other services that are enabled by default, hence my confusion. Is this new policy from systemd or by openSUSE? Do you have a reference to it and other such policies, so I can provide appropriate submissions in the future? I take it, then, that the expected work flow for most service installations will be, from the end user point of view: 1. install the service (using zypper or yast2), then 2. manually run "systemctl enable <SERVICE>" from the command line Is this correct? In the case of open-iscsi, there are 3 services, and only 2 of them should be enabled, since enabling the 3rd will mean the iscsid daemon is running even if not needed. I thought automatically installing open-iscsi with the correct 2 of 3 units enabled would result in the least number of bugs filed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c4 Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|aj@suse.com | --- Comment #4 from Andreas Jaeger <aj@suse.com> 2013-10-23 07:48:19 UTC --- (In reply to comment #3)
Andreas: I'm not clear on this new policy. Is it that no service is enabled by default, ever, from now on, or are there exceptions? I assumed the policy was designed to stop all services from enabling themselves by default, when installed, since that might not be what the user wanted in all cases. Especially if such automatic enablement means the system is bogged down using unneeded resources because daemons are running when not needed.
The file default-openSUSE.preset defines what is enabled by default - those are the exceptions. If there are really valid reasons to enable open-iscsi, we can add it.
In this case, it seems like the socket-driven model available to systemd services means that "enabling" iscsid.socket in this case causes almost no system impact. And I feel that the principle of least surprise should be that if the customer installs open-iscsi and runs "iscsiadm -m discovery ..." to find some nodes, they don't expect a message saying "the daemon is not running". The daemon should be started. In the System V Init days, there was a line in /etc/iscsi/iscsid.conf that told the open-iscsi system to start up the daemon in such cases, if needed. But that line has been removed because of systemd's socket-driven functionality.
I noticed that there are more than a few other services that are enabled by default, hence my confusion. Is this new policy from systemd or by openSUSE?
This is an openSUSE policy.
you have a reference to it and other such policies, so I can provide appropriate submissions in the future?
This should be documented in the openSUSE wiki under packaging guide lines but sometimes the sections are not complete.
I take it, then, that the expected work flow for most service installations will be, from the end user point of view: 1. install the service (using zypper or yast2), then 2. manually run "systemctl enable <SERVICE>" from the command line
Is this correct? In the case of open-iscsi, there are 3 services, and only 2 of
Yes, that's correct.
them should be enabled, since enabling the 3rd will mean the iscsid daemon is running even if not needed. I thought automatically installing open-iscsi with the correct 2 of 3 units enabled would result in the least number of bugs filed.
So, it's the choice of enabling two for everybody that installs it - versus the fear that users might start all three manually? Two bad choices ;( Btw. if you disagree, feel free to discuss on openstack-packaging in a larger round. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c Bug 846945 depends on bug 827654, which changed state. Bug 827654 Summary: open-iscsi should be updated to integrate with systemd http://bugzilla.novell.com/show_bug.cgi?id=827654 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c5 Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium --- Comment #5 from Lee Duncan <lduncan@suse.com> 2013-10-28 12:47:25 PDT --- Updating priority to P3 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |847953 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c6 --- Comment #6 from Lee Duncan <lduncan@suse.com> 2013-10-30 16:05:24 PDT --- Looks like it's fixed in Factory: https://build.opensuse.org/request/show/203672 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|847953 | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c7 Lee Duncan <lduncan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #7 from Lee Duncan <lduncan@suse.com> 2013-12-12 14:07:04 PST --- Removed dependency on 845593, and marked as resolved. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=846945 https://bugzilla.novell.com/show_bug.cgi?id=846945#c8 --- Comment #8 from Lee Duncan <lduncan@suse.com> 2013-12-12 14:09:32 PST --- Make the removed dependency on 847953. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com