On 9 September 2014 18:45, Sebastian <[email protected]> wrote: > Hey Simon! > > For example, imagine you have an Ansible charm which inside are some php > settings applied like php memory limit, and then you relate a subordinated > charm to it, that creates a new php.ini with custom configurations that the > project needs. > > If the playbook of the subordinated charm makes a move that doesn't count > with files or configurations generated by the other playbook in the main > service charm, probably will result in a conflict, and errors will be shown.
This seems to me more like a problem of conflicting on a single file, which is a problem for any subordinate, not specifically an ansible one. As I'm sure you know, it is generally better to use a directory of config files that are included from the main config file, so different things can "own" different files, and not conflict. Many tools support this OOTB. However, if you can't have includes in a the main php.ini file, then ansible can actually help you with this somewhat, all though in limited fashion. Check out the lineinfile module: http://docs.ansible.com/lineinfile_module.html > I was thinking in how to avoid this, leaving less customized configurations > in the main charm. But!, it's difficult to know where's the limit. Yeah, so getting the right responsibilities between subordinates/principles can be quite nuanced. A good example IMO is the gunicorn subordinate for running python applications. All configuration is done via the relation to the subordinate, and the subordinate owns the gunicorn config completely (going so far as to disable the debian sysv init packaging as it's quite limited). So the responsibilities are clearly divided. That may not be possible in your scenario, of course[1]. But it's easy for a principle charm to touch a file it really shouldn't be doing. We had some gunicorn using principle charms that invoked "/etc/init.d/gunicorn restart" directly, which was a real pain when we wanted to change how gunicorn was run. One further idea: pass your extra config to the subordinate (or vice versa) as a string in the relation data, and have the subordinate include that config in the generated php.ini. Not the cleanest solution, but it could work. Or even better, expose all the knobs you want to configure in the relation data, and allow them to be set by the principle (with sane defaults). This is what the gunicorn subordinate does, fyi. HTH [1] I know very little about modern[2] php deployment [2] I can probably help with PHP 3, though ;P -- Simon -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
