ListVolumesResponse should return an ID

[lpabon]

The current model which provides a StartToken on ListVolumesRequest does not provide enough information if there are multiple clients to the CSI driver. For this reason ListVolumesResponse should return an ID that is passed in with StartToken to identify the caller.

Unless grpc provides a method to get some type of id from the connection?

[jdef]

I don't understand the need for clientID. Can you provide an example workflow that illustrates why a plugin needs to identify unique clients?

…

On Fri, Nov 3, 2017 at 3:48 PM, Luis Pabón ***@***.***> wrote: The current model which provides a StartToken on ListVolumesRequest does not provide enough information if there are multiple clients to the CSI driver. For this reason ListVolumesResponse should return an ID that is passed in with StartToken to identify the caller. Unless grpc provides a method to get some type of id from the connection? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#138>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPVLPLq67gd7WbN_sZH4QzYeawE-1Qcks5sy24agaJpZM4QRmFU> .

[akutz]

Hi @jdef,

Isaw @lpabon's post and started considering this situation myself. First of all, gRPC does not provide a unique connection identifier. The reasoning, IMO, is faulty:

gRPC does not provide this level of functionality, because it isn't valid when proxies are used and even sometimes when they're not.

This is also true for HTTP and does not stop people from using it when it is available. Too much of Go and gRPC seems to be based around what works 100% of the time and not providing tools that work in a large number of cases. I digress.

The reason @lpabon likely brings this issue up is due to concern that paging data might require knowledge of the client requesting the next page so that not any client can request another's paged data mid-query. I can see the point, but I'd argue that a token that's effectively a pointer to a cursor should act like a bearer token -- he who has the token gets the data.

The token could also be made to look like whatever the SP requires. For example, the following JSON object has two fields:

1. i - a unique ID
2. c - a cursor

{
  "i": "bda5c39bdd22448d9c8c6ae211a7265e",
  "c": 800
}

A minified version of the above JSON would be:

{"i":"bda5c39bdd22448d9c8c6ae211a7265e","c":800}

The above could even be base-64 encoded:

eyJpIjoiYmRhNWMzOWJkZDIyNDQ4ZDljOGM2YWUyMTFhNzI2NWUiLCJjIjo4MDB9

However, @jdef, this is why I think you're confused as to the need for the client ID. I think @lpabon believes the token should include a unique ID and the cursor, and I think you, @jdef, probably think the token only needs to be a unique ID.

I think I agree with @jdef here (if I'm even half correct in my assumptions).

While I can see how a token could be nothing more than a simple integer cursor, or could be enhanced to be a JSON object that includes a unique ID and a cursor, as well as any other useful information, I believe ultimately an SP should simply return a unique ID. That ID can be the same for the duration of the paged data, or the ID could change every time a new page is requested. Regardless, the token should be something the SP uses to query its own cache/datastore/storage provider for the next page.

I do not think it's the job of the token to persist information about the client/cursor, but rather the SP uses the token to look up that information in a manner completely opaque to the CO and user.

[jdef]

Another argument I'd like to present: CSI doesn't make any distinction among CO's invoking the same plugin instance's RPC for any other call in the spec, why should it do so for ListVolumes? Yes, I was thinking that the paging token would be a bearer token. It could also encode multiple pieces of information as suggested by @akutz, if needed. At the end of the day, it's opaque to the CO so the plugin can basically do whatever it wants w/ respect to encoding data in the token, subject to the field size limitations proposed by #132

…

On Sat, Nov 4, 2017 at 9:51 PM, Schley Andrew Kutz ***@***.*** > wrote: A quick addendum -- as far as identifying the client with respect to the token goes, it's my opinion that a token for purposes of paging data is a bearer token -- he/she who possesses the token gets the data. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#138 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPVLPjHCULDJZ-LhPzXzeN8OEfjgd1_ks5szRS1gaJpZM4QRmFU> .

[lpabon]

Here is an example:

[ client 1 ] --> |
                      | --> [ csi driver ]
[ client 2 ] --> |

If two clients are connected to the CSI driver and both clients send a ListVolumes( maxEntries = M ) for client 1 at time t1 and ListVolumes( maxEntries = N ) for client 2 at time t2, then how does the driver maintain state to be able to return the correct token for that point-in-time view of volumes?

Currently there is no model to uniquely identify each of these clients.

[codenrhoden]

This seems related to #104 as well

[akutz]

Hi @codenrhoden,

Maybe.

Hi @lpabon,

I'm not sure I understand. The token returned by ListVolumes is a bearer token used by a client to ask for the subsequent data page. Your use case is already handled by the spec.

[lpabon]

Ah, I see @akutz . By a bearer token you mean that it is up to the driver to marshal/unmarshal data into the token to be able to continue with pagination from a specific client. I am ok with this model as long as we describe this on the comments for next_token

[lpabon]

I should leave open to add this documentation to the spec.