<div dir="ltr"><div><div><div><div><div>I disagree. Guest should be able to do (for now two things):<br></div>1. Installing db, post-install configuration (dpkg reconfigure, etc.)<br></div>2. Allowing to apply outcome configuration in dictionary format.<br>
<br></div>As i mentioned earlier. There could be a problem with updating full config file. Reason is simple: post-configuration could take really custom database post-install configuration (taskmanager doesn't knew anything about that),<br>
</div>if taskamanger would do so - it would be a huge bug, because noone garanties you that database would work with default configuration (out-of-box).<br></div>To be precise, noone garanties that database will be in active state after simple "yum install" or "apt-get install". Simple example of post-install configuration: database would listen for requests on localhost.<br>
<br><div><div><div><div><div><div class="gmail_extra">Whole workflow of configuration parameters should take into accout config which already placed on the VM, not that one which lays at template on server-side.<br><br></div>
<div class="gmail_extra">As the beggining i suggest to make next flow:<br><div>1. Creating parameters group.</div><div>2. Validate and Save.</div><div>3. Send to an instance those parameters in dict representation.<br></div>
<div>4. Let manager decide how it should be processed (overrides.cnf, merging, etc.)<br></div><br></div><div class="gmail_extra">Any other flow would breake consistency of post-install configuration.<br><br></div><div class="gmail_extra">
Best regards, Denis M.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2013/11/25 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Denis,<div><br></div><div>I'm proposing that #3 and #4 sorta be swapped from your list where we merge the config group parameters into the main config and send down the file like we do now. So the guest does not need to handle the merging. The logic is the same just the location of the logic to merge be handled by the service rather than at the guest. </div>



<div><br></div><div>Most of the "merging" logic could be part of the jinja template we already have.</div><div><br></div><div>This will allow the guest to be agnostic of the type of config file and less logic in the guest.</div>
<span class=""><font color="#888888">
<div><br></div><div><br></div>

<div>-Craig</div><div><br></div><div><br></div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 1:19 PM, Denis Makogon <span dir="ltr"><<a href="mailto:dmakogon@mirantis.com" target="_blank">dmakogon@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I would like to see this functionality in the next way:<div>1. Creating parameters group.</div>
<div>2. Validate and Save.</div>
<div>3. Send to an instance those parameters in dict representation.</div><div>4. Merge into main config.</div>
<div><br></div><div>PS: #4 is database specific, so it's should be handled by manager.</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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div>We need to determine if we should not use a separate file for the overrides config as it might not be supported by all dbs trove supports. (works well for mysql but might not for cassandra as we discussed in the irc channel)</div>



<div><br></div><div>To support this for all dbs we could setup the jinja templates to add the configs to the end of the main config file (my.cnf for mysql example). </div><span><font color="#888888"><div><br>
</div><div><br></div><div>-Craig Vyvial</div>
</font></span></div>
<br></div></div>_______________________________________________<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></blockquote></div><br></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></blockquote></div><br></div>
</div></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></div></div></div></div></div></div>