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