Migrating the python-django charm to Ansible

Michael Nelson michael.nelson at canonical.com
Thu Nov 6 01:03:03 UTC 2014

Hi Patrick,

On Thu, Nov 6, 2014 at 4:22 AM, Patrick Hetu <patrick.hetu at gmail.com> wrote:
> Since the last UDS, I'm trying to make the python-django charm evolve
> to use Ansible for is various tasks instead of using pure Python scripts.
> My previous attempt:
>   lp:~patrick-hetu/charms/precise/python-django/ansible
> had some problems so I decided to restart from scratch here (work in
> progress):
>   lp:~patrick-hetu/charms/precise/python-django/ansible_reboot
> Based on the following observations.
> Use roles that are not specific to Juju
> ---------------------------------------
> If you look at an Ansible role you will probably found a file
> defaults/main.yml or vars/main.yml. For me it was stunning how close
> those are to a charm configuration file.

Specifically, this is not the config.yaml you're talking about, but
the config file which is passed during deployment right? As in,
"myconfig.yaml" in:

juju deploy --config myconfig.yaml mycharm


> So why not grab this opportunity to use the same file
> (minus the charm name at the top [1]) with both Juju and Ansible
> and make Juju use the same roles that Ansible community are using by
> introducing
> shims in the charm playbook.

This should be possible without needing to re-use the actual file
itself - if I've understood correctly what you mean: any ansible-based
juju charm can reuse any community role for free, by using a shim to
set the roles expected variable names, based on the charm config?

So looking at the examples in your branch, if your charm has a config
option django-settings (and therefore playbook and templates have {{
django_settings }} available via the current helpers), while an
ansible-community django-project role expects a "settings_module"
variable, your example shim.yml does:

set_fact: shim_settings_module="{{ django_settings }}"

and then when you use the role, you pass in the the shim_settings_module:

    - role: django-project
        - install
      django_settings: "{{ shim_settings_module }}"

But I don't see the need for the shim at all, when you can just pass
the charm config value straight through:

      django_settings: "{{ django_settings }}

(or in the general case: django_settings: "{{ whatever_my_charm_config_uses }}")

I'm not sure whether I'm missing something about what you're meaning
(re-using the actual file), or whether you may have missed that all
the config is already available in the playbook/template contexts via
the existing charmhelper ansible support (unlikely, as you've used it
before I think). Let me know what I'm missing.

> [1] Using a configuration file without that charm name at the top
> was working in the past but now doesn't. Maybe this could be
> re-enable without to much negative impact.

That might be worth a juju bug. I assume it's related to the config
file being used generally to store config for multiple services within
your setup, but I don't see any reason why that should mean that if
the config file without the charm (service) name at the top is used
for deploying a single charm, that juju couldn't still accept it as
the config for that service.

> Couple the playbook with Juju with a shim
> -----------------------------------------
> To get the playbook to work with an external role we could use
> a shim file that translate Juju's dynamic configuration
> and relation data to roles variables.

Sounds great to be able to reuse existing external roles, but let me
know what I'm missing about why a shim is needed to do this.

> I was thinking using a shim imported in the pre_tasks section of
> the charm's playbook that runs on all tags.
> (see: https://github.com/ansible/ansible/issues/3157)
> The shim would do things like:
> * Translating Juju variable to role variable

That can be done in the playbook where needed as above.

> * Sanitize variable like: unit_name, relation_name, etc

That *should* be done by the existing charmhelpers (it writes out
/etc/ansible/host_vars/localhost on each hook execution with config,
relations and some other things like unit name, public and private

> * Ensure backward compatiblity
> Then using tags to dispatch based on the current relation
> to the corresponding roles.
> Build role for re-usability
> ---------------------------


> This have the potential to solve the problem of repetition of some
> high level tasks in other charm.
> Like adding ppa,

You can add PPAs with the existing apt_repository module (see the
example there):


> fetching source code, adding ssl certificate,
> configuring backup, etc
> A little bit like what charmhelper is doing right now.

Yes! I think making reusable roles for common tasks in juju charms is
really worthwhile [1]. We do have a bunch of public shareable roles
that Simon Davy and I (mainly) are reusing and improving for some
internal services [2]. Please take a look and see if there's things
that could be useful - but our use-case is a bit different (for
example, the payload role is because we are never pulling sourcecode
branches from external repositories during deployments, instead
pulling a built code asset from an internal swift container - although
there would be no reason why it couldn't be extended to support both).
Other roles may be useful (directories-and-permissions for listing
readonly/readwrite dirs, or wsgi-app for interfacing with the gunicorn

A typical charm which I write for a service these days only does two
things in addition to the re-used roles: installs any specific package
dependencies and writes out the specific settings/config file and
handle any other relations (elasticsearch/postgresql). I posted an
example a while back (uses an old version of the shared roles) [3].

Also, I know that Simon has a django shared role that he's about to
submit to charm-ansible-roles - it may be worth a look (Simon?), but
again, our use-case is a bit different as we're not attempting to
write one charm to deploy any django project right now (we did try in
the past, but found it was adding unreasonable complexity for us,
unless the projects being deployed were very similar).

Let me know about the shims!


[1] https://micknelson.wordpress.com/2014/06/10/reusable-ansible-roles-for-juju-charms/
[2] https://github.com/absoludity/charm-ansible-roles
[3] https://micknelson.wordpress.com/2014/06/25/a-walk-through-charming-an-existing-wsgi-application/

> I might not be clear so don't be afraid to ask clarification.
> I'm looking forward to receive your feedbacks
> Patrick
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju

More information about the Juju mailing list