<div dir="ltr">I see good progress on this thread.<div><br></div><div>Once thing that I want to bring up, related to <a href="https://review.rdoproject.org/r/#/c/13254/">https://review.rdoproject.org/r/#/c/13254/</a> is that in the future we want to automate bumps for Ansible (every time there is a new tag); and also make <a href="https://review.rdoproject.org/jenkins/job/rdoinfo-tripleo-master-testing-centos-7-multinode-1ctlr-featureset010-nv/4/" rel="nofollow" style="color:rgb(6,84,172);text-decoration:none;font-family:sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">rdoinfo-tripleo-master-testing-centos-7-multinode-1ctlr-featureset010</a> job voting at some point, because it's too easy to merge this patch now while in fact, new Ansible wasn't properly tested.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 3, 2018 at 9:05 AM, Alan Pevec <span dir="ltr"><<a href="mailto:apevec@redhat.com" target="_blank">apevec@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <<a href="mailto:sdoran@redhat.com">sdoran@redhat.com</a>> wrote:<br>
>> Ansible RPMs are already there<br>
>> <a href="http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/" rel="noreferrer" target="_blank">http://releases.ansible.com/<wbr>ansible/rpm/release/epel-7-<wbr>x86_64/</a> but they<br>
>> depend on EPEL for additional deps.<br>
><br>
> Ansible RPMs have always been there. I don't believe they depend on anything<br>
> in EPEL.<br>
<br>
</span>You are correct, I had some stale info or mixed it up with something else.<br>
Here is yum install output on an empty CentOS7 machine:<br>
Installing:<br>
ansible noarch 2.4.3.0-1.el7.ans /ansible-2.4.3.0-1.el7.ans.<wbr>noarch<br>
Installing for dependencies:<br>
PyYAML x86_64 3.10-11.el7 base<br>
libyaml x86_64 0.1.4-11.el7_0 base<br>
python-babel noarch 0.9.6-8.el7 base<br>
python-cffi x86_64 1.6.0-5.el7 base<br>
python-enum34 noarch 1.0.4-1.el7 base<br>
python-idna noarch 2.4-1.el7 base<br>
python-ipaddress noarch 1.0.16-2.el7 base<br>
python-jinja2 noarch 2.7.2-2.el7 base<br>
python-markupsafe x86_64 0.11-10.el7 base<br>
python-paramiko noarch 2.1.1-4.el7 extras<br>
python-ply noarch 3.4-11.el7 base<br>
python-pycparser noarch 2.14-1.el7 base<br>
python-setuptools noarch 0.9.8-7.el7 base<br>
python2-cryptography x86_64 1.7.2-1.el7_4.1 updates<br>
python2-pyasn1 noarch 0.1.9-7.el7 base<br>
sshpass x86_64 1.06-2.el7 extras<br>
<span class="gmail-"><br>
> sshpass and paramiko come from Extras, python2-cryptography comes from<br>
> updates.<br>
<br>
</span>My concern is that if those were included in Extras for Ansible, they<br>
would be removed from Extras together with ansible.<br>
<span class="gmail-"><br>
> I'm not sure if any of that is helpful since you mentioned it would need to<br>
> be built by the appropriate SIG anyway.<br>
<br>
</span>Yes, ideally we would be able to get ConfigMgmt SIG going, in the<br>
meantime other SIGs are rebuilding on their own e.g. Virt SIG/oVirt<br>
did 2.4.3 <a href="http://cbs.centos.org/koji/buildinfo?buildID=21591" rel="noreferrer" target="_blank">http://cbs.centos.org/koji/<wbr>buildinfo?buildID=21591</a><br>
As a quickfix, we could also temporarily push this to RDO deps repo,<br>
until we have rest of the plan ready.<br>
<span class="gmail-"><br>
>> BTW ideal approach would be to insert OpenStack use-cases into Ansible<br>
>> upstream CI and make it voting, this could become reality with cross-project<br>
>> CI efforts lead by openstack-infra. With that, Ansible master would never<br>
>> break us!<br>
><br>
> I don't entirely follow this, but I think it sounds like what I proposed<br>
> above: having OpenStack test the devel branch of Ansible so Ansible<br>
> Engineering can get feedback quickly if things are broken prior to a<br>
> release. I know some of the OpenStack infra folks, and the networking team<br>
> within Ansible has been doing a lot of work with them with Zuul for<br>
> distributed CI. Myself and Ricardo Cruz on the Ansible side are very<br>
> interested in hooking up more testing of Ansible as it relates to OpenStack<br>
> using Zuul run by OpenStack Infra. Ricki and I talked about this a bunch at<br>
> the PTG but have been working on other things since we got back.<br>
<br>
</span>Yes, above was forward-looking CD world where, given infinite CI<br>
resources, everything is tested pre-commit across collaborating<br>
projects.<br>
Definitely trunk RPMs from devel branch are the step in that<br>
direction, progression scale is:<br>
no testing, push the latest release, hope for the best -> CI with<br>
latest release -> CI with devel branch -> CI pre-commit<br>
<br>
Cheers,<br>
Alan<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>
</div></div></div>