Open Stack

Another Example:

  Datastore Type | Version
  -------------------------------------
  MySQL 5.5          | 5.5.35
  MySQL 5.5          | 5.5.20
  MySQL 5.6          | 5.6.15
  ------------------------------------

A user creates a MySQL 5.5 configuration-group that merely consists
of a innodb_buffer_pool_size override. The innodb_buffer_pool_size
parameter is still featured in MySQL 5.6, so arguably the
configuration-group should work with MySQL 5.6 as well. If a
configuration-group can only be tied to a single datastore type
and/or a single datastore-version, this will not work.

To support all possible permutations, a "compatibility" list of sorts
has to be introduced.

Table: configuration_datastore_compatibility

  Name                    | Description
  ------------------------------------------------------------------
  id                            | PrimaryKey, Generated UUID
  from_version_id | ForeignKey(datastore_version.id)
  to_version_id      | ForeignKey(datastore_version.id)

The cloud provider can then be responsible for updating the
compatibility table (via trove-manage) whenever a new version of a
datastore is introduced and has a strict superset of configuration
parameters as compared to previous versions.

On a related note, it would probably behoove us to consider how to
handle datastore migrations in relation to configuration-groups.
A rough-draft blueprint/gist for datastore migrations is located at
https://gist.github.com/amcrn/dfd493200fcdfdb61a23.


Auston

---------------------------------------------------

From:  Craig Vyvial <cp16net at gmail.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date:  Wednesday, December 11, 2013 8:52 AM
To:  OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject:  [openstack-dev] [trove] configuration groups and
datastores	type/versions


Configuration Groups is currently developed to associate the datastore
version with a configuration that is created. If a datastore version is
not presented it will use the default similar to the way instances are
created now. This looks like
 a way of associating the configuration with a datastore because an
instance has this same association.

Depending on how you setup your datastore types and versions this might
not be ideal.
Example:
Datastore Type | Version
-------------------------
Mysql          | 5.1
Mysql          | 5.5

Percona        | 5.5
-------------------------

Configuration      | datastore_version
-----------------------------------
mysql-5.5-config   | mysql 5.5

percona-5.5-config | percona 5.5

-----------------------------------

or 

Datastore Type | Version
-------------------------
Mysql 5.1      | 5.1.12
Mysql 5.1      | 5.1.13

Mysql          | 5.5.32

Percona        | 5.5.44
-------------------------


Configuration      | datastore_version
-----------------------------------
mysql-5.1-config   | mysql 5.5

percona-5.5-config | percona 5.5

-----------------------------------



Notice that if you associate the configuration with a datastore version
then in the latter example you will not be able to use the same
configurations that you created with different minor versions of the
datastore. 

Something that we should consider is allowing a configuration to be
associated with a just a datastore type (eg. Mysql 5.1) so that any
versions of 5.1 should allow the same configuration to be applied.

I do not view this as a change that needs to happen before the current
code is merged but more as an additive feature of configurations.


*snippet from Morris and I talking about this*
Given the nature of how the datastore / types code has been implemented in
that it is highly configurable, I believe that we we need to adjust the
way in which we are associating configuration groups with datastore types
and versions.  The main
 use case that I am considering here is that as a user of the API, I want
to be able to associate configurations with a specific datastore type so
that I can easily return a list of the configurations that are valid for
that database type (Example: Get me a
 list of configurations for MySQL 5.6).   We know that configurations will
vary across types (MySQL vs. Redis) as well as across major versions
(MySQL 5.1 vs MySQL 5.6).   Presently, the code only keys off the
datastore version, and consequently, if I were
 to set up my datastore type as MySQL X.X and datastore versions as X.X.X,
then you would be potentially associating a configuration with a specific
minor version such as MySQL 5.1.63.    Given then, I am thinking that it
makes more sense to allow a configuration
 to be associated with both a datastore type AND and datastore version
with precedence given to the datastore type (where both attributes are
either optional ­ or at least one is required).  This would give the most
flexibility to associate configurations with
 either the type, version, or both and would allow it to work across
providers given that they are likely to configure types/versions
differently.

I'd like to hear how the community views this and bring up the
conversation now rather than later.

Thanks,
-Craig Vyvial