Re: [PATCH 3/3] nvmet: include all configured ports in discovery log page for unique discover controller

[Sagi Grimberg <sagi@grimberg.me>]

> So maybe we'll take a step and think about what we actually want
> to support.  Here is my understanding, which might as well be incorrect
> and/or incomplete.
> 
>   1) support a uniqueue discovery controller for bidirectional
>      authentication to work properly
> 
> The only thing we really need is to have the existing discovery log for
> the well known discovery subsystems to be able to also show up as a
> unique discovery subsystem.  Either by just renaming it like your earlier
> patch did, or by supporting an alternative name in addition to that.

I think that making the discovery subsystem show up in configfs makes
sense, it can be attached to port(s) just like any other subsystem.

> 
>   2) (optionally) make the well known discovery controller go away
> 
> Just renaming the subsystem will make the well known one go away,
> but while that can be useful for some use cases, I think making it
> always go away has the potential for breakage.  So maybe we need
> to not rename but be able to create an alias and have a way to
> disable the well known discovery controller if not used.

agreed.

> 
>   3) Actually have a different content.
> 
> Can you explain the use cases here a bit more?
> 
> And maybe add anything else we'd like to consider.  (Everyone else
> on the list please also chime in)

I don't think we should support multiple discovery subsystems on
the same target. Don't know why would anyone need it. I also think
that reporting subsystems that are attached to all ports is just a
a routing failure waiting to happen. But if anyone really really
wants it, we can keep a flag on the discovery subsystem to report
on all ports if explicitly set.