Hitherto, Trove has not made a clear distinction of which datastores are considered to be “experimental” and which are considered to be “suitable for general use”. At the mid-cycle in Seattle (Kilo release) we discussed the possibility of introducing a clear definition of what an “experimental” datastore would be and how one could migrate a datastore from “experimental” to “suitable for general use”.
When code for a datastore is submitted to Trove, there is no clear indication whether that datastore is in a state that would be sufficient for general use. For example, while a single instance datastore of MySQL is perfectly usable for some development and test use cases but a single instance datastore of (say) Cassandra is much less useful. A datastore that supports backup and restore is more useful than one that does not.
As a community we wish to be welcoming of changes but no all change sets are made equal. Some include extensive capabilities and test coverage while others are more basic. In an effort to make it clear what we, as a community, believe is the “readiness” of a datastore, we believe that a classification of datastores is a good improvement.
It is proposed that we create three groups of datastores as described in detail below. This classification will mean that any datastore could be considered to be either (a) “experimental”, (b) “technical preview”, or (c) “stable”.
In each release, beginning with the Kilo release, each datastore will be given a classification that will be one of the values listed above based strictly on its adherence to the requirements for each of those classifications.
The classifications will be inclusive; i.e. a datastore that meets the “technical preview” requirements must also meet all the requirements for “experimental”, and a datastore that meets the “stable” requirements must also meet all the requirements for “technical preview”.
In a similar vein, we will also assign a classification to each strategy. Some strategies may be more throughly vetted and tested (for example) than others. While (purely for purposes of illustration) mysql_binlog may be considered “stable”, one could have a different replication strategy that was considered “experimental”.
At the very least, this change will impact the trove-guestagent.conf file as it lists the datastore registry by providing the path to the implementation (manager.py)
Any similar location either in a configuraiton file (or for that matter, in the code) that calls out a location of an implementation will have to change.
This should have no database changes.
This change has no impact on the Public API.
No changes to the internal API.
It does not change the behavior of the guest agent, merely the location of the code.
As part of this change, it is proposed that the following assignments be made.
Stable: MySQL Technical Preview: Cassandra and MongoDB Experimental: All others
A datastore will be considered for merging in the experimental stage if it includes the following items.
A strategy will be considered experimental if an implementation is provided and includes basic unit tests to verify operation of the strategy. A passing, and non-voting test suite should also be provided.
A datastore will be considered for “Technical Preview” if it meets the requirements of “Experimental” and further
Note that it is not required that the datastore implement all features (resize, backup, replication, clustering, ...) to meet this classification.
It is also required that non-voting gate tests for all capabilities and a mechanism to build a guest image that will allow a user to exercise these capabilities is provided.
A strategy will not (normally) be considered for Technical Preview classification.
A datastore will be considered “Stable” if it meets the requirements of “Technical Preview” and a stable voting test suite is part of the gate.
A strategy will be considered “Stable” if it meets the requirements of “Experimental” and also has stable voting tests as part of the gate.
The plan is to edit all files required to reflect the change in location of some datastores and strategies.
The only other alternative is to have a webpage that lists this information without actually reorganizing the code.
Each datastore will have to be launched and verified for proper operation.
This will have a documentation impact and a bug will be opened for this.