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