Re: srp_daemon : ​Disallow ​all targets ​if ​not ​explicitly ​allowed by default

[Roland Fehrenbacher <rf-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>]

>>>>> "BD" == Benjamin Drung <benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org> writes:

Hi all,

    BD> Am Dienstag, den 09.05.2017, 21:01 +0300 schrieb Leon
    BD> Romanovsky:
    >> On Tue, May 09, 2017 at 01:41:46PM -0400, Laurence Oberman wrote:
    >> >
    >> >
    >> > ----- Original Message -----
    >> > > From: "Bart Van Assche" <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> To:
    >> > > "Benjamin Drung" <benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>, linux-rdm
    >> > > a@vger.kernel.org Sent: Tuesday, May 9, 2017 1:11:06 PM
    >> > > Subject: Re: srp_daemon : Disallow all targets if not
    >> > > explicitly allowed by default
    >> > >
    >> > > On 05/09/17 10:07, Benjamin Drung wrote:
    >> > > > srptools 1.0.3-2 in Debian disallows all targets if not
    >> > > > explicitly allowed by default. Motivation (taken from
    >> > > > debian/changelog):
    >> > > >
    >> > > > * Don't activate any targets per default. (Closes: #740945)
    >> > > >   This is more sensible than the previous default of
    >> > > > bringing   up all targets in the IB fabric upon boot. In a
    >> > > > larger fabric   with many storage targets available, most
    >> > > > of the times only   one or a few targets are wanted on a
    >> > > > particular machine.
    >> > > >
    >> > > > Do you agree and could you change the default upstream? I
    >> > > > prefer not to carry a different behavior in Debian alone.
    >> > >
    >> > > Hello Benjamin,
    >> > >
    >> > > What I expect is that users will hate this change. They will
    >> > > notice that after they have installed and enabled srp_daemon
    >> > > that no targets are discovered without having any clue why no
    >> > > automatic login to SRP targets occurs.
    >> > >
    >> > > Bart.
    >> > >
    >> > > -- To unsubscribe from this list: send the line "unsubscribe
    >> > > linux- rdma" in the body of a message to
    >> > > majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info
    >> > > at  http://vger.kernel.org/majordomo-info.htm l
    >> > >
    >> >
    >> > Hello
    >> >
    >> > Indeed, I agree with Bart here, this change will lead to a lot
    >> > of confusion about why users no longer see device discovery.
    >> > For me I would prefer its not changed.
    >>
    >> According to the Benjamin's description, this is already behavior
    >> of Debian and their derivatives. So this change won't change for
    >> these users anything. I think that the best solution will be to
    >> keep in sync distros and upstream. Or enable by default on all
    >> systems or disable by default on all systems.

    BD> This change was uploaded to Debian unstable two days ago. So it
    BD> is a recent change done by Roland Fehrenbacher (CCed) which
    BD> still can be reverted. I'm fine with any option as long as
    BD> Debian and upstream are in sync.

    BD> Bart's objection (that users of large setups know how to edit
    BD> the srp_daemon configuration file but most users of small setups
    BD> don't know how to edit that configuration file) seem valid to
    BD> me. Roland, your input please.

it's hard to judge what is the most wanted default setup. The reason why
this was changed was the cited Debian bug report. I'm also a friend of
well-defined configs, so I agree with that opinion. I believe,
adding a '#' in front of a line of a config file shouldn't overburden an
admin who deals with IB storage under Linux, if she/he prefers the most
simple config. The change in Debian is also clearly communicated (NEWS
file), so I don't really see a problem. Finally: There are many packages
in Debian that have a different default config as compared to upstream.

Cheers,

Roland--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html