summaryrefslogtreecommitdiff
path: root/templates/chef_client.rb.tmpl
diff options
context:
space:
mode:
authorScott Moser <smoser@ubuntu.com>2018-04-12 15:51:07 -0600
committerChad Smith <chad.smith@canonical.com>2018-04-12 15:51:07 -0600
commit4b86ab9a25b512420ecfe98953a3f3a6e4b4bba1 (patch)
treeadeb2faf312a92bfb2a76a3a4557d841d7d95d24 /templates/chef_client.rb.tmpl
parentc6dff581a9c253170d5e3f12fb83d16a8dec8257 (diff)
downloadvyos-cloud-init-4b86ab9a25b512420ecfe98953a3f3a6e4b4bba1.tar.gz
vyos-cloud-init-4b86ab9a25b512420ecfe98953a3f3a6e4b4bba1.zip
renderer: support unicode in render_from_file.
If a file passed to render_from_file had non-ascii text then jinja in python2 would decode as ascii, which would cause UnicodeDecodeError. This issue can be re-created in python2 with just: 'can\xe2\x80\x99t'.decode() The solution here is to explicitly pass in unicode supporting type (py3 str, py2 unicode). Those are six.text_type. Then jinja does not try to decode. The reason we hit this is that load_file calls decode_binary. decode_binary believes it has no work to do if it got a six.string_types. isinstance('can\xe2\x80\x99t', six.string_types) == True So it returns the original string which will blow up for jinja. Our fix here then is to load the file in binary mode and explicitly decode it to utf-8. Then in python2 we'll have a unicode type and in python3 we'll have a string type.
Diffstat (limited to 'templates/chef_client.rb.tmpl')
0 files changed, 0 insertions, 0 deletions