Craig, thanks for update. I'm going to re-review it tomorrow. Best regards, Denis Makogon.
2013/11/13 Craig Vyvial <cp16...@gmail.com> > I have updated the reviews related to configuration groups. > > Trove - https://review.openstack.org/#/c/53168/ > Python-TroveClient - https://review.openstack.org/#/c/53169/ > > Please review at your leisure. > > TODOs: > * add pagination support for configuration on instances > * mark configuration groups as deleted instead of doing a hard delete in > the db. > > > Thanks, > Craig Vyvial > > > On Thu, Oct 3, 2013 at 3:48 PM, Craig Vyvial <cp16...@gmail.com> wrote: > >> Oops forgot the link on BP for versioning templates. >> >> >> https://blueprints.launchpad.net/trove/+spec/configuration-templates-versionable >> >> >> On Thu, Oct 3, 2013 at 3:47 PM, Craig Vyvial <cp16...@gmail.com> wrote: >> >>> I have been trying to figure out where a call for the "default" >>> configuration should go. I just finished adding a method to get the >>> [mysqld] section via an api call but not sure where this should go yet. >>> >>> Currently i made it: >>> GET - /instance/{id}/configuration >>> >>> This kinda only half fits in the path here because it doesnt really >>> describe that this is the "default" configuration on the instance. On the >>> other hand, it shows that it is coupled to the instance because we need the >>> instance flavor to give what the current values are in the template applied >>> to the instance. >>> >>> Maybe other options could be: >>> GET - /instance/{id}/configuration/default >>> GET - /instance/{id}/defaultconfiguration >>> GET - /instance/{id}/default-configuration >>> GET - /configuration/default/instance/{id} >>> >>> Suggestions welcome on the path. >>> >>> There is some wonkiness showing this information to the user because of >>> the difference in the values used. [1] This example shows that the template >>> uses "50M" as a value applied and the configuration-group would apply the >>> value equivalent to 52428800. I dont think we should worry about this now >>> but this could lead to confusion by a user. If they are a power-user type >>> then they might understand compared to a entry level user. >>> >>> [1] https://gist.github.com/cp16net/6816691 >>> >>> >>> >>> On Thu, Oct 3, 2013 at 2:36 PM, McReynolds, Auston < >>> amcreyno...@ebay.com> wrote: >>> >>>> 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. >>>> >>> So this is a great point. There are talks about making the templating >>> versioned in some form or fashion. ekonetzk(irc) said he would write up a >>> BP around versioning. >>> >>> >>>> >>>> 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? >>>> >>> see above paragraph. >>> >>> >>>> >>>> >>>> >>>> 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 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 >>>> >>>> Hmmmm. 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 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? >>>> >>>> [1] >>>> >>>> http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html >>>> >>>> >>>> < >>>> http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.ht >>>> ml<http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html> >>>> < >>>> http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.htm >>>> l>> >>>> >>>> _______________________________________________ >>>> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
