New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failures with ansible 2.2.1.0 #3111
Comments
Casting |
Hi, trying to install v1.4.0 cluster and Ansible is failing because of
I have tried to checkout Is there some workaround that would allow me to finish the installation process except of downgrading Ansible itself? thanks |
@marekjelen I believe you would need to either need to use the commit that @abutcher linked to above. Ansible is working on a new build that resolves the problem, so I do not expect that we will ship a workaround. |
Playing whack-a-mole with openshift-ansible workarounds. The next place we hit the issue is within the
|
I can confirm that downgrading ansible-2.2.1.0-1.el7.noarch.rpm from epel-release-7-9 to ansible-2.2.0.0-4.el7.noarch.rpm from epel-release-7-8 is a workaround for a successful openshift-ansible v1.4 installation. Regards, Armin. |
@ArminMW Dumb question, but where did you find the old version? I'm not seeing it in EPEL. |
@amdonov Just run into exactly the same issue. Installed 2.2.0.0 as a pip. |
I found the downlevel ansible in an epel mirror that seems to be lagging behind: |
@wicksy Thanks for the tip. I took your advice and did something similar to the following. (Hope I'm not missing anything) sudo yum -y erase ansible Before going that route I tried applying the patch that closed the Ansible issue. I think that additional work will need to happen to the openshift playbooks to work going forward. |
We've also got ansible-2.2.0.0 in the centos paas sig common repo http://mirror.centos.org/centos/7/paas/x86_64/openshift-origin/common/ansible-2.2.0.0-1.el7.noarch.rpm If you choose to downgrade to 2.2.0.0 it should be noted that version is vulnerable to CVE-2016-9587, see https://bugzilla.redhat.com/show_bug.cgi?id=1404378 |
We'll put a workaround in unless we're sure that we'll have a fixed version of ansible available soon. |
Just another confirmation that 2.2.0.0 downgrade results in a pass for me as well. Thanks for linking to the Ansible issues to track. |
Referenced PR is an incomplete fix fwiw. |
Downgrading works. I strongly suggest:
|
+1 for ansible 2.2.1.1 in EPEL repo. thanks |
@anosulchik are you saying you are seeing the same errors with 2.2.1.1? |
@detiber Yes. Looks like EPEL repo now contains 2.2.1.0 as latest Ansible instead of 2.2.1.1. 2.2.1.0 works just fine. |
I've run in to this issue on macOS with virtualenv and sorted it by: |
Incidentally, ansible 2.2.0.0 is no longer available as a package for Fedora 25. So at this point, there is no packaged version of ansible for Fedora 25 which works with Openshift-Ansible. (and replacing it via Pip is kinda painful, because it requires rebuilding the cryptography module). |
@jberkus if you read what i mentioned few comments above you can get the patched version from |
@DanyC97 well, I used a Fedora 24 container, which worked. But it does show that there's a deadline on fixing this one way or the other. |
Hello everyone, It was like same problem, I decided to configure the master server in hours, in the case in a CentOS 7 with chrony. I have the version of ansbile 2.2.1.0 |
@jberkus @maxamillion the current situation is far from ideal by any means. To give a bit more context:
I'm wondering if it would make sense to deliver OpenShift and openshift-ansible through a separate repo (or ideally repos, where each version is a separate repo) similar to how we are shipping in RHEL and CentOS. I think there are quite a few different reasons for why, but in this particular case, it would have allowed us to ship the patched Ansible version without affecting non-OpenShift users. |
Well, personally, I think we should ship an Openshift-ansible container which has all the bits. |
@jberkus kind of like this: #3382 ? There are some tricky problems with containerizing the install bits, though. The two biggest being:
The second reason is the biggest reason we haven't shipped something supported to date. Many users don't seem to like the idea of running the "installer" on a separate host and running a docker container on a host that you are managing the docker daemon and requiring a docker restart kind of kills your install. |
I generally solve the first problem by mounting my .ssh into the container. Not sure about proxy config, though, hasn't been an issue I had to solve. Yes, self-bootstrapping by being able to run the installer on one of the target hosts would be ideal. However, until we solve that problem, a container we can run elsewhere would still be an improvement. |
I already use containerized Ansible-controller and it really needs a lot of tweaking to cover e.g. ansible-vault secrets, .ssh/{config,id_rsa} (ssh bastion host is not an issue), aws api credentials and all possible adjustments to /etc/ansible/ansible.cfg. However, it's worth it, especially in situations like this. Btw, how do you solve such situations within Ansible Tower?? Would you be ever able to automate OCP installation with CloudForms and Tower? PS: We just ran into this issue... |
I'm having an issue and not sure if it is the same or not. I am using: Does this version have the fix or not? The issue I am seeing is during: TASK [openshift_master : set_fact] Is this the result of the same bug or do I have a unique issue? |
@Delmonte3161 That's the same problem. You can get ansible-2.2.1.0-2.el7 from the Centos PaaS SIG repo at http://mirror.centos.org/centos/7/paas/x86_64/openshift-origin/ |
@sdodson so I've installed the
|
@rastakajakwanna oh, hey, how did you deal with secrets? |
@jberkus some of them are parsed from known locations and exposed as env vars in the container, ansible-vault secret is mounted to the container user home location, that's the easiest solution. |
This build contains a fix for ansible that lets the installation of openshift (via openshift-ansible) pass. See: openshift/openshift-ansible#3111
For Fedora 25, ansible 2.2.2.0 is available in Fedora Rawhide as ansible-2.2.2.0-0.1.rc1.fc26.noarch.rpm , which appears to correctly run the playbook. |
Yes, as soon as 2.2.2.0 is available we can put this whole mess behind us. Unfortunately that's happened slower than expected. |
For Fedora 25 had to go for rawhide too which solved the issue.
|
Ansible 2.2.2.0 has been released, it should be available in F25 and EPEL shortly. OCP channels will be updated after we've validated this version. |
Looking forward to it. When it's available, we can close this. |
same problem with ansible 2.2.2.0
|
@x1957 Can you please open a new issue for that, that doesn't look like any of the other errors in this issue and it'd be helpful to gather the output with -vvvv option and include the tasks leading up to this failure. |
Closing this because Ansible 2.2.2.0 is widely available, if you find any new issues please open a new unique issue and include the output with -vvv and the task. |
We're seeing yaml rendering issues with our code and 2.2.1.0. Need to sort out if we need to fix something or if ansible will be fixing things.
Upstream references ansible/ansible#20290 ansible/ansible#20253
The text was updated successfully, but these errors were encountered: