On Mon, Nov 14, 2016 at 2:40 PM, Michael Scherer <mscherer at redhat.com> wrote: > Le samedi 12 novembre 2016 à 18:12 +0100, François Cami a écrit : >> On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard <dms at redhat.com> wrote: >> > On Sat, Nov 12, 2016 at 11:37 AM, François Cami <fcami at fedoraproject.org> wrote: >> >> Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate >> >> repositories managed by separate centos-release-ansible-{19,20,21,22} >> >> RPMs. Any issue during the build and test phases will be reported here >> >> or on IRC. Persistent issues will be posted to the wiki. >> > >> > Does upstream Ansible even support as far back as 1.9.x and 2.0.x ? >> >> The answer is quite probably "no". > > I brought that issue with the other developers of Ansible. > There is plan to remove it from epel (1.9), and I suspect the last > update will be to fix CVE-2016-8628, then it will likely be declared > officially EOL. > >> > Are you going to be shipping what are basically EOL and >> > unsupported/unmaintained versions ? >> >> Yes. >> There will be a note in the wiki making that clear. >> Tbh I have no other choice as ceph upstream repeatedly told me the >> ceph-ansible playbook is only validated against ansible-1.9 for now. > > Porting the software to 2.X is a option (albeit I guess not the favored > one) > > While there isn't much serious security issue with Ansible[1], relying > on obsoletes version is bad. If some playbooks can't be ported to 2.X or > if there is no will or timeline to that to happen, it is effectively not > maintained to my eyes. See below :) To clarify: while I plan to make 1.9 available, it is best thought as a historical effort like http://vault.centos.org/ and our users will be encouraged to use the future ansible2 repository. >> One of the goals of the ansible effort is to test that particular >> playbook against different ansible versions and fix the bugs in the >> playbook. >> I'd rather start from a known-working environment than from a broken >> one to do so. > > I think we need to have a specific page that outline the timeline of > support, but that would be much easier if we knew the upstream policy, > which I plan to ask to be clarified upstream. Awesome, thank you! François > [1] the worst problems found so far requires a root compromised server > in the first place _and_ a very specific set of playbook, cf > CVE-2016-8628, CVE-2014-4966 (I can give details offlist if people are > interested). > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel >