[CentOS-devel] [Config Management SIG] delivering Ansible

[François Cami]

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
>