<div dir="ltr"><div>These are some good q's.</div><div>responses inline <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 1:20 AM, 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">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></blockquote><div>The true default configuration group should be customized by a provider. This can be done via the jinja templates that are currently used.</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>
#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></blockquote><div>The user should be able to see what configurations they have overridden from the defaults. The user should be able to see the defaults by querying the db.</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>
#3 - Should a user be able to apply a different configuration-group on<br>
a master, than say, a slave?<br></blockquote><div>Yes they should be able to apply any configuration they want to each instance they own.</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>
#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></blockquote><div>The user should be capable of creating a configuration-group with any values they would like that are in bounds to the variable to be set.</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>
#5 - For GET /configuration/parameters, where is the list of supported<br>
parameters and their metadata sourced from?<br></blockquote><div>There is a config file that has all the options available to the user. This is sources and displayed via the GET call. </div><div>example of the file: <a href="https://gist.github.com/6796477">https://gist.github.com/6796477</a></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>
#6 - Should a user be able to reset a configuration-group to the<br>
current default configuration-group?<br></blockquote><div>A user should be able to reset the configuration-group to the "default" in the template and they can do this by unassigning the configuration to the instance.</div>
<div>There is a test case for this.</div><div><br></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>
#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></blockquote><div>A new configuration-group will be setting the override changes to the default my.cnf template.</div><div>We include the overrides.cnf directory location in the my.cnf</div><div>!includedir /etc/mysql/conf.d/</div>
<div>The overrides.cnf will be written with the changes to the configuration group and apply them dynamically if they can be, otherwise a restart will be required of the instance.</div><div><br></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>
#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></blockquote><div>All dynamic changes will be applied at the time they are either 1) applied to the configuration group that is tied to an instance or 2) when a configuration group is applied to an instance. If there are changes that cannot be dynamically set then we will change the state of the instance to RESTART_REQUIRED to apply the changes. </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>
#9 - Reminder: Once multiple service-types and versions are supported,<br>
the configuration-group will need a service-type field.<br></blockquote><div>Yes i agree with this and need a way of splitting the validation rules and making sure that we dont allow applying a configuration-group to different service types.</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>
#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></blockquote><div>I've thought about this but I do not this we should try to shoot for this right now.</div><div>I have some ideas similar to what you are describing but not sure i want to tackle this in the first iteration.</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>
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>
<div class="im"><br>
<br>
<br>
On 10/1/13 7:55 PM, "Michael Basnight" <<a href="mailto:mbasnight@gmail.com">mbasnight@gmail.com</a>> wrote:<br>
<br>
>On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:<br>
>><br>
>> So from this API, I see that a configuration is a standalone resource<br>
>>that could be applied to N number of instances. It's not clear to me<br>
>>what the API is for 'applying' a configuration to an existing instance.<br>
><br>
><a href="https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.2" target="_blank">https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.2</a><br>
>8PUT.29<br>
><br>
>> Also if we change a single item in a given configuration, does that<br>
>>change propagate to all instances that configuration belongs to?<br>
><br>
>Thats a good question. Maybe PATCH'ing a configuration is not a good<br>
>thing. We either have 1) drift between an attached config on an instance<br>
>vs the template, or 2) a confusing situation where we are potentially<br>
>updating configurations on running instances. Another possibility is that<br>
>a PATCH would in effect, clone the existing template, if its in use,<br>
>giving it a new UUID with the updated parameters. But im not sure i like<br>
</div>>that approach eitherŠ Its really not a PATCH at that point anyway id<br>
<div class="im">>think.<br>
><br>
>Blueprint designers, im looking to you for clarity.<br>
><br>
>> What about making 'configuration' a sub-resource of /instances?<br>
>><br>
>> Unless we think configurations will be common amongst instances for a<br>
>>given tenant, it may not make sense to make them high level resources.<br>
><br>
>As in /instances/configurations, or /instances/{id}/configurations ? I do<br>
>see commonality between a configuration and a bunch of instances, such<br>
>that a configuration is not unique to a single instance. I can see a<br>
>reseller having a tweaked out "works with _insert your favorite CMS<br>
>here_" template applied to all the instances they provision.<br>
><br>
<br>
<br>
</div><div class=""><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>