[opensuse-kubic] Improving Release Coordination of Kubernetes componants
Hi all, As discussed with some regular contributors already, today we realised we've made a little faux pas with our release coordination. We started shipping CoreDNS 1.6.3 containers a week ago, which meant our existing CoreDNS 1.3.1 containers got deleted today. But we haven't shipped k8s 1.16.x yet, which will use those CoreDNS 1.6.3 containers. Every current Kubic snapshot needs CoreDNS 1.3.1, which dissapeared today. Fabian and Dominique have got things working again but I'm thinking how to avoid this situation in the future.
From now on I intend to take extreme care to only submit the following 3 packages in conjunction with each other, and expect them to be staged together:
coredns cri-tools kubernetes If anyone is submitting any of the above 3 packages to Factory instead of me, please make sure you're only doing so in coordination with appropriate version bumps in the other packages. Are there other packages in Kubic that need that similar treatment & coordination? Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg HRB 247165, AG München GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
Hi, Am Mittwoch, 9. Oktober 2019, 12:17:30 CEST schrieb Richard Brown:
Hi all,
As discussed with some regular contributors already, today we realised we've made a little faux pas with our release coordination.
We started shipping CoreDNS 1.6.3 containers a week ago, which meant our existing CoreDNS 1.3.1 containers got deleted today.
But we haven't shipped k8s 1.16.x yet, which will use those CoreDNS 1.6.3 containers. Every current Kubic snapshot needs CoreDNS 1.3.1, which dissapeared today.
Fabian and Dominique have got things working again but I'm thinking how to avoid this situation in the future.
By restricting which container images/tags are accessible from openQA tests. Currently if a container image is not found in the staging/totest project on registry.opensuse.org, it falls back silently to use the released images. This means that inconsistencies such as this one aren't noticed. Once this situation is completely fixed I'll try to get the tests running fine with the fallback only applying to whole images instead of tags. So if kubic/coredns is in a staging, only the tags provided by that one are accessible and not any from the released project. opensuse/leap:15.1 would still be accessible from TW stagings then.
From now on I intend to take extreme care to only submit the following 3 packages in conjunction with each other, and expect them to be staged together:
coredns cri-tools kubernetes
If anyone is submitting any of the above 3 packages to Factory instead of me, please make sure you're only doing so in coordination with appropriate version bumps in the other packages.
Are there other packages in Kubic that need that similar treatment & coordination?
Cilium has the same issue AFAIK. Cheers, Fabian
Regards,
-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Wed, 2019-10-09 at 13:23 +0200, Fabian Vogt wrote:
Hi,
Am Mittwoch, 9. Oktober 2019, 12:17:30 CEST schrieb Richard Brown:
Hi all,
As discussed with some regular contributors already, today we realised we've made a little faux pas with our release coordination.
We started shipping CoreDNS 1.6.3 containers a week ago, which meant our existing CoreDNS 1.3.1 containers got deleted today.
But we haven't shipped k8s 1.16.x yet, which will use those CoreDNS 1.6.3 containers. Every current Kubic snapshot needs CoreDNS 1.3.1, which dissapeared today.
Fabian and Dominique have got things working again but I'm thinking how to avoid this situation in the future.
By restricting which container images/tags are accessible from openQA tests. Currently if a container image is not found in the staging/totest project on registry.opensuse.org, it falls back silently to use the released images. This means that inconsistencies such as this one aren't noticed.
Once this situation is completely fixed I'll try to get the tests running fine with the fallback only applying to whole images instead of tags. So if kubic/coredns is in a staging, only the tags provided by that one are accessible and not any from the released project. opensuse/leap:15.1 would still be accessible from TW stagings then.
This proposal will work for coredns and probably cilium It wont work for cri-tools which we also messed up the release coordination recently ;)
From now on I intend to take extreme care to only submit the following 3 packages in conjunction with each other, and expect them to be staged together:
coredns cri-tools kubernetes
If anyone is submitting any of the above 3 packages to Factory instead of me, please make sure you're only doing so in coordination with appropriate version bumps in the other packages.
Are there other packages in Kubic that need that similar treatment & coordination?
Cilium has the same issue AFAIK.
Cheers, Fabian
Regards,
-- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg HRB 247165, AG München GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
participants (2)
-
Fabian Vogt -
Richard Brown