openedx-unsupported
demo role may fail if EDXAPP_LANGUAGE_CODE is other than English.
I'll understand if this isn't accepted as a bug, since the circumstances are pretty rare. However, with the regular mentions of instituting some legit documented method of using server-vars.yml during initial deployment, I expect it will become one eventually, so why not fix it before that happens. I'm not sure which would be the best way, though, which is why it's a bug report and not a PR. If nothing else, let this story save someone the twelve hours I spent chasing this bug around.
We (an educational establishment working on an edX installation) are installing devstacks for our developers using our own Vagrantfile, which downloads and adds to ansible-playbook our server-vars.yml, containing references to our fork. Among other things, it sets EDXAPP_LANGUAGE_CODE to ru. Even that is not sufficient to trigger the problem, the actual trigger is the fact that we're using (and have committed to our fork) the unapproved translations from Transifex.
When ansible gets to the point where it needs to create users as part of the demo role, manage.py throws UnicodeEncodeExceptions. The reason it does is that the successful completion messages that it was about to print (and which ansible silently consumes, so whoever is installing the devstack doesn't even see them) are in Russian. (Notice that it's not on the list of approved translations either, but it is part of student/views.py, so it's not a manage.py-only message and probably shows up somewhere else, so needs to be translated.) While I initially thought the cause was a problem in ansible extensive investigation demonstrated that this isn't the case. (i.e. I patched it in place, didn't help.)
The real problem is that the way the demo role's tasks run manage.py prevents it from determining that the terminal supports utf-8, (there's no terminal, just stdin and stdout) and by default Python believes that only characters that fit into 'ascii' are valid to print. Having the success message contain cyrillic thus triggers the exception.
The solution that eventually worked was this line in server-vars.yml:
demo_edxapp_venv_bin: 'PYTHONIOENCODING=UTF-8 {{COMMON_APP_DIR}}/{{demo_edxapp_user}}/venvs/{{demo_edxapp_user}}/bin'
This makes sure that Python knows that utf-8 characters are valid and all goes smoothly from there. I am not at all sure this is the best way to communicate this environment variable to the shell, though. (and setting it up in the Vagrantfile mysteriously does not work at all)
@Mihara I just happened to encounter a similar issue this past week, wherein manage.py was being run through the ansible playbook I was using. Have you looked at ansible/ansible#6655, perhaps? My solution was using a more recent version of ansible, though I could get away with isolating the piece of my ansible run. (In other words, I haven't tested the entire run on ansible 1.7.1, only the piece that runs manage.py. I wonder if the problem is -- similar to what you found -- how ansible is running shell commands that encounter unicode, rather than the demo role itself.)
I'm wondering, have you attempted to run the manage.py commands independently from the ansible run? Do they still fail with unicode decoding issues?
Running the command directly was the very first thing I tried, they do not fail this way and print the Russian success message - it only fails when run from a playbook, and since PYTHONIOENCODING fixes it, it has to be because it's printing to stdout, not to a terminal. And, I'm pretty sure there are other issues floating around mentioning how switching to ansible 1.7 is not currently viable due to many playbooks needing syntax changes...
That is true, moving to anything higher than Ansible 1.5 will indeed break other things, and wholesale change over of $ variables to "{{ }}" style isn't the answer either, it'll require some tedious work to go through the variables and test how they are going to work (or not work) with later versions of Ansible.
That work is underway but there's no time table of it landing.
