jinja treating 'namespace' as a keyword in tripleo_common tests

[Brent Eagles]

Certain unit tests in tripleo-common are failing to match computed vs expected results, e.g.:

== Start paste ==
 ... -python} -m subunit.run discover -t ./ . --load-list /tmp/tmpkzaf60rl
2017-11-14 18:18:59.262614 | ubuntu-xenial | ======================================================================
2017-11-14 18:18:59.262646 | ubuntu-xenial | FAIL: tripleo_common.tests.image.test_kolla_builder.TestKollaImageBuilderTemplate.test_container_images_from_template_filter
2017-11-14 18:18:59.262659 | ubuntu-xenial | tags: worker-2

<< snip >>

2017-11-14 18:18:59.262905 | ubuntu-xenial | testtools.matchers._impl.MismatchError: !=:
2017-11-14 18:18:59.262927 | ubuntu-xenial | reference = [{'imagename': 'tripleoupstream/centos-binary-nova-compute:liberty',
2017-11-14 18:18:59.262940 | ubuntu-xenial | 'pull_source': 'docker.io',
2017-11-14 18:18:59.262954 | ubuntu-xenial | 'push_destination': 'localhost:8787',
2017-11-14 18:18:59.262965 | ubuntu-xenial | 'uploader': 'docker'},
2017-11-14 18:18:59.262985 | ubuntu-xenial | {'imagename': 'tripleoupstream/centos-binary-nova-libvirt:liberty',

<< snip >>

2017-11-14 18:18:59.263053 | ubuntu-xenial | 'pull_source': 'docker.io',
2017-11-14 18:18:59.263067 | ubuntu-xenial | 'push_destination': 'localhost:8787'}]
2017-11-14 18:18:59.263081 | ubuntu-xenial | actual = [{'imagename': '<class '
2017-11-14 18:18:59.263103 | ubuntu-xenial | "'jinja2.utils.Namespace'>/centos-binary-nova-compute:liberty",

<< snip >>

== End paste ==

On a hunch, I replaced all instances of 'namespace' in jinja strings and files with something else (like 'ugh' or 'ns') and the tests succeeded. Perhaps this is a known issue in jinja, a regression or simply a breaking change that we need to adapt to?

[Julie Pichon (jpichon)]

Seems like a duplicate of bug 1732140, which turns out to be resolved by https://review.openstack.org/#/c/516136/ - has all the right votes but struggling to merge unfortunately.

[Brent Eagles (beagles)]

Thanks Julie. I missed this in my search! It is indeed a duplicate. The referenced bug covers the exact same findings as well (version 2.10 yada yada).