Trove/Blueprints/unify-common-code-in-guest-agent-variant-configuration
Contents
Description
There are going to be situations where there are many variants of a given data store. For example, in the "MySQL" category there are already MySQL (from Oracle), Percona Server, and MariaDB. Then there are going to be versions of these servers to contend with. The way the code is currently structured, most data stores will share some configuration options (and their values), and variants of a given data store would share some additional options (and maybe even their values). The present implementation results in a lot of duplicated code.
Justification/Benefits
It is never a good idea to have a lot of duplicated code. And when a bug fix requires an identical change in many places, it would be a good idea to consider rationalization.
For example, we see in review 80061 [1] that MySQL variants Percona and MySQL have many common options in [2].
In the near future, there is a plan to implement MariaDB. The current approach would cause us to copy the entire block of code for MariaDB.
Similarly one can see the kind of pain caused by this in [3] where we are actually duplicating code in chunks which is bound to lead to a maintenance issue down the road.
Use Case Requirements
This is mostly a matter or rationalizing the code. We (the developers and maintainers) are the customers of this change.
Scope
While it can be argued that this kind of rationalization could be done across the code base, this BP focuses on the configuration options. I believe it should affect
trove/common/cfg.py trove/guestagent/datastore/cassandra/options.py trove/guestagent/datastore/couchbase/options.py trove/guestagent/datastore/mongodb/options.py trove/guestagent/datastore/mysql/options.py and trove/guestagent/datastore/redis/options.py
I believe that it could be implemented (and I'm not going to be the one doing the implementation so I'll defer to SnowDust who has volunteered to do the implementation) as follows.
cfg.py should include the defaults that relate to the configuration of all guest agents. A file such as trove/guestagent/datastore/mysql/options.py could hold the options that are common to all mysql variants (but are different from other datastores). A file such as trove/guestagent/datastore/mysql/mariadb-options.py could hold the options that are common to all mariadb versions A file such as trove/guestagent/datastore/mysql/mariadb-5-5-options.py could hold the options that are specific to mariadb-5.5 (if that's the right version, maybe it should be 10 but whatever)
Impacts
This will impact the source files above (I believe).
Configuration
There should be no changes to configuration files required.
Database
- Does this impact any existing tables? If so, which ones?
No
- Are the changes forward and backward compatible?
No change
- Be sure to include the expected migration process
Not applicable
Public API
- Does this change any API that an end-user has access to?
- Are there any exceptions in terms of consistency with other APIs?
There is no change to the API
Internal API
- Does this change any internal messages between API and Task Manager or Task Manager to Guest
There should be (IMHO) no change to the internal API.
Guest Agent
- Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?
There should be no change to the behavior of the guest agent.