Add env_uri to define a plugin as a string

[Joelgranados]

Rocksdb's db_bench uses env_uri to specify the plugins that it will use and to pass parameters to the plugin for initialization. Here we add this functionality to the percona server.

Signed-off-by: Joel Granados [email protected]

[Joelgranados]

ping...

[percona-ysorokin]

Hi @Joelgranados
Sorry for the late response. First of all thank you very much for your contribution we really appreciate it.

However, before proceeding I would like to clarify a few questions regarding the patch you submitted.
First of all, I would like to know the the use case that motivated you to add this env_uri variable. From the very brief documentation I managed to find, I understood that custom Environment objects can be used to instruct RocksDB to work in, say, AWS S3 environment. To do this, somebody needs to implement a custom class, say S3Environment, and register it via ObjectLibrary::Default()->AddFactory<Env>("s3://*", ...). As you might have noticed we already have something very similar for the fs_uri. However we do so, basically, because we have additional RocksDB Filesystem Plugin called zenfs statically compiled in our binaries and Percona Server users can specify --rocksdb-fs-uri=zenfs://... option to use it.
In contrast, in case of env_uri, we do not have any custom Environment objects compiled in / registered and correct me if I a wrong here but it seems that there is little use in adding this variable.

[Joelgranados]

Hey @percona-ysorokin
Very good questions :)

1. What is my motiviation. I'm using percona to test data placement applications/algorithms and this inevitably leads me down the track of implementing a rocksDB plugin for when the data arrives to storage.

2. fs_uri -vs- env_uri. fs_uri is basically a subset of env_uri. When you use fs_uri, you probably use a default environment and add your filesystem plugin. But you do not get access to additional non-filesystem functions like WaitForJoin, StartThread and Unschedule. Having env_uri allows me to pack more functionality in my plugin (if I so choose to do that). But if you want to just implement a filesystem, you can implement the filesystem related functions and leave the others as defaults.

3. Having env_uri is a good way to maybe have other plugins come in besides the already existing Zenfs that you mentioned.

Does this answer your questions? Did I miss something?

[percona-ysorokin]

OK, @Joelgranados
Let me rephrase this a bit. Imagine we merge this PR and at some point we will have a new Percona Server for MySQL release, say 8.0.31, that will include this new --rocksdb-env-uri command line option.
What's the purpose of having it if the only environment we have compiled in our binaries is the Default one. Basically, providing --rocksdb-env-uri=<custom_env> will always be an error as <custom_env> is not registered to match with any custom environment implementation (even if we forget for a moment that our binaries do not have such thing at all).
We simply do not have any ObjectLibrary::Default()->AddFactory<Env>() call in our code (except for a few gunit tests).

[Joelgranados]

Was just wondering if it was of interest. If no, then no :). Thankyou for your feedback! it is very valuable to understand why the motivation behind my PR does not coincide with current objectives. I'll keep the patch around as I'm using it and feel free to get back to me if the objectives shift.