> Let me know about the shims! Well, I've just tested and it looks like it was fixed in Ansible 1.7 at least for host_vars/... So much cleaner code to come!
Also, let met know what your thinking about the changes I propose on how relations are handle in charm-ansible-roles. Patrick 2014-11-07 15:33 GMT-05:00 Patrick Hetu <[email protected]>: > > > 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 > > yes, that's what I meant. > > >> [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. > > Done: https://bugs.launchpad.net/juju-core/+bug/1390525 > > > Let me know about the shims! > > Yes, sorry, I forgot to mention the main problem that shim is trying to > solve. > The major reason for shims is because Ansible can't redefined an > existing variable at runtime. Ansible evaluate the yaml as a jinja2 > template > first and then run it. > > So a shim is an assignement trick to get the right values in the playbook. > > For example, I want to use to be able to customize the django_settings > variable > in the charm configuration but set it to the basename of the working_dir in > case it not set: > > - name: set settings_module if django_settings != '' > set_fact: shim_settings_module="{{ django_settings }}" > when: django_settings != '' > > - name: set settings_module if django_settings == '' > set_fact: shim_settings_module="{{ shim_working_dir | basename > }}.settings" > when: django_settings == '' > > I've tried, the default() filter, set_fact module and with_first_found > helpers. > They are all great tools for simulating simple if. > But redefining a variable will fail silently or trigger an infinite loop. > > You can check it out with this snippet: > > - hosts: localhost > vars: > a: "abc" > tasks: > - debug: msg={{ a }} > - set_fact: a="b" > - debug: msg={{ a }} > > Then running it with -e to see the problem: > > ansible-playbook redefine.yml -i local -e "a=xyz" > > > [2] https://github.com/absoludity/charm-ansible-roles > > I've checked those roles and wanted to contribute to it but I got blocked. > > I found that tagging the tasks with Juju's hook names make it difficult to > produce a reusable role. > Because you will have to set a tag to all your tasks in the role > and always be running untagged task. > This also make the charm specific to Juju. > > I've chose to use tags only in the playbook and not in roles. > I use it in the python-django charm like that: > > - role: wsgi-app > tags: > - wsgi-relation-joined > - wsgi-relation-changed > - website-relation-joined > - website-relation-changed > wsgi_user: "{{ django_uid }}" > wsgi_group: "{{ django_gid }}" > working_dir: "{{ shim_working_dir }}" > python_path: "{{ shim_python_path_list }}" > app_label: "{{ sanitized_unit_name }}" > wsgi_application: wsgi > working_dir: "{{ shim_working_dir }}" > settings_module: "{{ shim_settings_module }}" > > And for task specific to a role, I filter in the roles with a when: > > - name: Open port > .... > when: relations['website'] > > - name: Reload wsgi > ... > when: relations['wsgi'] > > or a better way could be to include base on relations in the playbook like > this: > > - include: wsgi_apps/tasks/relations/wsgi.yml > when: relations['wsgi'] > > This is far from perfect but I can't see other way to keep the role > flexible but not specific to Juju. > > >> 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 > >> addresses) > > > >It does, but they're not sanitized currently. Would be a good thing to > >add a sanitized version of local/remote unit names to the ansible > >host_vars. > > I have open a bug about that: > > https://bugs.launchpad.net/charm-helpers/+bug/1390535 > > > > So we have individual charms for each services, even if running from > > the same codebase. Each charm supports only the relations and config > > that it needs[1]. We utilise shared ansible roles as Michael said to > > reduce the charm to pretty much the bare minimum needed for this > > specific service: charm config, relations, writing the service config > > to disk. Most other things are taken care of by the roles. > > Yes that seems to be the way to go. So people would to build a custom > django charm > by adding only pieces that they want in there playbook. > > > 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). > > I think the python-django charm would be there only to show all the > possible features > available by the reusable roles and people would be encorage to build a > charm per site. > > Patrick > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
