-
Notifications
You must be signed in to change notification settings - Fork 146
Framework for setting up environment needed for ASV tests
Writing asv tests against one type of storage which is exclusive like LMDB is generally easy, as all moving parts including the storage are isolated on specific developer machine or on GitHub runner. But when we have to write tests that need to use shared storage, and eventually same tests to be easily and safely executed concurrenty at more than one place could become challenging and lead to unpredictable results. Additionally we would like to reuse SAME tests and run them with minimum change (one parameter for instance) against different kind of storage LMDB, Amazon S3, GCP, Azure etc.
Additionally if we want to reuse setting up similar type of environment in other types of tests we cannot use existing approach for writing tests and setup tightly coupled with the ASV test clases.
We would need a safer approach which requires adding additional abstraction to help us do that safely.
An abstraction taht makes all storages to look like shared storages (even the LMDB).
To achieve that we can use prefixes for Amazon S3 and paths (file locations for LMDB)
On the top level (root) there is:
- one Bucket for Amazon S3
- one root folder for LMDB storages
That will be dedicated space for ASV test
From there we can create several different spaces, dedicated for different needs.
This space is meant to be accessed by all machines and clients and is shared space. It can be used to store data that is going to be written only once, and then all clients could read. Therefore this space is dedicated through a common prefix (name) in the bucket. (PERSISTENT_LIBS_PREFIX)
This space is meant to be private space for each client and test and isolated from others (all modifyable operations require such space). To achieve that the prefix is constructed of several parts.
- First is the common name for this prefix (MODIFIABLE_LIBS_PREFIX)
- then a part unique for each machine can be added through environment variable (ARCTICDB_PERSISTENT_STORAGE_SHARED_PATH_PREFIX) this is done for github and could be done by each person individually
- and the third part can and should be defined in every test case.
Now by concatenating those 3 parts we create a separate unique space in the storage for tests that need to have private space which is in their control
This space is exactly like Persistent space. It serves actually to test the framework if every operation that works on persistant space actually works correct. We can risk and execute something we do not know how it works on shared persistence space. We need a safe space which is like the real one but again is not it. Therefore again a shared space with 3d different prefix is needed, but in this time no concatenations to make it private are needed
Note, that above abstraction with prefixes works with LMDB too as this time it will be the folder structure and the name of folders.
ArcticDB Wiki