<div dir="ltr">inline.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 1:03 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div>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.</div>
<div><br></div><div>When a configuration-group is removed the instance will return to the "default" state. This does not exactly act as a clone behavior.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>No User X does not get the changes. For User X to get the changes a maintenance may need to be scheduled. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If it's a "true" clone, User X should be isolated from a change in<br>
defaults, no?<br></blockquote><div>User X will not see these default changes until a new instance is created.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>If i understand this correctly my above statement means that its isolated by default.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>The default template will not be represented as a configuration group.</div><div>This could potentially be a good fit but its more of a nice to have type of feature.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
From: Craig Vyvial <<a href="mailto:cp16net@gmail.com" target="_blank">cp16net@gmail.com</a>><br>
<div>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: Wednesday, October 2, 2013 10:06 AM<br>
<div>To: OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</div>Subject: Re: [openstack-dev] [trove] Configuration API BP<br>
<div><div><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>
</div></div>i believe its a db tableŠ someone may have to correct me there.<br>
<div><div><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>
</div></div> <<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>
<div><div><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>
</div></div></blockquote></div><br></div></div>