<div dir="ltr">> Let me know about the shims!<br><div><br></div><div>Well, I've just tested and it looks like it was fixed in Ansible 1.7 at least for host_vars/...</div><div>So much cleaner code to come!</div><div><br></div><div>Also, let met know what your thinking about the changes I propose on how relations</div><div>are handle in charm-ansible-roles.</div><div><br></div><div>Patrick</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-07 15:33 GMT-05:00 Patrick Hetu <span dir="ltr"><<a href="mailto:patrick.hetu@gmail.com" target="_blank">patrick.hetu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><br>> Specifically, this is not the config.yaml you're talking about, but<div>> the config file which is passed during deployment right? As in,</div><div>> "myconfig.yaml" in:</div><div>></div><div>> juju deploy --config myconfig.yaml mycharm</div><div><br></div></span><div>yes, that's what I meant.</div><span class=""><div><br></div><div>>> [1] Using a configuration file without that charm name at the top</div><div>>> was working in the past but now doesn't. Maybe this could be</div><div>>> re-enable without to much negative impact.</div><div><br></div><div>>That might be worth a juju bug.</div><div><br></div></span><div>Done: <a href="https://bugs.launchpad.net/juju-core/+bug/1390525" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1390525</a></div><span class=""><div><br></div><div>> Let me know about the shims!</div><div><br></div></span><div>Yes, sorry, I forgot to mention the main problem that shim is trying to solve.</div><div>The major reason for shims is because Ansible can't redefined an</div><div>existing variable at runtime. Ansible evaluate the yaml as a jinja2 template</div><div>first and then run it.</div><div><br></div><div>So a shim is an assignement trick to get the right values in the playbook.</div><div><br></div><div>For example, I want to use to be able to customize the django_settings variable</div><div>in the charm configuration but set it to the basename of the working_dir in</div><div>case it not set:</div><div><br></div><div>- name: set settings_module if django_settings != ''</div><div> set_fact: shim_settings_module="{{ django_settings }}"</div><div> when: django_settings != ''</div><div><br></div><div>- name: set settings_module if django_settings == ''</div><div> set_fact: shim_settings_module="{{ shim_working_dir | basename }}.settings"</div><div> when: django_settings == ''</div><div><br></div><div>I've tried, the default() filter, set_fact module and with_first_found helpers.</div><div>They are all great tools for simulating simple if.</div><div>But redefining a variable will fail silently or trigger an infinite loop.</div><div><br></div><div>You can check it out with this snippet:</div><div><br></div><div>- hosts: localhost</div><div> vars:</div><div> a: "abc"</div><div> tasks:</div><div> - debug: msg={{ a }}</div><div> - set_fact: a="b"</div><div> - debug: msg={{ a }}</div><div><br></div><div>Then running it with -e to see the problem:</div><div><br></div><div> ansible-playbook redefine.yml -i local -e "a=xyz"</div><div><br></div><div>> [2] <a href="https://github.com/absoludity/charm-ansible-roles" target="_blank">https://github.com/absoludity/charm-ansible-roles</a></div><div><br></div><div>I've checked those roles and wanted to contribute to it but I got blocked.</div><div><br></div><div>I found that tagging the tasks with Juju's hook names make it difficult to produce a reusable role.</div><div>Because you will have to set a tag to all your tasks in the role</div><div>and always be running untagged task.</div><div>This also make the charm specific to Juju.</div><div><br></div><div>I've chose to use tags only in the playbook and not in roles.</div><div>I use it in the python-django charm like that:</div><div><br></div><div>- role: wsgi-app</div><div> tags:</div><div> - wsgi-relation-joined</div><div> - wsgi-relation-changed</div><div> - website-relation-joined</div><div> - website-relation-changed</div><div> wsgi_user: "{{ django_uid }}"</div><div> wsgi_group: "{{ django_gid }}"</div><div> working_dir: "{{ shim_working_dir }}"</div><div> python_path: "{{ shim_python_path_list }}"</div><div> app_label: "{{ sanitized_unit_name }}"</div><div> wsgi_application: wsgi</div><div> working_dir: "{{ shim_working_dir }}"</div><div> settings_module: "{{ shim_settings_module }}"</div><div><br></div><div>And for task specific to a role, I filter in the roles with a when:</div><div><br></div><div>- name: Open port</div><div> ....</div><div> when: relations['website']</div><div><br></div><div>- name: Reload wsgi</div><div> ...</div><div> when: relations['wsgi']</div><div><br></div><div>or a better way could be to include base on relations in the playbook like this:</div><div><br></div><div>- include: wsgi_apps/tasks/relations/wsgi.yml</div><div> when: relations['wsgi']</div><div><br></div><div>This is far from perfect but I can't see other way to keep the role</div><div>flexible but not specific to Juju.</div><span class=""><div><br></div><div>>> That *should* be done by the existing charmhelpers (it writes out</div><div>>> /etc/ansible/host_vars/localhost on each hook execution with config,</div><div>>> relations and some other things like unit name, public and private</div><div>>> addresses)</div><div>></div><div>>It does, but they're not sanitized currently. Would be a good thing to</div><div>>add a sanitized version of local/remote unit names to the ansible</div><div>>host_vars.</div><div><br></div></span><div>I have open a bug about that:</div><div><br></div><div> <a href="https://bugs.launchpad.net/charm-helpers/+bug/1390535" target="_blank">https://bugs.launchpad.net/charm-helpers/+bug/1390535</a></div><span class=""><div><br></div><div><br></div><div>> So we have individual charms for each services, even if running from</div><div>> the same codebase. Each charm supports only the relations and config</div><div>> that it needs[1]. We utilise shared ansible roles as Michael said to</div><div>> reduce the charm to pretty much the bare minimum needed for this</div><div>> specific service: charm config, relations, writing the service config</div><div>> to disk. Most other things are taken care of by the roles.</div><div><br></div></span><div>Yes that seems to be the way to go. So people would to build a custom django charm</div><div>by adding only pieces that they want in there playbook.</div><span class=""><div><br></div><div>> our use-case is a bit different as we're not attempting to</div><div>> write one charm to deploy any django project right now (we did try in</div><div>> the past, but found it was adding unreasonable complexity for us,</div><div>> unless the projects being deployed were very similar).</div><div><br></div></span><div>I think the python-django charm would be there only to show all the possible features</div><div>available by the reusable roles and people would be encorage to build a charm per site.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Patrick</div><div><br></div></font></span></div> </blockquote></div><br></div>