Re: [rdo-dev] Strategy on packaging external dependencies in RDO + include Ansible in RDO

On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdoran(a)redhat.com&gt; 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(a)lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org