openstack/trove-specs
Code Issues Proposed changes

Update mysql manager refactor spec

Browse Source 
Based on discussion in Trove meeting on July 22, update
spec to discuss:

* Service class dependency injection
* Remove discussion of alternate reorg that was not pursued

Change-Id: I3bbe4ad9df776a66aa698e96486b5196ba84b6ed
Implements: bp/mysql-manager-refactor
This commit is contained in:
Alex Tomic 2015-07-29 15:59:03 -04:00
parent 3e63adf8c9
commit a489b36cf5
1 changed files with 16 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
specs/liberty/mysql-manager-refactor.rst
View File

@ -50,50 +50,11 @@ The crux of this blueprint is to move the majority of the existing MySQL
manager code into a new set of abstract classes, with stub subclasses for manager code into a new set of abstract classes, with stub subclasses for
MySQL, Percona and MariaDB datastores inheriting from them. MySQL, Percona and MariaDB datastores inheriting from them.
Due to the recent reorganization of datastores into a directory structure based **Maturity-Aware Reorganization**
on maturity, there are two alternatives that we have considered.
**Maturity-Agnostic** The base mysql code will reside in the current mysql datastore directory.
The first alternative is for base, inherited code to be agnostic of maturity.
This would result in This would result in
* The creation of a ``trove/guestagent/datastore/base`` directory, that would
contain a directory with abstract classes for each "base" system. For now,
this would be only MySQL, but in the future could also include systems with
a number of variants/forks such as PostgreSQL.
* The majority of the current MySQL datastore code moving to
``trove/guestagent/datastore/base/mysql`` , but the classes made abstract.
* The existing MySQL datastore classes remaining where they are, but largely
replaced with stub implementations that inherit from the new base classes.
The resulting file and directory structure would change from::
trove/guestagent/datastore/mysql/manager.py
trove/guestagent/datastore/mysql/service.py
to::
trove/guestagent/datastore/base/mysql/manager.py
trove/guestagent/datastore/base/mysql/service.py
trove/guestagent/datastore/mysql/manager.py
trove/guestagent/datastore/mysql/service.py
trove/guestagent/datastore/experimental/mariadb/manager.py
trove/guestagent/datastore/experimental/mariadb/service.py
trove/guestagent/datastore/experimental/percona/manager.py
trove/guestagent/datastore/experimental/percona/service.py
The benefit of this approach is a clean separation of the abstract code common
to variants of a datastore and the datastore implementations themselves. A
drawback is that it fits somewhat awkwardly with our maturity-based
reorganization, especially if a future base system has only experimental
datastores as subclasses.
**Maturity-Aware**
The second alternative is for the base mysql code to reside in the current
mysql datastore directory. This would result in
* The creation of new base implementations for the manager and service * The creation of new base implementations for the manager and service
modules in the ``trove/guestagent/datastore/mysql`` directory modules in the ``trove/guestagent/datastore/mysql`` directory
* The creation of explicit datastores for Percona and MariaDB with * The creation of explicit datastores for Percona and MariaDB with
@ -120,13 +81,24 @@ This approach has the benefit of less potential confusion about the maturity
level of the base code. However, it is not as not as clean an organization: level of the base code. However, it is not as not as clean an organization:
MySQL CE is treated as both a base system and an implementing datastore. MySQL CE is treated as both a base system and an implementing datastore.
In both cases, a pass through the MySQL manager code would be done to identify A pass through the MySQL manager code will be done to identify methods that
methods that should be made abstract. These methods would then be brought should be made abstract. These methods would then be brought "down" into the
"down" into the subclasses. subclasses.
This blueprint does *not* attempt to create optimized MariaDB or Percona This blueprint does *not* attempt to create optimized MariaDB or Percona
datastores, but rather to lay the groundwork for their creation. datastores, but rather to lay the groundwork for their creation.
**Service class dependency injection**
The service.py module contains a number of classes, such as MySqlAppStatus,
that are used in the manager.py module. These are currently tightly coupled:
the mysql manager has an explicit import for each.
The make it possible to extend these classes arbitrarily for different
datastores, and eliminate the tight-coupling, the old references will be
refactored into class properties, which are to be injected by the concrete
manager class.
**Strategy consolidation** **Strategy consolidation**
Currently not included in the scope of this refactor, but an important future Currently not included in the scope of this refactor, but an important future