Hide Forgot
Description of problem: Trigger a 3.4 installation with enabling RHEL-7.3 and EXTRA-RHEL-7.3 repos on RHEL-7.1/7.2 hosts, installs would failed at task "[os_firewall : Install iptables packages]" Version-Release number of selected component (if applicable): openshift-ansible-3.4.13-1.git.0.ff1d588.el7.noarch.rpm How reproducible: always Steps to Reproduce: 1.Prepare RHEL7.2 hosts to be installed that iptables-1.4.21-16.el7.x86_64 is installed by default, and enabling RHEL-7.3 and EXTRA-RHEL-7.3 repos for installing docker-1.12 2.Trigger the installation Actual results: TASK [os_firewall : Install iptables packages] ********************************* Friday 28 October 2016 05:34:04 -0400 (0:00:00.932) 0:03:16.950 ******** failed: [openshift-132.lab.eng.nay.redhat.com] (item=[u'iptables', u'iptables-services']) => {"changed": true, "failed": true, "item": ["iptables", "iptables-services"], "msg": "", "rc": 1, "results": ["iptables-1.4.21-13.el7.x86_64 providing iptables is already installed", "Loaded plugins: product-id, search-disabled-repos, subscription-manager\nThis system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.\nResolving Dependencies\n--> Running transaction check\n---> Package iptables-services.x86_64 0:1.4.21-17.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package Arch Version Repository Size\n================================================================================\nInstalling:\n iptables-services x86_64 1.4.21-17.el7 rhel73 50 k\n\nTransaction Summary\n================================================================================\nInstall 1 Package\n\nTotal download size: 50 k\nInstalled size: 24 k\nDownloading packages:\nRunning transaction check\nERROR with transaction check vs depsolve:\niptables = 1.4.21-17.el7 is needed by iptables-services-1.4.21-17.el7.x86_64\n You could try running: rpm -Va --nofiles --nodigest\nYour transaction was saved, rerun it with:\n yum load-transaction /tmp/yum_save_tx.2016-10-28.05-37.a0Zon8.yumtx\n"]} Expected results: Installation success. Additional info:
Ansible really does not seem to like things like this: - name: Install iptables packages action: "{{ ansible_pkg_mgr }} name={{ item }} state=present" with_items: - iptables - iptables-services In this case iptables is a little old, iptables-services is not yet installed, and the latest version depends on a newer version of iptables. Switching to state=latest doesn't help, iptables will get updated but iptables-services can still fail due to ordering and when it checks it's deps, re-running it after iptables was successfully updated does work. I can separate these into two tasks, first iptables, then iptables-services, and use state=latest for both.
We wouldn't want to use state=latest, since it would cause the packages to be updated if the config is run and newer packages are available. If separated into two tasks, I would expect iptables-services to properly update iptables to make the transaction work. If the issue is specifying both packages causes the rpm dependency solving to not work properly, it sounds like a bug in yum.
Are we sure going to latest available is off the table? Will that cause significant problems? I see that state=latest is not something we commonly use. It didn't work if separated into two tasks with state=present, it still tries to install the latest iptables-services, and errors out because it requires a change to something iptables. yum handles it fine on CLI with normal invocation, but ansible (or however it is using yum) does not. I can probably switch to a command yum install, but this would do the same as latest and auto-upgrade you if there was something newer avail.
Hmm wait, it doesn't work with yum directly, it surfaced later than I checked: $ yum install iptables-services Loaded plugins: product-id, search-disabled-repos, subscription-manager Resolving Dependencies --> Running transaction check ---> Package iptables-services.x86_64 0:1.4.21-17.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================================================================== Installing: iptables-services x86_64 1.4.21-17.el7 rhel73-latest 50 k Transaction Summary ====================================================================================================================================================================================== Install 1 Package Total size: 50 k Installed size: 24 k Is this ok [y/d/N]: y Downloading packages: Running transaction check ERROR with transaction check vs depsolve: iptables = 1.4.21-17.el7 is needed by iptables-services-1.4.21-17.el7.x86_64 You could try running: rpm -Va --nofiles --nodigest Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2016-11-01.15-38.5Lr1V6.yumtx
Moving this over to RHEL and iptables component, we need some guidance here, it looks like something is wrong with these packages per the previous comment. If you have non-latest iptables installed, and no iptables-services installed, attempting to install the services rpm will fail, it cannot resolve to also update the iptables package, which seems quite wrong. We are unable to assume to update to latest in the OpenShift installer so we're a bit stuck here.
From comment 4: iptables = 1.4.21-17.el7 is needed by iptables-services-1.4.21-17.el7.x86_64 You could try running: rpm -Va --nofiles --nodigest This is normally only happening if the iptables package 1.4.21-17.el7 is not available in the repo - otherwise yum would use it. Can you please verify that this iptables package is available in your repo?
1.4.21-17.el7 was available and installable, however I lost my reproducer with the release of RHEL 7.3, the original report came from using an internal repo for 7.3 pre-release, which is how I reproduced as well. However now with it in prod I cannot reproduce. With 7.3 released and fully up to date iptables-1.4.21-17.el7.x86_64: $ yum downgrade iptables -y This takes me down to 1.4.21-16.el7 but it comes from rhel-7-server-aus-rpms. (root@n4 ~) $ rpm -qa | grep iptables iptables-1.4.21-16.el7.x86_64 (root@n4 ~) $ yum install iptables-services -y This works now and successfully takes me up to 1.4.21-17.el7 for both packages, it didn't previously with the use of the internal 7.3 repo. I suspect it may be an issue if the current iptables version, and the destination iptables-services version to be installed are in different repos, however even that doesn't seem to be happening here with the aus-rpms repo.
This is believed to be a problem only when using pre-release repos and the content that was installed when the OS was installed is no longer available.
*** This bug has been marked as a duplicate of bug 1324914 ***