Hi, ARA author here,
Currently, Ansible in CBS [1] is maintained by the PAAS SIG (+ tdawson ). We're then tagging it in other SIGs wherever it is required such as cloud (for RDO/TripleO [2]) and ceph (for ceph-ansible [3]).
Ideally, I think Ansible should not be maintained by the PAAS SIG but by an (eventual) config management SIG. I can volounteer to help make this happen to some extent but I don't have a lot of bandwidth to put into this in the short term.
That said, EPEL currently only ships the latest version (i.e, 2.3 right now) and this is not good since users might still require 2.2 (or even 2.1). The PAAS SIG currently only ever maintains the version of Ansible known to work for the purposes of openshift-ansible so we have to take this into account as well.
I mention this because if, for example, the PAAS SIG decides it's moving to Ansible 2.3 and other projects leveraging their builds (i.e, RDO and Ceph) are not ready for 2.3, it would break. So, ideally, we'd really need to maintain supported versions.
For the record, here's the spec for Ansible in EPEL7 [4].
[1]: https://cbs.centos.org/koji/packageinfo?packageID=1947 [2]: https://cbs.centos.org/koji/buildinfo?buildID=17091 [3]: https://cbs.centos.org/koji/buildinfo?buildID=17173 [4]: https://src.fedoraproject.org/cgit/rpms/ansible.git/tree/?h=epel7
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Mon, May 29, 2017 at 2:46 PM, Fabian Arrotin arrfab@centos.org wrote:
Hi,
While technically speaking a ConfigManagement SIG was approved a long time ago (https://wiki.centos.org/SpecialInterestGroup/ConfigManagementSIG) it seems that nothing was built at all, and that initial people probably lost interest in that idea (?)
The interesting part is that other SIGs that were relying on such config management tools (like puppet or ansible) built it themselves in their own tags :
- puppet : https://cbs.centos.org/koji/packageinfo?packageID=390
- ansible : https://cbs.centos.org/koji/packageinfo?packageID=1947
I was myself just the "sponsor" for other community people to join and take care of the pkgs they were interested into, but suddenly I was myself busy rebuilding such tools, and I'd even have a new one as a proposal : ARA
ARA (Ansible Run Analysis) is a tool written under the openstack umbrella, and written/maintained by dmsimard (Cloud SIG member) For people not aware of it, it's a callback plugin for ansible that let you store (and so browse) your ansible logs through webui (and it stores those reports into a DB)
I initially thought about building that in the infrastructure7-el7 target, but maybe some other people would be interested into using those as pkgs directly in a repo on mirror.centos.org
Initially the author wanted to have it in Epel7, but due to two pkgs version that are in [base] (and so that will not be overwritten by Epel), that doesn't seem possible. So my proposal would be to rebuild what's needed through configmgmt SIG , including the two packages (pytest and python-jinja2)
For people interested in the ARA in Epel7 story, here is the pkg review : https://bugzilla.redhat.com/show_bug.cgi?id=1426193
Ideas, opinions ?
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel