Re: [SPDK] SPDK Event notifications

[Walker, Benjamin <benjamin.walker at intel.com>]

[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]

On Wed, 2018-10-10 at 15:38 +0000, Wodkowski, PawelX wrote:
> See comments inline.
> 
> Paweł
> 
> > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Pelplinski, Piotr
> > 
> > Hi,
> > I started work on SPDK event notifications.  I have few doubts that you
> > might help me resolve.
> > This functionality adds ability to register for specific events (i.e. a new
> > bdev), and be notified asynchronously when those events occur.
> > 
> > My proposal is three RPC calls based on following workflow:
> > 
> > 1.      After SPDK application starts, client sends RPCs to SPDK about what
> > kinds of events it wants to register for.
> > 
> > 2.      Then, client subscribes to specified events.
> > 
> > 3.      Then the client periodically asks for new events.
> 
> Why client need to ask for new event? Why event can't be send just send to all
> clients ASAP they available?
> You will have to track what events was send to what clients.

I think the above statement about tracking which events to send to which client
outlines the major problem here. Tracking which events each client needs is very
difficult - for instance, how long do you keep events around? A client could
check in once a month, for example. Further, how many simultaneous clients do we
need to keep track of? How much memory is that going to take? I'm positive that
we don't want to go down this path.

Clients already have the ability to simply poll the state of the system by
periodically issuing RPCs. That's good enough for most cases and is entirely
stateless (the REST paradigm - we even use JSON!). We could consider an event
stream API as an optimization only, where clients send an RPC and the response
contains a file descriptor (maybe a domain socket?) where a stream of JSON
objects corresponding to events as they happen is published (but not events from
before the connection was established). A client would then begin by sending the
existing RPCs to gather the current state of the world, then subscribe to this
event API for changes only.

> > 
> > RPC Calls:
> 
> Are you describing the JSON RPC objects here or rpc.py commands?
> 
> > 
> > 1.      show_async_events <component>
> > component (optional) - show events for specified component only
> > 
> > 2.      register_async_events <unique_id>, <events>
> > unique_id - unique identifier for client
> 
> What is the unique_id for? Isn't the connection itself an "unique id" enough?

Presumably the client could crash, get restarted, and want to grab the events it
missed by using the unique id.

> 
> 
> > events - list of comma separated events which client wants to subscribe to.
> 
> 
> > (Additional question: Does event should have parameters too? e.g. subscribe
> > only to event: deletion of bdev with specific name)
> > Response is a list of types of events to which client was subscribed.
> > 
> > 3.      poll_async_events <unique_id>
> > unique_id - unique identifier for client
> > Response is a list of events which happen from last call, which include:
> > 
> > -        Component, # component type for which event is raised
> > 
> > -        Notification,  # type of event, e.g. add, delete or update
> > 
> > -        Component_uuid, (e.g lvol uuid)
> > 
> > -        Parent_uuid (e.g. lvolstore uuid)
> > 
> > My question is what are the types of events we could register to?
> > I can think of few generic bdev events like:
> > -added bdev
> > -deleted bdev
> > -updated bdev
> > 
> > What other types of event do you see?
> 
> Runtime errors? Statistics? Nvmf/iscsi/vhost initiators connecting and
> disconnecting.
> There will be many more but the solution you are proposing should be generic
> enough to easly add more event in the future. bdev subsystem good starting
> point.
> 
> > 
> > You can also look at the updates on this topic on trello:
> > https://trello.com/c/ZTIHxp3w/28-asynchronous-rpc-notifications
> > 
> > --
> > Best Regards,
> > Piotr Pelpliński
> >