On Mon, Nov 14, 2016 at 2:40 PM, Michael Scherer mscherer@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@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@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@centos.org https://lists.centos.org/mailman/listinfo/centos-devel