[openstack-dev] [TripleO] TripleO Deep dive sessions for CI topics.
Carlos Camacho Gonzalez
ccamacho at redhat.com
Thu Aug 25 11:44:36 UTC 2016
Yeahp I think in case of debugging upstream submissions (on CI)
it's the same process of debugging locally those errors,
in which case, the only missing part there I think can be
just to point where to see when reading CI logs.
What I think will be a bigger challenge it's about to
teach other people to understand and master how
TripleO CI works, including how to define new jobs,
where to see when we have a package conflict
breaking the build, or how to detect infra issues
among other topics. (This won't be for debugging
submissions, instead to debug when we have CI
Not sure if it's needed a deep historical understanding about
how CI was built and about how it's actually working
but I think this will make people love a little bit more
I'll add more items to the Etherpad, let's see how many people
On Wed, Aug 24, 2016 at 8:24 PM, James Slagle <james.slagle at gmail.com>
> On Wed, Aug 24, 2016 at 12:17 PM, Carlos Camacho Gonzalez
> <ccamacho at redhat.com> wrote:
> > Hello guys!
> > I will like to ask you a question related to future TripleO deep dive
> > sessions.
> > What about having a specific series for CI? I read some people kind of
> > “complaining” on IRC when CI does not work properly and assuming that
> > care of CI is part of everyone's work let's try go have more eyes on CI
> > (including me).
> > I believe if more people its actually able to debug “real” CI issues we
> > be able to decrease the amount of work that these tasks take from the
> > I added to https://etherpad.openstack.org/p/tripleo-deep-dive-topics a
> > section with some topics, feel free to add/edit items and let's discuss
> > on the weekly meeting to see if in a mid-term we can have some
> > to CI.
> I think this is a great idea. What I'd like to know before planning
> something like this is what specific things do people need help on
> when it comes to debugging failed jobs. How have folks tried to debug
> jobs that have failed and gotten stuck?
> Most of the time it is looking at logs and trying to reproduce
> locally. I'd be happy to show that, but I feel like we've already
> covered that to a large degree. So, I'd like to dig a little more into
> specific ways people get stuck with failures and then we can directly
> address those.
> Ideally, a root cause of a failure could always be found, but that is
> just not going to be the case given other constraints. It often comes
> down to what one is able to reproduce locally, and how to mitigate the
> issues as best we can (see email I just sent for an example).
> Let me know or add the specifics to the etherpad and I'll pull
> something together if there are no other volunteers :).
> -- James Slagle
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev