3:39 p.m.
Hi,
Long time lurker first time poster.
On Wed, Mar 28, 2018 at 3:14 PM, Emilien Macchi <emilien(a)redhat.com> wrote:
Before going down to my specific context, I would like to raise that
we're
having more and more dependencies outside of OpenStack (Ceph, MariaDB,
Ansible, OVS, etc); and we know that all of them can easily "break"
projects like TripleO and therefore cause problems in the production chain.
I would like to understand if we have a common path for these projects, to
include them in delorean and in our machinery so we can easily test them in
RDO CI (and stop manual testing like we are doing now).
In my previous experience, we would backport newer versions of libvirt,
OVS, Ceph, and etc to the ubuntu cloud archive for users who are still on
the LTS. Initially it was a bit of a hassle because we would find something
that something that would break like an older library or a dependency that
is not in Xenial or a feature would change that we were not expecting.
However, once we release we were also taking responsibility of taking care
of things like updating newer versions of the software due to CVEs or
backports. This was automated as well, but it is something to be aware of
and mindful of.
We all know that we can't and don't want to consume EPEL but for some
projects it's going to be problematic, I'll discuss about one of them a bit
later in this email.
My proposal is the following:
- 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
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.
I think it would be a good idea to being conservative at the beginning of
the cycle and then taking it on a case by case basis. Over time we
automated the importation into the archive because we became more familiar
with what we had.
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).
it should be pretty easy to test them all together. I think you are going
to have a version matrix like what is done in tripleo with the feature sets.
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).
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.
I think you would follow upstream processes in consuming ansible.
Discussion is open, thanks for participating,
--
Emilien Macchi
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org