Greetings,
The tripleo ci team has identified a handful of patches that we'd like to land prior to Nov 2, the day docker.io goes away. We've hit some new bugs and have also tuned a few things to try and make sure we can get patches to merge.
Our current focus is across master, victoria, ussuri and centos-8 train, and queens while reducing coverage in rocky and stein.
A list of the prioritized gerrit reviews can be found here: https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view
The entire topic can be found here: https://review.opendev.org/#/q/topic:new-ci-job
Thanks all.
On 10/30/20 6:31 PM, Wesley Hayutin wrote:
Greetings,
The tripleo ci team has identified a handful of patches that we'd like to land prior to Nov 2, the day docker.io http://docker.io goes away. We've hit some new bugs and have also tuned a few things to try and make sure we can get patches to merge.
Our current focus is across master, victoria, ussuri and centos-8 train, and queens while reducing coverage in rocky and stein.
A list of the prioritized gerrit reviews can be found here: https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view
The entire topic can be found here: https://review.opendev.org/#/q/topic:new-ci-job
In that list there are patches to puppet modules and openstack services what run a single standalone tripleo CI job. I don't think creating an extra provider job to run a single consumer job sounds reasonable.
Thanks all.
On Tue, Nov 3, 2020 at 6:20 AM Bogdan Dobrelya bdobreli@redhat.com wrote:
On 10/30/20 6:31 PM, Wesley Hayutin wrote:
Greetings,
The tripleo ci team has identified a handful of patches that we'd like to land prior to Nov 2, the day docker.io http://docker.io goes
away.
We've hit some new bugs and have also tuned a few things to try and make sure we can get patches to merge.
Our current focus is across master, victoria, ussuri and centos-8 train, and queens while reducing coverage in rocky and stein.
A list of the prioritized gerrit reviews can be found here: https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view
The entire topic can be found here: https://review.opendev.org/#/q/topic:new-ci-job
In that list there are patches to puppet modules and openstack services what run a single standalone tripleo CI job. I don't think creating an extra provider job to run a single consumer job sounds reasonable.
Thanks all.
So our first pass there I think should be a content-provider. However we could potentially drop the content-provider and override docker.io -> quay.io as well. We are not certain yet how well quay.io will perform so we're being cautious atm.
-- Best regards, Bogdan Dobrelya, Irc #bogdando
On Tue, Nov 3, 2020 at 5:31 PM Wesley Hayutin whayutin@redhat.com wrote:
On Tue, Nov 3, 2020 at 6:20 AM Bogdan Dobrelya bdobreli@redhat.com wrote:
On 10/30/20 6:31 PM, Wesley Hayutin wrote:
Greetings,
The tripleo ci team has identified a handful of patches that we'd like to land prior to Nov 2, the day docker.io http://docker.io goes
away.
We've hit some new bugs and have also tuned a few things to try and make sure we can get patches to merge.
Our current focus is across master, victoria, ussuri and centos-8
train,
and queens while reducing coverage in rocky and stein.
A list of the prioritized gerrit reviews can be found here: https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view
The entire topic can be found here: https://review.opendev.org/#/q/topic:new-ci-job
In that list there are patches to puppet modules and openstack services what run a single standalone tripleo CI job. I don't think creating an extra provider job to run a single consumer job sounds reasonable.
Thanks all.
So our first pass there I think should be a content-provider. However we could potentially drop the content-provider and override docker.io -> quay.io as well. We are not certain yet how well quay.io will perform so we're being cautious atm.
or as currently discussing with sshnaidm on irc the job itself can build the containers instead of having a content provider do that
17:38 < sshnaidm|rover> maybe in puppet repos we will just build containers? 17:38 < sshnaidm|rover> it's one standalone job there only, irrc 17:38 < sshnaidm|rover> I think bogdan is right 17:39 < marios> sshnaidm|rover: but is it worth it to special case that? in the end it is still just 'build one set of containers' does it matter if it happens in a content provider or in the job itself? I guess it depends how stable are the cotnent providers and the answer is 'not always' ... :/ 17:40 < sshnaidm|rover> marios, it will remain one job there, not two 17:40 < sshnaidm|rover> and no need to change layouts, just adding one variable 17:40 < sshnaidm|rover> these repos anyway don't expect to run anything else from tripleo 17:41 < sshnaidm|rover> ~10 repos * N branches, will save us a little work.. 17:41 < marios> sshnaidm|rover: ack ... if it is easy enough to have that as special case then OK. and yes having one job instead of 2 (one content provider) brings its own benefits
-- Best regards, Bogdan Dobrelya, Irc #bogdando
Hi,
On Tue, Nov 3, 2020 at 9:19 PM Marios Andreou marios@redhat.com wrote:
On Tue, Nov 3, 2020 at 5:31 PM Wesley Hayutin whayutin@redhat.com wrote:
On Tue, Nov 3, 2020 at 6:20 AM Bogdan Dobrelya bdobreli@redhat.com wrote:
On 10/30/20 6:31 PM, Wesley Hayutin wrote:
Greetings,
The tripleo ci team has identified a handful of patches that we'd like to land prior to Nov 2, the day docker.io http://docker.io goes away. We've hit some new bugs and have also tuned a few things to try and make sure we can get patches to merge.
Our current focus is across master, victoria, ussuri and centos-8 train, and queens while reducing coverage in rocky and stein.
A list of the prioritized gerrit reviews can be found here: https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view
The entire topic can be found here: https://review.opendev.org/#/q/topic:new-ci-job
In that list there are patches to puppet modules and openstack services what run a single standalone tripleo CI job. I don't think creating an extra provider job to run a single consumer job sounds reasonable.
Thanks all.
So our first pass there I think should be a content-provider. However we could potentially drop the content-provider and override docker.io -> quay.io as well. We are not certain yet how well quay.io will perform so we're being cautious atm.
or as currently discussing with sshnaidm on irc the job itself can build the containers instead of having a content provider do that
17:38 < sshnaidm|rover> maybe in puppet repos we will just build containers? 17:38 < sshnaidm|rover> it's one standalone job there only, irrc 17:38 < sshnaidm|rover> I think bogdan is right 17:39 < marios> sshnaidm|rover: but is it worth it to special case that? in the end it is still just 'build one set of containers' does it matter if it happens in a content provider or in the job itself? I guess it depends how stable are the cotnent providers and the answer is 'not always' ... :/ 17:40 < sshnaidm|rover> marios, it will remain one job there, not two 17:40 < sshnaidm|rover> and no need to change layouts, just adding one variable 17:40 < sshnaidm|rover> these repos anyway don't expect to run anything else from tripleo 17:41 < sshnaidm|rover> ~10 repos * N branches, will save us a little work.. 17:41 < marios> sshnaidm|rover: ack ... if it is easy enough to have that as special case then OK. and yes having one job instead of 2 (one content provider) brings its own benefits
I raised it in https://review.opendev.org/#/c/760420 couple of days ago, just a note for standalone it should work fine but for other job like undercloud ones which also runs in some projects would need to add support for container-builds via build_container_images: true for those non provider jobs.
-- Best regards, Bogdan Dobrelya, Irc #bogdando
Thanks and Regards Yatin Karel
participants (4)
-
Bogdan Dobrelya
-
Marios Andreou
-
Wesley Hayutin
-
Yatin Karel