Call for Charm School topics

Simon Davy bloodearnest at gmail.com
Tue Sep 9 18:52:27 UTC 2014


On 9 September 2014 18:45, Sebastian <sebas5384 at gmail.com> 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



More information about the Juju mailing list