Re: [openstack-dev] [Trove] Core reviewer update
+1 welcome aboard peter + victoria + edmond! From: Nikhil Manchanda slick...@gmail.commailto:slick...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 5, 2015 at 8:26 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Trove] Core reviewer update Hello Trove folks: Keeping in line with other OpenStack projects, and attempting to keep the momentum of reviews in Trove going, we need to keep our core-team up to date -- folks who are regularly doing good reviews on the code should be brought in to core and folks whose involvement is dropping off should be considered for removal since they lose context over time, not being as involved. For this update I'm proposing the following changes: - Adding Peter Stachowski (peterstac) to trove-core - Adding Victoria Martinez De La Cruz (vkmc) to trove-core - Adding Edmond Kotowski (edmondk) to trove-core - Removing Michael Basnight (hub_cap) from trove-core - Removing Tim Simpson (grapex) from trove-core For context on Trove reviews and who has been active, please see Russell's stats for Trove at: - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt Trove-core members -- please reply with your vote on each of these proposed changes to the core team. Peter, Victoria and Eddie -- please let me know of your willingness to be in trove-core. Michael, and Tim -- if you are planning on being substantially active on Trove in the near term, also please do let me know. Thanks, Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core
+1 On 8/26/14, 6:54 AM, Tim Simpson tim.simp...@rackspace.com wrote: +1 From: Sergey Gotliv [sgot...@redhat.com] Sent: Tuesday, August 26, 2014 8:11 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core Strong +1 from me! -Original Message- From: Nikhil Manchanda [mailto:nik...@manchanda.me] Sent: August-26-14 3:48 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core Hello folks: I'm proposing to add Amrith Kumar (amrith on IRC) to trove-core. Amrith has been working with Trove for a while now. He has been a consistently active reviewer, and has provided insightful comments on numerous reviews. He has submitted quality code for multiple bug-fixes in Trove, and most recently drove the audit and clean-up of log messages across all Trove components. https://review.openstack.org/#/q/reviewer:amrith,n,z https://review.openstack.org/#/q/owner:amrith,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Craig Vyvial to trove-core
+1 On 5/6/14, 2:31 AM, Nikhil Manchanda nik...@manchanda.me wrote: Hello folks: I'm proposing to add Craig Vyvial (cp16net) to trove-core. Craig has been working with Trove for a while now. He has been a consistently active reviewer, and has provided insightful comments on numerous reviews. He has submitted quality code to multiple features in Trove, and most recently drove the implementation of configuration groups in Icehouse. https://review.openstack.org/#/q/reviewer:%22Craig+Vyvial%22,n,z https://review.openstack.org/#/q/owner:%22Craig+Vyvial%22,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] configuration groups and datastores type/versions
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 cp16...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Wednesday, December 11, 2013 8:52 AM To: OpenStack Development Mailing List openstack-dev@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
[openstack-dev] [trove] Datastore Type/Version Migration
With Multiple Datastore Types/Versions merged to master, the conversation around how to support migrating from one datastore version to another has begun. Please see https://gist.github.com/amcrn/dfd493200fcdfdb61a23 for a consolidation of thoughts thus far. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Design Summit Etherpads
In lieu of being able to be there in person, I've included my thoughts on the clustering blueprint @ https://etherpad.openstack.org/p/TroveReplicationClustering Thanks, Auston On 10/29/13 12:38 AM, Nikhil Manchanda nik...@manchanda.me wrote: The list of Etherpads for the design summit sessions for Trove is now posted at: https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Trove Feel free to add any relevant notes to the Etherpads. Thanks, Cheers, -Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] Configuration API BP
If User X's existing instance is isolated from the change, but there's no snapshot/clone/versioning of the current settings on X's instance (via the trove database or jinja template), then how will GET /configurations/:id return the correct/current settings? Unless you're planning on communicating with the guest? There's nothing wrong with that approach, it's just not explicitly noted anywhere in the blueprint. For some reason I inferred that it would be handled like trove security-groups. On a slightly different note: If the default template will not be represented as a default configuration-group from an api standpoint, then how will you support the ability for a user to enumerate the list of default configuration-group values for a service-type? GET /configurations/:id won't be applicable, so will it be something like GET /configurations/default? From: Craig Vyvial cp16...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Thursday, October 3, 2013 11:17 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove] Configuration API BP inline. On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston amcreyno...@ebay.com wrote: Awesome! I only have one follow-up question: Regarding #6 #7, how will the clone behavior work given that the defaults are hydrated by a non-versioned jinja template? I am not sure i understand clone behavior because there is not really a concept of cloning here. The jinja template is created and passed in the prepare call to the guest to write to the default my.cnf file. When a configuration-group is removed the instance will return to the default state. This does not exactly act as a clone behavior. Scenario Timeline: T1) Cloud provider begins with the default jinja template, but changes the values for properties 'a' and 'b'. (Template Version #1) T2) User X deploys a database instance T3) Cloud provider decides to update the existing template by modifying property 'c'. (Template Version #2) T4) User Z deploys a database instance I think it goes without saying that User Z's instance gets Template Version #2 (w/ changes to a b c), but does User X? No User X does not get the changes. For User X to get the changes a maintenance may need to be scheduled. If it's a true clone, User X should be isolated from a change in defaults, no? User X will not see these default changes until a new instance is created. Come to think about it, this is eerily similar to security-groups: administratively, it can be beneficial to share a configuration/security-group across multiple instances, but it can also be a nightmare. Internally, it's extremely rare that we wish to apply a database change to multiple tenants at once, so I'd argue at a minimum to support a CONF opt-in for isolation, if not default to it. If i understand this correctly my above statement means that its isolated by default. On a related note: Will the default template for a service-type be represented as a default configuration-group? If so, I imagine it can be managed through the API (or MGMT API)? The default template will not be represented as a configuration group. This could potentially be a good fit but its more of a nice to have type of feature. From: Craig Vyvial cp16...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Wednesday, October 2, 2013 10:06 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove] Configuration API BP I'm glad we both agree on most of these answers. :) On Oct 2, 2013 11:57 AM, Michael Basnight mbasni...@gmail.com wrote: On Oct 1, 2013, at 11:20 PM, McReynolds, Auston wrote: I have a few questions left unanswered by the blueprint/wiki: #1 - Should the true default configuration-group for a service-type be customizable by the cloud provider? Yes #2 - Should a user be able to enumerate the entire actualized/realized set of values for a configuration-group, or just the overrides? actualized #3 - Should a user be able to apply a different configuration-group on a master, than say, a slave? Yes #4 - If a user creates a new configuration-group with values equal to that of the default configuration-group, what is the expected behavior? Im not sure thats an issue. You will select your config group, and it will be the one used. I believe you are talking the difference between the template thats used to set up values for the instance, and the config options that users are allowed to edit. Those are going to be appended, so to speak, to the existing template. Itll be up to the server software to define what order values, if duplicated, are read / used. #5 - For GET /configuration/parameters, where is the list of supported parameters and their metadata sourced from? i believe
Re: [openstack-dev] [trove] Configuration API BP
I have a few questions left unanswered by the blueprint/wiki:
#1 - Should the true default configuration-group for a service-type be
customizable by the cloud provider?
#2 - Should a user be able to enumerate the entire actualized/realized
set of values for a configuration-group, or just the overrides?
#3 - Should a user be able to apply a different configuration-group on
a master, than say, a slave?
#4 - If a user creates a new configuration-group with values equal to
that of the default configuration-group, what is the expected
behavior?
#5 - For GET /configuration/parameters, where is the list of supported
parameters and their metadata sourced from?
#6 - Should a user be able to reset a configuration-group to the
current default configuration-group?
#7 - Is a new configuration-group a clone of the then current default
configuration-group with various changes, or will inheritence be
utilized?
#8 - How should the state of pending configuration-group changes be
reflected in GET /instances/:id ? How will this state be
persisted?
#9 - Reminder: Once multiple service-types and versions are supported,
the configuration-group will need a service-type field.
#10 - Should dynamic values (via functions and operators) in
configuration-groups be supported?
Example: innodb_buffer_pool_size = 150 * flavor['ram']/512
My Thoughts:
#1 - Yes
#2 - Actualized
#3 - Yes
#4 - Depends on whether the approach for configuration-groups is to
clone or to inherit.
#5 - ?
#6 - Yes
#7 - ?
#8 - ?
#9 - N/A
#10 - In the first iteration of this feature I don't think it's an
absolute necessity, but it's definitely a nice-to-have. The
design/implementation should not preclude this from being easily
added in the future.
Where ? == I'd like to think about it a bit more, but I have a gut
feeling
Thoughts?
On 10/1/13 7:55 PM, Michael Basnight mbasni...@gmail.com wrote:
On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:
So from this API, I see that a configuration is a standalone resource
that could be applied to N number of instances. It's not clear to me
what the API is for 'applying' a configuration to an existing instance.
https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.2
8PUT.29
Also if we change a single item in a given configuration, does that
change propagate to all instances that configuration belongs to?
Thats a good question. Maybe PATCH'ing a configuration is not a good
thing. We either have 1) drift between an attached config on an instance
vs the template, or 2) a confusing situation where we are potentially
updating configurations on running instances. Another possibility is that
a PATCH would in effect, clone the existing template, if its in use,
giving it a new UUID with the updated parameters. But im not sure i like
that approach eitherŠ Its really not a PATCH at that point anyway id
think.
Blueprint designers, im looking to you for clarity.
What about making 'configuration' a sub-resource of /instances?
Unless we think configurations will be common amongst instances for a
given tenant, it may not make sense to make them high level resources.
As in /instances/configurations, or /instances/{id}/configurations ? I do
see commonality between a configuration and a bunch of instances, such
that a configuration is not unique to a single instance. I can see a
reseller having a tweaked out works with _insert your favorite CMS
here_ template applied to all the instances they provision.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] Configuration API BP
Awesome! I only have one follow-up question: Regarding #6 #7, how will the clone behavior work given that the defaults are hydrated by a non-versioned jinja template? Scenario Timeline: T1) Cloud provider begins with the default jinja template, but changes the values for properties 'a' and 'b'. (Template Version #1) T2) User X deploys a database instance T3) Cloud provider decides to update the existing template by modifying property 'c'. (Template Version #2) T4) User Z deploys a database instance I think it goes without saying that User Z's instance gets Template Version #2 (w/ changes to a b c), but does User X? If it's a true clone, User X should be isolated from a change in defaults, no? Come to think about it, this is eerily similar to security-groups: administratively, it can be beneficial to share a configuration/security-group across multiple instances, but it can also be a nightmare. Internally, it's extremely rare that we wish to apply a database change to multiple tenants at once, so I'd argue at a minimum to support a CONF opt-in for isolation, if not default to it. On a related note: Will the default template for a service-type be represented as a default configuration-group? If so, I imagine it can be managed through the API (or MGMT API)? From: Craig Vyvial cp16...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Wednesday, October 2, 2013 10:06 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove] Configuration API BP I'm glad we both agree on most of these answers. :) On Oct 2, 2013 11:57 AM, Michael Basnight mbasni...@gmail.com wrote: On Oct 1, 2013, at 11:20 PM, McReynolds, Auston wrote: I have a few questions left unanswered by the blueprint/wiki: #1 - Should the true default configuration-group for a service-type be customizable by the cloud provider? Yes #2 - Should a user be able to enumerate the entire actualized/realized set of values for a configuration-group, or just the overrides? actualized #3 - Should a user be able to apply a different configuration-group on a master, than say, a slave? Yes #4 - If a user creates a new configuration-group with values equal to that of the default configuration-group, what is the expected behavior? Im not sure thats an issue. You will select your config group, and it will be the one used. I believe you are talking the difference between the template thats used to set up values for the instance, and the config options that users are allowed to edit. Those are going to be appended, so to speak, to the existing template. Itll be up to the server software to define what order values, if duplicated, are read / used. #5 - For GET /configuration/parameters, where is the list of supported parameters and their metadata sourced from? i believe its a db tableŠ someone may have to correct me there. #6 - Should a user be able to reset a configuration-group to the current default configuration-group? Yes, assuming we have a default config group, and im not sure we have a concept of that. We have what the install creates, the templated config file. Removing the association of your config from the instance will do this thought. #7 - Is a new configuration-group a clone of the then current default configuration-group with various changes, or will inheritence be utilized? I think clone will be saner for now. But you can edit your group with a PATCH, and that will not clone it. See [1] first paragraph. #8 - How should the state of pending configuration-group changes be reflected in GET /instances/:id ? How will this state be persisted? You are talking about changes that require a restart i believe. I think this falls into the same category as our conversation about minor version updates. We can have a pretty generic restart required somewhere there. #9 - Reminder: Once multiple service-types and versions are supported, the configuration-group will need a service-type field. Most def. You will only be able to assign relevant configs to their service-types, and the /configuration/parameters will need to be typed too. #10 - Should dynamic values (via functions and operators) in configuration-groups be supported? Example: innodb_buffer_pool_size = 150 * flavor['ram']/512 H. This is quite interesting. But no, not v1. I totally agree w/ the nice-to-have. Good idea though, we should add it to the blueprint. My Thoughts: #1 - Yes #2 - Actualized #3 - Yes #4 - Depends on whether the approach for configuration-groups is to clone or to inherit. #5 - ? #6 - Yes #7 - ? #8 - ? #9 - N/A #10 - In the first iteration of this feature I don't think it's an absolute necessity, but it's definitely a nice-to-have. The design/implementation
