hardcoded release version in one area but not when installing tools which causes mismatch

thoraxe commented 7 years ago

I had an issue where the upstream packages had changed to .35 but there was a hard coded version for .34

When installing the some of the packages ahead of time, this resulted in the OCP installation failing because of a version mismatch. I don't have the exact error right now, but it will crop up again once we get a new errata.

kenthua commented 7 years ago

This was all I could gather in my buffer, but last parts regarding version mismatches are what caused it.

"TASK [openshift_version : fail] ****" ... "fatal: [ip-192-199-0-62.us-west-1.compute.internal]: FAILED! => {", " \"changed\": false, ", " \"failed\": true", "}", "", "MSG:", "", "Detected OpenShift version 3.3.1.3 does not match requested openshift_release 3.3.0.35. You may need to adjust your yum repositories, inventory, or run the appropriate OpenShift upgrade playbook."

http://pastebin.com/BtFhKcg6

thoraxe commented 7 years ago

Yes, this is the symptom of the problem.

One of the tasks before the actual installation is installing some OpenShift software for some reason. That is pulling in an "older" package. The sequence of events for failure is:

someone hard codes something like 3.3.0.35 in the var
the repos get updated with a new package
you run the playbook(s) and some of the hosts get some openshift packages installed, with the hard-coded version reference, which is older than the current repo's packages
the actual openshift installer bombs because of the package mismatch

I just haven't had time to go into the plays to figure out which one is installing the specific version, or even why it's doing that.

sborenst / ansible_aws_deployer

hardcoded release version in one area but not when installing tools which causes mismatch #6