lxc_container: open files as text, fixes #30571

[bit]

SUMMARY

fix python3 support

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

modules/cloud/lxc/lxc_container.py

ANSIBLE VERSION

ansible 2.5.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/j/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/j/.local/lib/python3.5/site-packages/ansible-2.5.0-py3.5.egg/ansible
  executable location = /home/j/.local/bin/ansible
  python version = 3.5.4 (default, Sep  5 2017, 18:32:10) [GCC 7.2.0]

[ansibot]

cc @cloudnull
click here for bot help

[abadger]

Note: It's probably faster to write this like this:

container_config = to_text(f.read(), errors='surrogate_or_strict').splitlines()

There's overhead from calling the text conversion functions so calling them only once should be quicker.

[abadger]

Also, I'm not sure if it matters but you could use to_native() instead of to_text() if container_config should be byte strings on python2 and text strings on python3. In a quick look at the following code I didn't see anything that would be a problem with text strings on python2 but I put that out there in case @cloudnull does see something.

[bit]

instead of using to_native, my first commit to just open the file with 'r' and write with 'w' might be cleaner. that way it will be bytes in py2 and text in py3. After reading the py3 docs assumed you want to always use to_text/to_bytes in those cases.

[abadger]

Correct. I definitely prefer that we open files in binary mode and use to_bytes() when we write to them. Reading from them when we're dealing with modules is trickier because we let modules use a native string strategy. The modules can choose to try dealing with strings as the str type on the python version they're running as. This works well when there isn't much usage of the filesystem, environment variables, over the wire protocols, or other things from outside of python. In those cases,, having python strings match with bare string literals can be very helpful for module developers. But when we do start using files, filesystem paths, env vars, etc, even modules are forced to start thinking about encodings. Unfortunately, ```open()``` doesn't give much flexibility in terms of encodings. So I still prefer to open the file in binary mode and use to_text or to_native to convert the read in lines. But, depending on the API being used, sometimes it makes sense to use to_text and other times it makes sense to use to_native.

[abadger]

Merged to devel and cherry-picked to stable-2.4 for the 2.4.1 release.