On Feb 1, 2017 9:23 AM, "Laurentiu Pancescu" lpancescu@gmail.com wrote:
On 01/02/17 15:03, Jason DeTiberus wrote:
I don't think it is unreasonable to expect users that want to run 1.9 or other versions to use a virtualenv to do so.
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.
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.
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.
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.
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.
-- Jason DeTiberus
Regards, Laurențiu
_______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users