Open Stack

Good point...

In this case however, couldn't you solve this by simply allowing the user
to specify a list of multiple id's for both the datastore-id's and
datastore-version-id's?  That way the user can directly control which
configurations apply to different types and versions (choosing to apply
0,1, or many).  I am not sure how the provider would be able to directly
manage those on behalf of the user as they would not know which options
actually apply across the different types and versions (unless that too
was maintained).  I could be misunderstanding your proposal though.

Daniel







On 12/12/13 6:02 PM, "McReynolds, Auston" <amcreynolds at ebay.com> wrote:

>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
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev