Bug 1236115 - The ansible package requires python-jinja2
Summary: The ansible package requires python-jinja2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: ansible
Version: el6
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-26 15:02 UTC by James Belchamber
Modified: 2016-04-18 08:37 UTC (History)
6 users (show)

Fixed In Version: ansible-2.0.1.0-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-18 08:37:40 UTC
Type: Bug


Attachments (Terms of Use)

Description James Belchamber 2015-06-26 15:02:33 UTC
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?

Comment 1 Kevin Fenzi 2015-06-26 15:08:42 UTC
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?

Comment 2 James Belchamber 2015-06-26 15:19:58 UTC
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?

Comment 3 Kevin Fenzi 2015-06-26 15:55:35 UTC
(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"

Comment 4 James Belchamber 2015-06-26 16:07:30 UTC
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.

Comment 5 Toshio Ernie Kuratomi 2015-06-26 19:12:14 UTC
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.

Comment 6 Kevin Fenzi 2015-06-26 21:33:38 UTC
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. ;)

Comment 7 James Belchamber 2015-06-26 21:41:26 UTC
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.

Comment 8 Toshio Ernie Kuratomi 2015-06-28 08:27:30 UTC
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).

Comment 9 Toshio Ernie Kuratomi 2015-06-29 20:12:01 UTC
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.

Comment 10 James Belchamber 2015-06-29 20:15:52 UTC
I can test this quite extensively tomorrow :D

Comment 11 James Belchamber 2015-06-30 10:01:24 UTC
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.

Comment 12 Toshio Ernie Kuratomi 2015-07-08 16:53:56 UTC
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'],

Comment 13 Troels Arvin 2016-01-14 17:51:03 UTC
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
==============================================================

Comment 14 Kevin Fenzi 2016-01-14 17:53:55 UTC
(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. ;)

Comment 15 Troels Arvin 2016-01-14 20:46:38 UTC
(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.

Comment 16 James Belchamber 2016-01-15 09:38:28 UTC
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) :)

Comment 17 Kevin Fenzi 2016-01-16 16:53:47 UTC
(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 ?

Comment 18 James Belchamber 2016-01-17 16:14:21 UTC
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.

Comment 19 Fedora Update System 2016-02-05 05:59:55 UTC
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

Comment 20 Fedora Update System 2016-02-06 03:18:53 UTC
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

Comment 21 Fedora Update System 2016-02-25 22:29:15 UTC
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

Comment 22 Fedora Update System 2016-02-27 02:19:19 UTC
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

Comment 23 Fedora Update System 2016-04-18 08:37:36 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.