11:05 a.m.
On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdoran(a)redhat.com> wrote:
> Ansible RPMs are already there
> http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/ but they
> depend on EPEL for additional deps.
Ansible RPMs have always been there. I don't believe they depend on anything
in EPEL.
You are correct, I had some stale info or mixed it up with something else.
Here is yum install output on an empty CentOS7 machine:
Installing:
ansible noarch 2.4.3.0-1.el7.ans /ansible-2.4.3.0-1.el7.ans.noarch
Installing for dependencies:
PyYAML x86_64 3.10-11.el7 base
libyaml x86_64 0.1.4-11.el7_0 base
python-babel noarch 0.9.6-8.el7 base
python-cffi x86_64 1.6.0-5.el7 base
python-enum34 noarch 1.0.4-1.el7 base
python-idna noarch 2.4-1.el7 base
python-ipaddress noarch 1.0.16-2.el7 base
python-jinja2 noarch 2.7.2-2.el7 base
python-markupsafe x86_64 0.11-10.el7 base
python-paramiko noarch 2.1.1-4.el7 extras
python-ply noarch 3.4-11.el7 base
python-pycparser noarch 2.14-1.el7 base
python-setuptools noarch 0.9.8-7.el7 base
python2-cryptography x86_64 1.7.2-1.el7_4.1 updates
python2-pyasn1 noarch 0.1.9-7.el7 base
sshpass x86_64 1.06-2.el7 extras
sshpass and paramiko come from Extras, python2-cryptography comes
from
updates.
My concern is that if those were included in Extras for Ansible, they
would be removed from Extras together with ansible.
I'm not sure if any of that is helpful since you mentioned it
would need to
be built by the appropriate SIG anyway.
Yes, ideally we would be able to get ConfigMgmt SIG going, in the
meantime other SIGs are rebuilding on their own e.g. Virt SIG/oVirt
did 2.4.3 http://cbs.centos.org/koji/buildinfo?buildID=21591
As a quickfix, we could also temporarily push this to RDO deps repo,
until we have rest of the plan ready.
> BTW ideal approach would be to insert OpenStack use-cases into
Ansible
> upstream CI and make it voting, this could become reality with cross-project
> CI efforts lead by openstack-infra. With that, Ansible master would never
> break us!
I don't entirely follow this, but I think it sounds like what I proposed
above: having OpenStack test the devel branch of Ansible so Ansible
Engineering can get feedback quickly if things are broken prior to a
release. I know some of the OpenStack infra folks, and the networking team
within Ansible has been doing a lot of work with them with Zuul for
distributed CI. Myself and Ricardo Cruz on the Ansible side are very
interested in hooking up more testing of Ansible as it relates to OpenStack
using Zuul run by OpenStack Infra. Ricki and I talked about this a bunch at
the PTG but have been working on other things since we got back.
Yes, above was forward-looking CD world where, given infinite CI
resources, everything is tested pre-commit across collaborating
projects.
Definitely trunk RPMs from devel branch are the step in that
direction, progression scale is:
no testing, push the latest release, hope for the best -> CI with
latest release -> CI with devel branch -> CI pre-commit
Cheers,
Alan