I disagree. Guest should be able to do (for now two things): 1. Installing db, post-install configuration (dpkg reconfigure, etc.) 2. Allowing to apply outcome configuration in dictionary format.
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), 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). 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. 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. As the beggining i suggest to make next flow: 1. Creating parameters group. 2. Validate and Save. 3. Send to an instance those parameters in dict representation. 4. Let manager decide how it should be processed (overrides.cnf, merging, etc.) Any other flow would breake consistency of post-install configuration. Best regards, Denis M. 2013/11/25 Craig Vyvial <cp16...@gmail.com> > Denis, > > 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. > > Most of the "merging" logic could be part of the jinja template we already > have. > > This will allow the guest to be agnostic of the type of config file and > less logic in the guest. > > > -Craig > > > > > On Wed, Nov 13, 2013 at 1:19 PM, Denis Makogon <dmako...@mirantis.com>wrote: > >> I would like to see this functionality in the next way: >> 1. Creating parameters group. >> 2. Validate and Save. >> 3. Send to an instance those parameters in dict representation. >> 4. Merge into main config. >> >> PS: #4 is database specific, so it's should be handled by manager. >> >> >> 2013/11/13 Craig Vyvial <cp16...@gmail.com> >> >>> 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) >>> >>> 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). >>> >>> >>> -Craig Vyvial >>> >>> _______________________________________________ >>> 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
