[PATCH nvme-cli rfc 0/6] Support discovery log change events

[sagi@grimberg.me (Sagi Grimberg)]

>> Reviving this (again).
>>
>> Hannes, did you have a chance to look at this? Unless there are other
>> alternatives I suggest we go with this approach.
>>
>> We should be able to support discovery log change events automatically
>> at some point...
> 
> Yes, I did.
> And had several discussions with the involved parties (Hello, James :-).
> Consensus was that for FC we don't really need discovery AENs, as the 
> transport has knowledge about the fabric and the attached ports, and 
> will generate events on any topology change already.
> For RDMA and TCP, OTOH, we don't know the topology, and to be able to 
> discovery we will know the fabric ports in advance.
> So there automatic discovery is a real win, and arguably necessary if a 
> connection needs to be re-established after a fabric outage.

Again, this is a different thing Hannes, please stop mixing stuff.
I'm not arguing with you that we want automatically discover the fabric,
but discovery change log events and root discovery are different things
and only one of them is up for discussion here.

> Implementation-wise I'm not thoroughly happy with the MDNS approach, as 
> this requires quite a bit of additional infrastructure which needs to be 
> present on both sides.
> And my worry is that during failover scenarios we might not be able to 
> run these services at all (seeing that the root-fs is blocked).
> But if that is acceptable (read: if booting from those NVMe devices is 
> not required) then I guess we could go that way.
I'm going to ignore stuff about root discovery here (nothing personal,
its just not the subject here), we can talk about it in a separate
thread.

Now, I'm suggesting to support discovery change log events by allowing
the user to setup a persistent discovery controller and have the kernel
fire to userspace discovery change log events over that controller.

Any comments/feedback/alternatives on _this_?