[PATCH 1/3] nvmet: expose discovery subsystem in sysfs

[Sagi Grimberg]

>> The core question really is: do we _want_ to expose the discovery subsystem
>> in configfs?
> 
> Well, if you want a freely configurable one we kinda have to, right?
> 
>> Unfortunately, exposing the discovery subsystem and trying to configure it
>> with configfs does _not_ match with the way discovery is implemented today.
>> While we currently only have a single discovery subsystem, it will only
>> ever return the subsystems visible from this particular port.
> 
> Well.  The original Fabrics spec had this concept of that magic discovery
> NQN, which implies that there is one subsystem (or many pretending to be
> one).  And that is what the implementation followed.  The varipus 80?? TPs
> then made a complete mess off that.
> 
>> Hence this rather simple approach, having the 'normal' discovery subsystem
>> exposed, and let the admin configure it accordingly.
>>
>> I can look at keeping the internal implementation, and only expose unique
>> discovery controller (ie those with a unique subsystem NQN).
>> That would remove the need to having the 'discovery_nqn' attribute, and
>> address Christophs concerns.
> 
> I suspect if we want to support all the new mess from the FMDS group
> (and maybe we need to question the why a little more)

IIRC there were different reasons that we probably shouldn't care about
that were related to the centralize discovery thing, but a side issue
was a problem with authenticating against a discovery subsystem that
have a universal name (not exactly sure about the details, because we do
also have the hostnqn in the psk identity). However assuming this is a
real issue, then we probably want to support it.

>, then we should so something like:
> 
>   (1) keep the existing global NQN-based discovery as-is.
>   (2) maybe add a per-port known to allow disabling it if people really care
>   (3) allow creating additional discovery subsystems with non-default
>       NQNs that do not automatically get anything added to them and will
>       just be configured as needed through configfs

I don't think we should do a discovery subsystem that tells you about
subsystems in other ports, that is most likely asking for connectivity
issues. Unless the log page is constructed based on explicit
configuration.

> But maybe first we should take a step back and figure out what supporting
> TPAR8013 even buys us?

Hannes may know better on the authentication aspect...