Hide Forgot
When I install ansible it depends on python-jinja2. However, in EPEL there is a package, python-jinja2-26, which is a suitable (and updated) replacement. Can we update the ansible RPM to optionally use python-jinja2-26 if available, or at least not depend on python-jinja2 exclusively?
Not really. We could make it use python-jinja2-26 unconditionally, but rpm doesn't have a way to do any kind of optional (at least not the rhel6 rpm version). Is there some specific thing you want from python-jinja2-26 that is not available in python-jinja2?
Yeh, I want jinja 2.6 ;) the version of jinja2 provided by CentOS/RHEL is quite old, and since there's an update in EPEL it seems silly not to use it - and frustrating that I can't use it (without manually breaking dependencies and deleting the jinja2 package with nodeps). Don't both packages claim to provide 'python-jinja2' or something?
(In reply to James Belchamber from comment #2) > Yeh, I want jinja 2.6 ;) the version of jinja2 provided by CentOS/RHEL is > quite old, and since there's an update in EPEL it seems silly not to use it > - and frustrating that I can't use it (without manually breaking > dependencies and deleting the jinja2 package with nodeps). But why? Is there some specific bug you are running into thats fixed? Some change in syntax you can only use there? I'm afraid I am pretty risk averse to changing epel6 here, as the newer one could cause regressions and break things. If there were known advantages to the newer one that might be easier to decide to do. > > Don't both packages claim to provide 'python-jinja2' or something? No, python-jinja2-26 only provides "python-jinja2-26"
Ah, specifically? I'm hitting an issue using the mapping filter, but there's a bunch of other features introduced since 2.1 that are used in playbooks by the Ansible community. Here is the changelog: http://jinja.pocoo.org/docs/dev/changelog/ If it's a case of either/or, I'd personally lean towards more cutting-edge versions of Ansible using a newer Jinja2. They're both available in the same repo so it's not like that's a breaking change - leave RHEL to provide the super-stable, enterprise Ansible.
Newer jinja versions do add filters so it is nice to use then if available. But it would take a small amount of distro-specific patching to make it work all the time. A system can have both versions of jinja installed. On RHEL6 the default version would be the older version. So we'd need to have ansible's pkg_resources code detect that. Probably the best way to do that is to patch the setup.py to specify a version for jinja2: install_requires=['paramiko', 'jinja2 >= 2.6', "PyYAML", 'setuptools', 'pycrypto >= 2.6'], Then when ansible is built, the version dependency will be added to the egg_info and ansible will know which version of jinja2 it should install. At the rpm packaging level we would have to decide to unconditionally require pyhton-jinja2-26 instead of python-jinja2. That shouldn't cause any problems - it would just be people getting one dep in place of another.
So, I don't actually see any added filters between 2.2.1 and 2.6... That said, I'm not opposed to doing this, but I might see a security issue that needs fixing in python-jinja2-26 before we depend on it, and we might also consider if 2.8 is coming out soon, if so, we might want to look at moving to that instead? I'm going to be away for the next week, but feel free to move it forward however you like Toshio. ;)
s/filter/test. The mapping test was added in 2.6. I called it a filter by mistake ;) I only suggested 2.6 because it's there - newer is better in this case, since jinja2 features are directly accessed by the Ansible user.
python-jinja2-26 package has the patch for the security issue added: * Fri Jun 13 2014 Thomas Moschny <thomas.moschny@gmx.de> - 2.6-3 - Fix CVE-2014-1402 (using patch from RHSA-2014:0748).
I scratch built the package but keep getting sidetracked before testing: http://koji.fedoraproject.org/koji/taskinfo?taskID=10234297 If you have the time and inclination to test, I want to test that it works with both the regular python-jinja2 installed and with the regular python-jinja2 not installed.
I can test this quite extensively tomorrow :D
Ugh, it all works except one bit: # ansible-galaxy Traceback (most recent call last): File "/usr/bin/ansible-galaxy", line 39, in <module> from jinja2 import Environment ImportError: No module named jinja2 This is because ansible-galaxy is the only command that doesn't use the pkg_resources code - this is actually fixed in the ansible devel branch, which combines all the code into one executable (as part of the v2 commit - ce3ef7f). Of course, you can also fix this by having python-jinja2 installed, but I don't know if you'd really want to be depending on both packages. Interestingly, I'm getting different behaviour on two hosts. My initial catalyst for raising this was that, in my development environment, the python-jinja2 package is used by ansible in preference to python-jinja2-26. This meant I had to manually remove python-jinja2 with --nodeps to make my playbook work. On my fresh CentOS 6.5 test server (which I spun up to test this package) python-jinja2-26 is used by ansible even if python-jinja2 is present - the reverse of my current development environment. This is true even of the current stable packages in EPEL. Any idea why that might be? Anyway, we shouldn't break ansible-galaxy - possibly this replaced dependency should wait until Ansible v2. Everything else, however, works exactly as expected.
I can't think of a reason that python-jinja2-26 would be preferred with the current packages in the repository. It would be preferred in the package I scratch built though (part of the changes that the ansible-newer-jinja.patch effect: - install_requires=['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6'], + install_requires=['paramiko', 'jinja2 >= 2.6', "PyYAML", 'setuptools', 'pycrypto >= 2.6'],
I've found that I had to rebuild EPELs ansible package for RHEL 6 with the following change: from: Requires: python-jinja2 to: Requires: python-jinja2-26 Otherwise, ansible would not install at all, see below. But maybe, this is more about the python-jinja2-26 package: I think it needs to add a "provides": Provides: python-jinja2 So I guess I should really have created a rebuilt python-jinja2-26 package instead of the somewhat dirty trick above. ============================================================== # yum install ansible Loaded plugins: product-id, security, subscription-manager Setting up Install Process epel/metalink | 17 kB 00:00 epel | 4.3 kB 00:00 epel/primary_db | 5.7 MB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rhev-agent-rpms/primary_db | 38 kB 00:00 rhel-6-server-rpms | 3.7 kB 00:00 rhel-6-server-rpms/primary_db | 37 MB 00:12 Resolving Dependencies --> Running transaction check ---> Package ansible.noarch 0:1.9.4-1.el6 will be installed --> Processing Dependency: sshpass for package: ansible-1.9.4-1.el6.noarch --> Processing Dependency: python-keyczar for package: ansible-1.9.4-1.el6.noarch --> Processing Dependency: python-jinja2 for package: ansible-1.9.4-1.el6.noarch --> Processing Dependency: python-httplib2 for package: ansible-1.9.4-1.el6.noarch --> Processing Dependency: python-crypto2.6 for package: ansible-1.9.4-1.el6.noarch --> Processing Dependency: PyYAML for package: ansible-1.9.4-1.el6.noarch --> Running transaction check ---> Package PyYAML.x86_64 0:3.10-3.1.el6 will be installed --> Processing Dependency: libyaml-0.so.2()(64bit) for package: PyYAML-3.10-3.1.el6.x86_64 ---> Package ansible.noarch 0:1.9.4-1.el6 will be installed --> Processing Dependency: python-jinja2 for package: ansible-1.9.4-1.el6.noarch ---> Package python-crypto2.6.x86_64 0:2.6.1-2.el6 will be installed ---> Package python-httplib2.noarch 0:0.7.7-1.el6 will be installed ---> Package python-keyczar.noarch 0:0.71c-1.el6 will be installed --> Processing Dependency: python-pyasn1 for package: python-keyczar-0.71c-1.el6.noarch ---> Package sshpass.x86_64 0:1.05-1.el6 will be installed --> Running transaction check ---> Package ansible.noarch 0:1.9.4-1.el6 will be installed --> Processing Dependency: python-jinja2 for package: ansible-1.9.4-1.el6.noarch ---> Package libyaml.x86_64 0:0.1.3-4.el6_6 will be installed ---> Package python-pyasn1.noarch 0:0.0.12a-1.el6 will be installed --> Finished Dependency Resolution Error: Package: ansible-1.9.4-1.el6.noarch (epel) Requires: python-jinja2 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ==============================================================
(In reply to Troels Arvin from comment #13) > I've found that I had to rebuild EPELs ansible package for RHEL 6 with the > following change: > from: > Requires: python-jinja2 > to: > Requires: python-jinja2-26 > > Otherwise, ansible would not install at all, see below. You need to enable the 'rhel-optional' channel to get python-jinja2 That has nothing to do with this. ;)
(In reply to Kevin Fenzi from comment #14) Kevin: Ah, thanks. You are right. After enabling rhel-optional, I don't have to do anything dirty in order to install ansible.
The recent release of Ansible 2.0 fixes the only issue I found with Toshio's package (the different host behaviour was down to me fiddling locally, so it can be disregarded) :)
(In reply to James Belchamber from comment #16) > The recent release of Ansible 2.0 fixes the only issue I found with Toshio's > package (the different host behaviour was down to me fiddling locally, so it > can be disregarded) :) So, that means ansible 2.0, patched to use python-jinja2-26 works in all your tests? Or ansible 2.0 stock meets your needs and you don't need python-jinja2-26 anymore? or ?
Ansible 2.0 isn't in EPEL yet, so I haven't tested it. However, the blocker was that ansible-galaxy was a bit of a unicorn, which was fixed in 2.0. I would recommend making the change to python-jinja2-26 at the same time as updating to Ansible 2.0.
ansible-2.0.0.2-3.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7a81f2e5d4
ansible-2.0.0.2-3.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7a81f2e5d4
ansible-2.0.1.0-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d99bf20e44
ansible-2.0.1.0-2.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d99bf20e44
ansible-2.0.1.0-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.