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

Emilien Macchi emilien at redhat.com
Thu Apr 5 02:39:28 UTC 2018


I see good progress on this thread.

Once thing that I want to bring up, related to
https://review.rdoproject.org/r/#/c/13254/ is that in the future we want to
automate bumps for Ansible (every time there is a new tag); and also make
rdoinfo-tripleo-master-testing-centos-7-multinode-1ctlr-featureset010
<https://review.rdoproject.org/jenkins/job/rdoinfo-tripleo-master-testing-centos-7-multinode-1ctlr-featureset010-nv/4/>
job
voting at some point, because it's too easy to merge this patch now while
in fact, new Ansible wasn't properly tested.

On Tue, Apr 3, 2018 at 9:05 AM, Alan Pevec <apevec at redhat.com> 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
>



-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20180404/fb5e7de3/attachment.html>


More information about the dev mailing list