Fetch OMap keys in bulk that one by one

[ShyamsundarR]

In function GetObjectUUIDData we fetch multiple keys from the same OMap, this can be optimized to fetch all keys in one call, and hence save a network roundtrip in fetching these one by one.

This should speed up operations around snapshot management, as the second key is fetched (at present) when snapshots are in play.

The intention is to use list equivalents to fetch all keys, rather dump one key at a time into the output file.

[humblec]

Moving out of release-1.2.0 as this is yet to be started.

[phlogistonjohn]

@nixpanic @ShyamsundarR I'm interested in taking a stab at this. It looks nicely self contained and a good way to start re-learning ceph-csi again. Thoughts?

[ShyamsundarR]

@nixpanic @ShyamsundarR I'm interested in taking a stab at this. It looks nicely self contained and a good way to start re-learning ceph-csi again. Thoughts?

More power to you :) 👍 you would be looking at one call instead of the swarm here I presume, to reduce the call counts. Thanks!

[phlogistonjohn]

I'm happy to look at both. I'll probably start simple with a direct translation of GetOMapValue from cli to go-ceph. Then I'll look into making a "GetMultiOMapValues" kind of thing to see if we can cut down on round-trips.

The existing go-ceph calls, despite a number of issues I already have with them, already support handling multiple omap key/values in one call.

[phlogistonjohn]

Pardon my confusion, but GetObjectUUIDData function appears to be gone now.
Interestingly, the file "./scripts/golangci.yml" appears to be the only thing left referring to it, stating:

  dogsled:
    # voljournal.GetObjectUUIDData currently returns 4 values of which some may
    # not always be useful
    max-blank-identifiers: 3

I have no idea what "dogsled" is but my guess is that this comment is out of date. Shall I remove the comment? I don't have anything to put in its place.

[ShyamsundarR]

Pardon my confusion, but GetObjectUUIDData function appears to be gone now.
Interestingly, the file "./scripts/golangci.yml" appears to be the only thing left referring to it, stating:

  dogsled:
    # voljournal.GetObjectUUIDData currently returns 4 values of which some may
    # not always be useful
    max-blank-identifiers: 3

I have no idea what "dogsled" is but my guess is that this comment is out of date. Shall I remove the comment? I don't have anything to put in its place.

I did not know this existed in that file. We can remove it, as I fixed that up to return a structure.

Apparently (googling states) dogsled is: "dogsled: Checks assignments with too many blank identifiers (e.g. x, _, _, _, := f())" (from here), which was true for this function prior to the change to return the struct.

[nixpanic]

There are a few old commits in my wip/rbd/go-ceph tree. See commits like util: use go-ceph for GetOMapValue(). These need to get adapted to use rbdVol.conn.GetIoctx(poolname) as is done for deleteImage() in PR #862