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

[sagi@grimberg.me (Sagi Grimberg)]

>> I do have some quite fundamental problem with discovery log change 
>> events:
>> - The initial discovery is still unsolved, ie we have to know the 
>> transport address before we can even get to those events
> 
> I understand your concern, but its completely irrelevant to this.
> This is a building block to automate the entire sequence, but
> the fact that we don't have it all automated doesn't mean we should
> not support discovery log change AENs.
> 
> For root discovery automation, we can talk about bringing a tpar
> with a prototype.
> 
>> - More crucially, we don't get these events when we to the first 
>> connection, requiring us to have the initial call to 'connect-all' on 
>> a separate way.
> 
> Again, this is initial root discovery, which is irrelevant to discovery
> log change events.
> 
>> - We don't have any indication if a new subsystem has been created; 
>> once a subsystem a new subsystem on another port is created it's 
>> anyones guess if that'll show up on the particular discovery controller
> 
> What? the event is on the port level, every port/subsystem softlink will
> trigger a discovery log change event. Its not anyones guess, its pretty
> deterministic given that you have discovery controller connected to the
> port.
> 
>> Especially the second point is most vexing; we could get around this 
>> by requiring the discovery controller to send AENs on the initial connect
>> (well, actually as soon as the AENs are enabled), but I guess that'll 
>> require a change to the spec ...
> 
> Why? with a script to auto-connect or root discovery automation this is 
> no longer an issue (not sure how much this is an issue right now).

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...