Open Stack

Because we haven't heard any objections for one week, I invited the three
people
I mentioned to the puppet-manager-core group.

On Tue, May 18, 2021 at 11:42 PM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Thank you, Marios and the team for your time in the meeting.
>
> Based on our discussion, I'll nominate the following three volunteers from
> tripleo core team
> to the puppet-openstack core team.
>  - Marios Andreou
>  - Ronelle Landy
>  - Wes Hayutin
>
> Their scope of +2 will be limited to tripleo job definitions (which are
> written in .zuul.yaml or zuul.d/*.yaml) at this moment.
>
> I've not received any objections so far (Thank you Tobias for sharing your
> thoughts !) but will wait for one week
> to be open for any feedback from the other cores or people around.
>
> My current plan is to add a specific hashtag so that these reviewers can
> easily find the related changes like [1]
> but please let me know if anybody has preference.
> [1]
> https://review.opendev.org/q/hashtag:%22puppet-tripleo-job%22+(status:open%20OR%20status:merged)
>
> P.S.
> I received some interest about maintaining puppet modules (especially our
> own integration jobs),
> so will have some people involved in that part as well.
>
>
> On Fri, May 14, 2021 at 8:57 PM Marios Andreou <marios at redhat.com> wrote:
>
>> On Fri, May 14, 2021 at 2:46 PM Takashi Kajinami <tkajinam at redhat.com>
>> wrote:
>> >
>> > 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.
>> >
>>
>> ack thanks for the clarification ;) makes more sense now
>>
>> >>
>> >>
>> >> >
>> >> > 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.
>> >
>> >
>>
>> ok thanks look forward to discussing on Tuesday then,
>>
>> regards, marios
>>
>>
>> >>
>> >>
>> >> 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/20210527/9693380b/attachment-0001.html>