<div dir="ltr">Craig, thanks for update. I'm going to re-review it tomorrow.<div><br></div><div>Best regards, Denis Makogon.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/13 Craig Vyvial <span dir="ltr"><<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have updated the reviews related to configuration groups.<div><br></div><div>Trove - <a href="https://review.openstack.org/#/c/53168/" target="_blank">https://review.openstack.org/#/c/53168/</a></div>
<div>Python-TroveClient - <a href="https://review.openstack.org/#/c/53169/" target="_blank">https://review.openstack.org/#/c/53169/</a></div>
<div><br></div><div>Please review at your leisure.</div><div><br></div><div>TODOs:</div><div>* add pagination support for configuration on instances</div><div>* mark configuration groups as deleted instead of doing a hard delete in the db.</div>
<div><br></div><div><br></div><div>Thanks,<br>Craig Vyvial</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 3, 2013 at 3:48 PM, Craig Vyvial <span dir="ltr"><<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Oops forgot the link on BP for versioning templates.</div><div><br><div><a href="https://blueprints.launchpad.net/trove/+spec/configuration-templates-versionable" target="_blank">https://blueprints.launchpad.net/trove/+spec/configuration-templates-versionable</a><br>
</div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 3, 2013 at 3:47 PM, Craig Vyvial <span dir="ltr"><<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>
<br></div><div>Currently i made it:</div><div>GET - /instance/{id}/configuration</div><div><br></div><div>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.</div>
<div><br></div><div>Maybe other options could be:</div><div>GET - /instance/{id}/configuration/default<br></div><div>GET - /instance/{id}/defaultconfiguration<br></div><div>GET - /instance/{id}/default-configuration<br></div>
<div>GET - /configuration/default/instance/{id}</div><div><br></div><div>Suggestions welcome on the path.</div><div><br></div><div>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.</div>
<div><br></div><div>[1] <a href="https://gist.github.com/cp16net/6816691" target="_blank">https://gist.github.com/cp16net/6816691</a><br></div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br>
<div class="gmail_quote"><div>
On Thu, Oct 3, 2013 at 2:36 PM, McReynolds, Auston <span dir="ltr"><<a href="mailto:amcreynolds@ebay.com" target="_blank">amcreynolds@ebay.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If User X's existing instance is isolated from the change, but there's<br>
no snapshot/clone/versioning of the current settings on X's instance<br>
(via the trove database or jinja template), then how will<br>
GET /configurations/:id return the correct/current settings? Unless<br>
you're planning on communicating with the guest? There's nothing<br>
wrong with that approach, it's just not explicitly noted anywhere in<br>
the blueprint. For some reason I inferred that it would be handled<br>
like trove security-groups.<br></blockquote></div><div>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.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On a slightly different note: If the default template will not be<br>
represented as a default configuration-group from an api standpoint,<br>
then how will you support the ability for a user to enumerate the list<br>
of default configuration-group values for a service-type?<br>
GET /configurations/:id won't be applicable, so will it be<br>
something like GET /configurations/default?<br></blockquote></div><div>see above paragraph.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
<br>
<br>
From: Craig Vyvial <<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>><br>
Reply-To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</div>Date: Thursday, October 3, 2013 11:17 AM<br>
<div><div>To: OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [trove] Configuration API BP<br>
<br>
<br>
inline.<br>
<br>
<br>
On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston<br>
<<a href="mailto:amcreynolds@ebay.com" target="_blank">amcreynolds@ebay.com</a>> wrote:<br>
<br>
Awesome! I only have one follow-up question:<br>
<br>
Regarding #6 & #7, how will the clone behavior work given that the<br>
defaults are hydrated by a non-versioned jinja template?<br>
<br>
<br>
I am not sure i understand "clone behavior" because there is not really a<br>
concept of cloning here. The jinja template is created and passed in the<br>
"prepare call" to the guest to write to the default my.cnf file.<br>
<br>
When a configuration-group is removed the instance will return to the<br>
"default" state. This does not exactly act as a clone behavior.<br>
<br>
<br>
<br>
Scenario Timeline:<br>
<br>
T1) Cloud provider begins with the default jinja template, but changes<br>
the values for properties 'a' and 'b'. (Template Version #1)<br>
T2) User X deploys a database instance<br>
T3) Cloud provider decides to update the existing template by modifying<br>
property 'c'. (Template Version #2)<br>
T4) User Z deploys a database instance<br>
<br>
I think it goes without saying that User Z's instance gets Template<br>
Version #2 (w/ changes to a & b & c), but does User X?<br>
<br>
<br>
No User X does not get the changes. For User X to get the changes a<br>
maintenance may need to be scheduled.<br>
<br>
<br>
<br>
If it's a "true" clone, User X should be isolated from a change in<br>
defaults, no?<br>
<br>
<br>
User X will not see these default changes until a new instance is created.<br>
<br>
<br>
<br>
Come to think about it, this is eerily similar to security-groups:<br>
administratively, it can be beneficial to share a<br>
configuration/security-group across multiple instances, but it can<br>
also be a nightmare. Internally, it's extremely rare that we wish to<br>
apply a database change to multiple tenants at once, so I'd argue<br>
at a minimum to support a CONF opt-in for isolation, if not default<br>
to it.<br>
<br>
<br>
If i understand this correctly my above statement means that its isolated<br>
by default.<br>
<br>
<br>
<br>
On a related note: Will the default template for a service-type be<br>
represented as a default configuration-group? If so, I imagine it<br>
can be managed through the API (or MGMT API)?<br>
<br>
<br>
The default template will not be represented as a configuration group.<br>
This could potentially be a good fit but its more of a nice to have type<br>
of feature.<br>
<br>
<br>
<br>
<br>
From: Craig Vyvial <<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>><br>
Reply-To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<br>
Date: Wednesday, October 2, 2013 10:06 AM<br>
To: OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<br>
Subject: Re: [openstack-dev] [trove] Configuration API BP<br>
<br>
<br>
I'm glad we both agree on most of these answers.<br>
:)<br>
<br>
On Oct 2, 2013 11:57 AM, "Michael Basnight" <<a href="mailto:mbasnight@gmail.com" target="_blank">mbasnight@gmail.com</a>> wrote:<br>
<br>
On Oct 1, 2013, at 11:20 PM, McReynolds, Auston wrote:<br>
<br>
> I have a few questions left unanswered by the blueprint/wiki:<br>
><br>
> #1 - Should the true default configuration-group for a service-type be<br>
> customizable by the cloud provider?<br>
<br>
Yes<br>
<br>
><br>
> #2 - Should a user be able to enumerate the entire actualized/realized<br>
> set of values for a configuration-group, or just the overrides?<br>
<br>
actualized<br>
<br>
><br>
> #3 - Should a user be able to apply a different configuration-group on<br>
> a master, than say, a slave?<br>
<br>
Yes<br>
<br>
><br>
> #4 - If a user creates a new configuration-group with values equal to<br>
> that of the default configuration-group, what is the expected<br>
> behavior?<br>
<br>
Im not sure thats an issue. You will select your config group, and it will<br>
be the one used. I believe you are talking the difference between the<br>
"template" thats used to set up values for the instance, and the config<br>
options that users are allowed to edit.<br>
Those are going to be "appended", so to speak, to the existing template.<br>
Itll be up to the server software to define what order values, if<br>
duplicated, are read / used.<br>
<br>
><br>
> #5 - For GET /configuration/parameters, where is the list of supported<br>
> parameters and their metadata sourced from?<br>
<br>
<br>
<br>
i believe its a db tableŠ someone may have to correct me there.<br>
<br>
><br>
> #6 - Should a user be able to reset a configuration-group to the<br>
> current default configuration-group?<br>
<br>
Yes, assuming we have a "default config group", and im not sure we have a<br>
concept of that. We have what the install creates, the templated config<br>
file. Removing the association of your config from the instance will do<br>
this thought.<br>
<br>
><br>
> #7 - Is a new configuration-group a clone of the then current default<br>
> configuration-group with various changes, or will inheritence be<br>
> utilized?<br>
<br>
I think clone will be saner for now. But you can edit your group with a<br>
PATCH, and that will not clone it. See [1] first paragraph.<br>
<br>
><br>
> #8 - How should the state of pending configuration-group changes be<br>
> reflected in GET /instances/:id ? How will this state be<br>
> persisted?<br>
<br>
You are talking about changes that require a restart i believe. I think<br>
this falls into the same category as our conversation about minor version<br>
updates. We can have a pretty generic "restart required" somewhere there.<br>
<br>
><br>
> #9 - Reminder: Once multiple service-types and versions are supported,<br>
> the configuration-group will need a service-type field.<br>
<br>
Most def. You will only be able to assign relevant configs to their<br>
service-types, and the /configuration/parameters will need to be typed too.<br>
<br>
><br>
> #10 - Should dynamic values (via functions and operators) in<br>
> configuration-groups be supported?<br>
> Example: innodb_buffer_pool_size = 150 * flavor['ram']/512<br>
<br>
Hmmmm. This is quite interesting. But no, not v1. I totally agree w/ the<br>
nice-to-have. Good idea though, we should add it to the blueprint.<br>
<br>
><br>
> My Thoughts:<br>
><br>
> #1 - Yes<br>
> #2 - Actualized<br>
> #3 - Yes<br>
> #4 - Depends on whether the approach for configuration-groups is to<br>
> clone or to inherit.<br>
> #5 - ?<br>
> #6 - Yes<br>
> #7 - ?<br>
> #8 - ?<br>
> #9 - N/A<br>
> #10 - In the first iteration of this feature I don't think it's an<br>
> absolute necessity, but it's definitely a nice-to-have. The<br>
> design/implementation should not preclude this from being easily<br>
> added in the future.<br>
><br>
> Where "?" == "I'd like to think about it a bit more, but I have a gut<br>
> feeling"<br>
><br>
> Thoughts?<br>
<br>
[1]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html</a><br>
<br>
<br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.ht<br>
ml</a><br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.htm" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.htm</a><br>
l>><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>