<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Feb 1, 2017 9:23 AM, "Laurentiu Pancescu" <<a href="mailto:lpancescu@gmail.com">lpancescu@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 01/02/17 15:03, Jason DeTiberus wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think it is unreasonable to expect users that want to run 1.9 or<br>
other versions to use a virtualenv to do so.<br>
</blockquote>
<br></div>
Indeed (although migrating the playbooks to 2.x isn't that difficult). Upstream has an extensive test suite and is pretty fast in addressing the few bugs that occasionally slip through, not to mention the security fixes. I've been using Ansible's stable releases privately for quite a while (via MacPorts), without ever experiencing any serious regressions - even minor annoyances have been rare.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I would argue that is not the case for a sufficiently large project (such as openshift-ansible). We hit quite a few problems when migrating from 1.9 to 2.0 and to a lesser extent 2.0 to 2.1. The 2.1 to 2.2 migration went smoothly (we had previously fixed the templating deprecation warnings, otherwise we would have been bit), but we've hit regressions with 2.2.1.</div><div dir="auto"><br></div><div dir="auto">I agree that the Ansible team is very responsive to fixing issues, but the architecture changes from 1.9 to 2.x introduced breaking changes that affected playbook parsing and breaking plugins.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since Fedora already makes the effort to provide the current Ansible releases in EPEL, it would be a pity not to take advantage of that.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I agree, however there would need to be a transition period for projects that can't respond immediately for breakage related to an Ansible update (moving to using a locked version in a virtualenv) or have other extenuating circumstances (openshift-ansible for example has a callback plugin that provides a friendly error for Ansible < 2.2 or Ansible != 2.2.1.0, though it looks like we'll need to add a test for 2.2.1.1 now as well). That said, the OpenShift jobs already use a virtualenv.</div><div dir="auto"><br></div><div dir="auto">--</div><div dir="auto">Jason DeTiberus</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Laurențiu<div class="elided-text"><br>
______________________________<wbr>_________________<br>
Ci-users mailing list<br>
<a href="mailto:Ci-users@centos.org" target="_blank">Ci-users@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/ci-users" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/ci-users</a><br>
</div></blockquote></div><br></div></div></div>