[puppet][tripleo] Inviting tripleo CI cores to maintain tripleo jobs ?
Hi team,
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.
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.
Thank you, Takashi
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].
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)?
Or is it that you don't have enough folks to get fixes merged so this is mostly about growing the pool of reviewers?
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
regards, marios
[1] https://zuul.opendev.org/t/openstack/builds?job_name=tripleo-ci-centos-8-sce... [2] https://meet.google.com/bqx-xwht-wky [3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
Thank you, Takashi
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-sta... 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-sce... [2] https://meet.google.com/bqx-xwht-wky [3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
Thank you, Takashi
On Fri, May 14, 2021 at 2:46 PM Takashi Kajinami tkajinam@redhat.com wrote:
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-sta... 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... [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-sce... [2] https://meet.google.com/bqx-xwht-wky [3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
Thank you, Takashi
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%2...)
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@redhat.com wrote:
On Fri, May 14, 2021 at 2:46 PM Takashi Kajinami tkajinam@redhat.com wrote:
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-sta...
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...
[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-sce...
[2] https://meet.google.com/bqx-xwht-wky [3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
Thank you, Takashi
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@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%2...)
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@redhat.com wrote:
On Fri, May 14, 2021 at 2:46 PM Takashi Kajinami tkajinam@redhat.com wrote:
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-sta...
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...
[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-sce...
[2] https://meet.google.com/bqx-xwht-wky [3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
Thank you, Takashi
Thanks Takashi!
On Wed, May 26, 2021 at 6:44 PM Takashi Kajinami tkajinam@redhat.com wrote:
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@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%2...)
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@redhat.com wrote:
On Fri, May 14, 2021 at 2:46 PM Takashi Kajinami tkajinam@redhat.com wrote:
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-sta...
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...
[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-sce...
[2] https://meet.google.com/bqx-xwht-wky [3] https://hackmd.io/MMg4WDbYSqOQUhU2Kj8zNg?both
Thank you, Takashi
Hello Takashi,
From an Puppet OpenStack core perspective being outside of RedHat
I have no problem with it since the mentioned trust from the TripleO side is to only approve patches directly related to it.
Hopefully the person becomes interested and starts working on all the Puppet parts as well :)
Best regards Tobias
On 14 May 2021, at 07:38, Takashi Kajinami tkajinam@redhat.com wrote:
Hi team,
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.
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.
Thank you, Takashi
participants (4)
-
Marios Andreou
-
Takashi Kajinami
-
Tobias Urdin
-
Wesley Hayutin