On Fri, May 14, 2021 at 8:40 AM Takashi Kajinami <tkajinam@redhat.com> wrote:
>
> Hi team,
>
Hi Takashi
> As you know, we currently have TripleO jobs in some of the puppet repos
> to ensure a change in puppet side doesn't break TripleO which consumes
> some of the modules.
in case it isn't clear and for anyone else reading, you are referring
to things like [1].
This is a nitfixing but puppet-pacemaker is a repo under the TripleO project.
I intend a job like
which is maintained under puppet repos.
>
> Because these jobs hugely depend on the job definitions in TripleO repos,
> I'm wondering whether we can invite a few cores from the TripleO CI team
> to the puppet-openstack core group to maintain these jobs.
> I expect the scope here is very limited to tripleo job definitions and doesn't
> expect any +2 for other parts.
>
> I'd be nice if I can hear any thoughts on this topic.
Main question is what kind of maintenance do you have in mind? Is it
that these jobs are breaking often and they need fixes in the
puppet-repos themselves so we need more cores there? (though... I
would expect the fixes to be needed in tripleo-ci where the job
definitions are, unless the repos are overriding those definitions)?
We define our own base tripleo-puppet-ci-centos-8-standalone job[4] and
each puppet module defines their own tripleo job[5] by overriding the base job,
so that we can define some basic items like irellevant files or voting status
for all puppet modules in a single place.
Or is it that you don't have enough folks to get fixes merged so this
is mostly about growing the pool of reviewers?
Yes. My main intention is to have more reviewers so that we can fix our CI jobs timely.
Actually the proposal came to my mind when I was implementing the following changes
to solve very frequent job timeouts which we currently observe in puppet-nova wallaby.
IMO these changes need more attention from TripleO's perspective rather than puppet's
perspective.
In the past when we introduced content provider jobs, we ended up with a bunch of patches
submitted to both tripleo jobs and puppet jobs. Having some people from TripleO team
would help moving forward such a transition more smoothly.
In the past we have had three people (Alex, Emilien and I) involved in both TripleO and puppet
but since Emilien has shifted this focus, we have now 2 activities left.
Additional one or two people would help us move patches forward more efficiently.
(Since I can't approve my own patch.)
I think limiting the scope to just the contents of zuul.d/ or
.zuul.yaml can work; we already have a trust based system in TripleO
with some cores only expected to exercise their voting rights in
particular repos even though they have full voting rights across all
tripleo repos).
Are you able to join our next tripleo-ci community call? It is on
Tuesday 1330 UTC @ [2] and we use [3] for the agenda. If you can join,
perhaps we can work something out depending on what you need.
Otherwise no problem let's continue to discuss here
Sure. I can join and bring up this topic.
I'll keep this thread to hear some opinions from the puppet side as well.
regards, marios
[1] https://zuul.opendev.org/t/openstack/builds?job_name=tripleo-ci-centos-8-scenario004-standalone&project=openstack/puppet-pacemaker
[2] https://meet.google.com/bqx-xwht-wky
[3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
>
> Thank you,
> Takashi
>