Open Stack

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 <cp16net at 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 <dmakogon at 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 <cp16net at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/c9c1e3fd/attachment.html>