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

Mon Nov 14 13:40:10 UTC 2016
Michael Scherer <mscherer at redhat.com>

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.


> 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.

[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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20161114/2e9603d4/attachment-0008.sig>