inline.
On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston <[email protected]>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 <[email protected]> > Reply-To: OpenStack Development Mailing List > <[email protected]> > Date: Wednesday, October 2, 2013 10:06 AM > To: OpenStack Development Mailing List <[email protected] > > > 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" <[email protected]> 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> > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
