> - Identify which projects we have had troubles in the past months and that
> we are not automatically testing when new versions bump up (OVS? Ceph? etc)
> - For these projects, how could we either 1) import them in delorean and

Pretty please s/delorean/RDO Trunk/
DLRN is a tool, RDO Trunk are the repos built by it.
(see Alfredo's blog series starting with [1] for the introduction to RDO repos)

> automatically bump them at each new tag, with proper CI job in place or 2)
> have a repo that is nightly build from imports on latest tags available from
> their upstream repos), and have periodic jobs that test these bits.

Upstream trunk chasing requires involvement from the people working
closely in that upstream project,
and reality is that e.g. even for OpenStack projects FTBFs in RDO
Trunk are fixed by CI and infra teams most of the time.
Until we have clear buy-in from subject-matter-experts, we cannot add
a project directly to the trunk chase.
There could a compromise, read on.

> What I like with 1) is that we can easily test them independently (e.g. a
> new version of OVS) versus all together in 2) (a new version of OVS + a new
> version of MariaDB, etc).

For OVS specifically, Javier and I looked it and opened a story for
DLRN support [2]
tl;dr project would be in rdoinfo but pinned and every pin update
would be gated by rdoinfo CI
Open questions are which CI jobs give good enough coverage while not
too expense (hint: running full TripleO CI is NOT answer).
This would avoid limit amount of racing against upstream master as pin
updates would be proposed by the interested person who would then own
it until it works and passes gate.

Note this is all for the OpenStack/RDO release in _development_ i.e.
master CI, for stable releases we would use stable release of
dependencies, ideally built and released in the CentOS SIG repos
i.e. Ceph from Storage SIG (this is the case now), OVS from NFV SIG
(not the case now), Ansible from ConfigManagement SIG (not the case
now) ...

> Which leads to my second question... how are going to ship Ansible.
> I talked with Sam Doran (in cc) today and it seems like in the near future
> Ansible would be shipped via releases.ansible.com or EPE (and not from CentOS Extras anymore).

Ansible RPMs are already there
http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/
but they depend on EPEL for additional deps. To make it work in CentOS
SIG ecosystem, we need them rebuilt and released in the appropriate
SIG.

> So here are the questions:
>
> 1) How are we going to test new versions of Ansible in RDO CI context?
> 2) Where should we ship it? Back in my proposal, would it make sense to
> import Ansible in RDO and gate each bump (proposal #1) or take upstream, put
> in a deps repo (as we have current I believe) and test it with a periodic jobs among other new deps.

Ansible is not in deps repo, we are getting it from Extras.
NB there are multiple Ansibles in the CI context: Zuul/softwarefactory
is pinned to an older version and pypi installed and the same is
tripleo-quickstart (ideally those would use RPM Ansible but that's a
separate discussion).
Ansible RPM is only used by tripleo itself and it is currently coming
from Extras where latest version is 2.4.2 [3] and I saw requests to
get newer.
For master we could try the same plan as OVS above, for stable
releases I'd ask Ansible team to get involved with ConfigManagement
SIG.

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!