Hi Marios, On Fri, May 14, 2021 at 8:10 PM Marios Andreou <marios@redhat.com> wrote:
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 https://zuul.opendev.org/t/openstack/builds?job_name=puppet-nova-tripleo-standalone&project=openstack/puppet-nova 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. [4] https://github.com/openstack/puppet-openstack-integration/blob/master/zuul.d... [5] https://github.com/openstack/puppet-nova/blob/master/.zuul.yaml
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. https://review.opendev.org/q/topic:%22tripleo-tempest%22+(status:open) 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