On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdo...@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 _______________________________________________ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org
