Open Stack

Hi Marios,

On Fri, May 14, 2021 at 8:10 PM Marios Andreou <marios at redhat.com> wrote:

> On Fri, May 14, 2021 at 8:40 AM Takashi Kajinami <tkajinam at 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/tripleo.yaml
[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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210514/a683309c/attachment.html>