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

[Jill Rouleau]

This is coming back up.  We're making module changes that will release
with ansible 2.7 and will be needed in tripleo.  What do we need to do
to move forward with a long term plan for ensuring ansible releases find
their way into rdo? 

- JillOn Tue, 2018-04-03 at 18:05 +0200, Alan Pevec wrote:
> On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdoran at 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 at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
> 
> To unsubscribe: dev-unsubscribe at lists.rdoproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20180709/dcde4eef/attachment-0001.sig>