[PATCH 0/2] ci: Update to Fedora 39
Green pipeline: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1106643445 Michal Prívozník (2): ci: integration: Switch upstream integration tests to Fedora 39 ci: Update Alpine and Fedora and regenerate ci/buildenv/{alpine-317.sh => alpine-319.sh} | 0 ci/buildenv/{fedora-37.sh => fedora-39.sh} | 0 ...e-317.Dockerfile => alpine-319.Dockerfile} | 2 +- ...ora-37.Dockerfile => fedora-39.Dockerfile} | 2 +- ci/gitlab/builds.yml | 64 +++++++-------- ci/gitlab/containers.yml | 18 ++--- ci/integration.yml | 80 +++++++++---------- ci/manifest.yml | 18 ++--- 8 files changed, 92 insertions(+), 92 deletions(-) rename ci/buildenv/{alpine-317.sh => alpine-319.sh} (100%) rename ci/buildenv/{fedora-37.sh => fedora-39.sh} (100%) rename ci/containers/{alpine-317.Dockerfile => alpine-319.Dockerfile} (98%) rename ci/containers/{fedora-37.Dockerfile => fedora-39.Dockerfile} (98%) -- 2.41.0
Currently, Fedora 37 and 38 is used. The former is now EOL since there's new release. Switch 37 to 39 then. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/integration.yml | 80 +++++++++++++++++++++++----------------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/ci/integration.yml b/ci/integration.yml index 25788099b5..8b66a8c688 100644 --- a/ci/integration.yml +++ b/ci/integration.yml @@ -81,46 +81,6 @@ centos-stream-9-tests-local-env: artifacts: true -.fedora-37-tests: - variables: - # needed by libvirt-gitlab-executor - DISTRO: fedora-37 - # can be overridden in forks to set a different runner tag - LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host - tags: - - $LIBVIRT_CI_INTEGRATION_RUNNER_TAG - -fedora-37-tests-prebuilt-env: - extends: - - .integration_tests_prebuilt_env - - .fedora-37-tests - needs: - - x86_64-fedora-37-prebuilt-env - - project: libvirt/libvirt-perl - job: x86_64-fedora-37-prebuilt-env - ref: master - artifacts: true - - project: libvirt/libvirt-python - job: x86_64-fedora-37-prebuilt-env - ref: master - artifacts: true - -fedora-37-tests-local-env: - extends: - - .integration_tests_local_env - - .fedora-37-tests - needs: - - x86_64-fedora-37-local-env - - project: libvirt/libvirt-perl - job: x86_64-fedora-37-prebuilt-env - ref: master - artifacts: true - - project: libvirt/libvirt-python - job: x86_64-fedora-37-prebuilt-env - ref: master - artifacts: true - - .fedora-38-tests: variables: # needed by libvirt-gitlab-executor @@ -199,3 +159,43 @@ fedora-38-upstream-qemu-tests-local-env: job: x86_64-fedora-38-prebuilt-env ref: master artifacts: true + + +.fedora-39-tests: + variables: + # needed by libvirt-gitlab-executor + DISTRO: fedora-39 + # can be overridden in forks to set a different runner tag + LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host + tags: + - $LIBVIRT_CI_INTEGRATION_RUNNER_TAG + +fedora-39-tests-prebuilt-env: + extends: + - .integration_tests_prebuilt_env + - .fedora-39-tests + needs: + - x86_64-fedora-39-prebuilt-env + - project: libvirt/libvirt-perl + job: x86_64-fedora-39-prebuilt-env + ref: master + artifacts: true + - project: libvirt/libvirt-python + job: x86_64-fedora-39-prebuilt-env + ref: master + artifacts: true + +fedora-39-tests-local-env: + extends: + - .integration_tests_local_env + - .fedora-39-tests + needs: + - x86_64-fedora-39-local-env + - project: libvirt/libvirt-perl + job: x86_64-fedora-39-prebuilt-env + ref: master + artifacts: true + - project: libvirt/libvirt-python + job: x86_64-fedora-39-prebuilt-env + ref: master + artifacts: true -- 2.41.0
On Thu, Dec 14, 2023 at 09:28:16AM +0100, Michal Privoznik wrote:
Currently, Fedora 37 and 38 is used. The former is now EOL since there's new release. Switch 37 to 39 then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/integration.yml | 80 +++++++++++++++++++++++----------------------- 1 file changed, 40 insertions(+), 40 deletions(-)
Patch looks good, but I don't think we can push it until the Fedora 39 runner used for integration tests has been created, and AFAIK that's a manual process. Erik, I know that you've taken care of this so far. Has the process been documented anywhere? Is it something that people other than you can deal with? -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Dec 15, 2023 at 02:26:11AM -0800, Andrea Bolognani wrote:
On Thu, Dec 14, 2023 at 09:28:16AM +0100, Michal Privoznik wrote:
Currently, Fedora 37 and 38 is used. The former is now EOL since there's new release. Switch 37 to 39 then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/integration.yml | 80 +++++++++++++++++++++++----------------------- 1 file changed, 40 insertions(+), 40 deletions(-)
Patch looks good, but I don't think we can push it until the Fedora 39 runner used for integration tests has been created, and AFAIK that's a manual process.
Erik, I know that you've taken care of this so far. Has the process been documented anywhere? Is it something that people other than you can deal with?
Uhm, yes, it is documented, however that docs resource isn't public as it runs on a private infra. Yes, Cleber and Jan should be able to do that too as they have access. I'd do that for you myself no problem, but I'm already on PTO since today. If this isn't a blocker for you until the new year, then I'll take care of it then. Erik
On Fri, Dec 15, 2023 at 06:06:54PM +0100, Erik Skultety wrote:
On Fri, Dec 15, 2023 at 02:26:11AM -0800, Andrea Bolognani wrote:
On Thu, Dec 14, 2023 at 09:28:16AM +0100, Michal Privoznik wrote:
Currently, Fedora 37 and 38 is used. The former is now EOL since there's new release. Switch 37 to 39 then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/integration.yml | 80 +++++++++++++++++++++++----------------------- 1 file changed, 40 insertions(+), 40 deletions(-)
Patch looks good, but I don't think we can push it until the Fedora 39 runner used for integration tests has been created, and AFAIK that's a manual process.
Erik, I know that you've taken care of this so far. Has the process been documented anywhere? Is it something that people other than you can deal with?
Uhm, yes, it is documented, however that docs resource isn't public as it runs on a private infra. Yes, Cleber and Jan should be able to do that too as they have access. I'd do that for you myself no problem, but I'm already on PTO since today. If this isn't a blocker for you until the new year, then I'll take care of it then.
I don't think it's a blocker. And it's fine if the documentation is internal, as long as there's more than one person that can push things forward when needed. -- Andrea Bolognani / Red Hat / Virtualization
On 12/15/23 18:06, Erik Skultety wrote:
On Fri, Dec 15, 2023 at 02:26:11AM -0800, Andrea Bolognani wrote:
On Thu, Dec 14, 2023 at 09:28:16AM +0100, Michal Privoznik wrote:
Currently, Fedora 37 and 38 is used. The former is now EOL since there's new release. Switch 37 to 39 then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/integration.yml | 80 +++++++++++++++++++++++----------------------- 1 file changed, 40 insertions(+), 40 deletions(-)
Patch looks good, but I don't think we can push it until the Fedora 39 runner used for integration tests has been created, and AFAIK that's a manual process.
Erik, I know that you've taken care of this so far. Has the process been documented anywhere? Is it something that people other than you can deal with?
Uhm, yes, it is documented, however that docs resource isn't public as it runs on a private infra. Yes, Cleber and Jan should be able to do that too as they have access. I'd do that for you myself no problem, but I'm already on PTO since today. If this isn't a blocker for you until the new year, then I'll take care of it then.
Erik
Gentle ping. Although, libvirt-ci moved meanwhile and dropped freebsd-12 in favor of freebsd-14. Which is exactly what we need to fix failing CI: https://gitlab.com/libvirt/libvirt/-/pipelines/1125194120 Michal
On Wed, Jan 03, 2024 at 09:42:01AM +0100, Michal Prívozník wrote:
On 12/15/23 18:06, Erik Skultety wrote:
On Fri, Dec 15, 2023 at 02:26:11AM -0800, Andrea Bolognani wrote:
On Thu, Dec 14, 2023 at 09:28:16AM +0100, Michal Privoznik wrote:
Currently, Fedora 37 and 38 is used. The former is now EOL since there's new release. Switch 37 to 39 then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/integration.yml | 80 +++++++++++++++++++++++----------------------- 1 file changed, 40 insertions(+), 40 deletions(-)
Patch looks good, but I don't think we can push it until the Fedora 39 runner used for integration tests has been created, and AFAIK that's a manual process.
Erik, I know that you've taken care of this so far. Has the process been documented anywhere? Is it something that people other than you can deal with?
Uhm, yes, it is documented, however that docs resource isn't public as it runs on a private infra. Yes, Cleber and Jan should be able to do that too as they have access. I'd do that for you myself no problem, but I'm already on PTO since today. If this isn't a blocker for you until the new year, then I'll take care of it then.
Erik
Gentle ping.
Although, libvirt-ci moved meanwhile and dropped freebsd-12 in favor of freebsd-14. Which is exactly what we need to fix failing CI:
I upgraded the existing images and added Fedora-39 base image to the bare metal runners. Give it a try and let me know if anything's still failing. Erik
New Alpine and Fedora releases were added to libvirt-ci (3.19 and 39, respectively) and old ones were removed. Update the manifest file and regenerate the rest. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- ci/buildenv/{alpine-317.sh => alpine-319.sh} | 0 ci/buildenv/{fedora-37.sh => fedora-39.sh} | 0 ...e-317.Dockerfile => alpine-319.Dockerfile} | 2 +- ...ora-37.Dockerfile => fedora-39.Dockerfile} | 2 +- ci/gitlab/builds.yml | 64 +++++++++---------- ci/gitlab/containers.yml | 18 +++--- ci/manifest.yml | 18 +++--- 7 files changed, 52 insertions(+), 52 deletions(-) rename ci/buildenv/{alpine-317.sh => alpine-319.sh} (100%) rename ci/buildenv/{fedora-37.sh => fedora-39.sh} (100%) rename ci/containers/{alpine-317.Dockerfile => alpine-319.Dockerfile} (98%) rename ci/containers/{fedora-37.Dockerfile => fedora-39.Dockerfile} (98%) diff --git a/ci/buildenv/alpine-317.sh b/ci/buildenv/alpine-319.sh similarity index 100% rename from ci/buildenv/alpine-317.sh rename to ci/buildenv/alpine-319.sh diff --git a/ci/buildenv/fedora-37.sh b/ci/buildenv/fedora-39.sh similarity index 100% rename from ci/buildenv/fedora-37.sh rename to ci/buildenv/fedora-39.sh diff --git a/ci/containers/alpine-317.Dockerfile b/ci/containers/alpine-319.Dockerfile similarity index 98% rename from ci/containers/alpine-317.Dockerfile rename to ci/containers/alpine-319.Dockerfile index 461b1a7482..b49f348805 100644 --- a/ci/containers/alpine-317.Dockerfile +++ b/ci/containers/alpine-319.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM docker.io/library/alpine:3.17 +FROM docker.io/library/alpine:3.19 RUN apk update && \ apk upgrade && \ diff --git a/ci/containers/fedora-37.Dockerfile b/ci/containers/fedora-39.Dockerfile similarity index 98% rename from ci/containers/fedora-37.Dockerfile rename to ci/containers/fedora-39.Dockerfile index 5177f8db1a..700fe64d2f 100644 --- a/ci/containers/fedora-37.Dockerfile +++ b/ci/containers/fedora-39.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:37 +FROM registry.fedoraproject.org/fedora:39 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index 4cb338fac9..5cc904ffb7 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -51,22 +51,22 @@ x86_64-almalinux-8-clang-local-env: RPM: skip -x86_64-alpine-317-prebuilt-env: +x86_64-alpine-319-prebuilt-env: extends: .native_build_job_prebuilt_env needs: - - job: x86_64-alpine-317-container + - job: x86_64-alpine-319-container optional: true allow_failure: false variables: - NAME: alpine-317 + NAME: alpine-319 -x86_64-alpine-317-local-env: +x86_64-alpine-319-local-env: extends: .native_build_job_local_env needs: [] allow_failure: false variables: - IMAGE: docker.io/library/alpine:3.17 - NAME: alpine-317 + IMAGE: docker.io/library/alpine:3.19 + NAME: alpine-319 x86_64-alpine-edge-prebuilt-env: @@ -233,32 +233,6 @@ x86_64-debian-sid-local-env: NAME: debian-sid -x86_64-fedora-37-prebuilt-env: - extends: .native_build_job_prebuilt_env - needs: - - job: x86_64-fedora-37-container - optional: true - allow_failure: false - variables: - NAME: fedora-37 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - -x86_64-fedora-37-local-env: - extends: .native_build_job_local_env - needs: [] - allow_failure: false - variables: - IMAGE: registry.fedoraproject.org/fedora:37 - NAME: fedora-37 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - - x86_64-fedora-38-prebuilt-env: extends: .native_build_job_prebuilt_env needs: @@ -285,6 +259,32 @@ x86_64-fedora-38-local-env: - libvirt-rpms +x86_64-fedora-39-prebuilt-env: + extends: .native_build_job_prebuilt_env + needs: + - job: x86_64-fedora-39-container + optional: true + allow_failure: false + variables: + NAME: fedora-39 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + +x86_64-fedora-39-local-env: + extends: .native_build_job_local_env + needs: [] + allow_failure: false + variables: + IMAGE: registry.fedoraproject.org/fedora:39 + NAME: fedora-39 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + + x86_64-fedora-rawhide-prebuilt-env: extends: .native_build_job_prebuilt_env needs: diff --git a/ci/gitlab/containers.yml b/ci/gitlab/containers.yml index 2463d1a5aa..add5e2360f 100644 --- a/ci/gitlab/containers.yml +++ b/ci/gitlab/containers.yml @@ -14,11 +14,11 @@ x86_64-almalinux-8-container: NAME: almalinux-8 -x86_64-alpine-317-container: +x86_64-alpine-319-container: extends: .container_job allow_failure: false variables: - NAME: alpine-317 + NAME: alpine-319 x86_64-alpine-edge-container: @@ -64,13 +64,6 @@ x86_64-debian-sid-container: NAME: debian-sid -x86_64-fedora-37-container: - extends: .container_job - allow_failure: false - variables: - NAME: fedora-37 - - x86_64-fedora-38-container: extends: .container_job allow_failure: false @@ -78,6 +71,13 @@ x86_64-fedora-38-container: NAME: fedora-38 +x86_64-fedora-39-container: + extends: .container_job + allow_failure: false + variables: + NAME: fedora-39 + + x86_64-fedora-rawhide-container: extends: .container_job allow_failure: true diff --git a/ci/manifest.yml b/ci/manifest.yml index afb1fa007d..85f6b9d878 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -19,7 +19,7 @@ targets: RPM: skip CC: clang - alpine-317: x86_64 + alpine-319: x86_64 alpine-edge: jobs: @@ -152,14 +152,6 @@ targets: containers: false builds: false - fedora-37: - jobs: - - arch: x86_64 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - fedora-38: jobs: - arch: x86_64 @@ -173,6 +165,14 @@ targets: - arch: mingw64 + fedora-39: + jobs: + - arch: x86_64 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + fedora-rawhide: jobs: - arch: x86_64 -- 2.41.0
On Thu, Dec 14, 2023 at 09:28:15AM +0100, Michal Privoznik wrote:
Green pipeline:
https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1106643445
Michal Prívozník (2): ci: integration: Switch upstream integration tests to Fedora 39 ci: Update Alpine and Fedora and regenerate
Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Dec 14, 2023 at 09:28:15 +0100, Michal Privoznik wrote:
Green pipeline:
https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1106643445
Michal Prívozník (2): ci: integration: Switch upstream integration tests to Fedora 39
For future reference, please note that the integration test suite makes use of artifacts from libvirt/libvirt-perl and libvirt/libvirt-python projects, which thus must be bumped to new Fedora prior to bumping the main project. I've approved and merged https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/109 and posted https://gitlab.com/libvirt/libvirt-python/-/merge_requests/130 which will need to be approved. This should fix the following integration test failure: https://gitlab.com/libvirt/libvirt/-/jobs/5880074910
On Mon, Jan 08, 2024 at 10:35:53 +0100, Peter Krempa wrote:
On Thu, Dec 14, 2023 at 09:28:15 +0100, Michal Privoznik wrote:
Green pipeline:
https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1106643445
Michal Prívozník (2): ci: integration: Switch upstream integration tests to Fedora 39
For future reference, please note that the integration test suite makes use of artifacts from libvirt/libvirt-perl and libvirt/libvirt-python projects, which thus must be bumped to new Fedora prior to bumping the main project.
I've approved and merged
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/109
and posted
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/130
which will need to be approved.
This should fix the following integration test failure:
Grrr, this broke because debian-10 was dropped from lcitool and libvirt-python doesn't build trivially neither in debian-11 nor in debian-12. I might check it later, but honestly got demotivated ...
On Mon, Jan 08, 2024 at 10:48:58AM +0100, Peter Krempa wrote:
On Mon, Jan 08, 2024 at 10:35:53 +0100, Peter Krempa wrote:
On Thu, Dec 14, 2023 at 09:28:15 +0100, Michal Privoznik wrote:
Green pipeline:
https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1106643445
Michal Prívozník (2): ci: integration: Switch upstream integration tests to Fedora 39
For future reference, please note that the integration test suite makes use of artifacts from libvirt/libvirt-perl and libvirt/libvirt-python projects, which thus must be bumped to new Fedora prior to bumping the main project.
Right. We keep forgetting that. I've just posted patches[1] that add notes to the file, so hopefully that doesn't happen again.
I've approved and merged
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/109
and posted
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/130
which will need to be approved.
This should fix the following integration test failure:
Grrr, this broke because debian-10 was dropped from lcitool and libvirt-python doesn't build trivially neither in debian-11 nor in debian-12.
From a quick look, the problem seems to be related to the somewhat recent change in Debian (and other distros? Or was it Python itself?) where 'pip install' is disabled outside of venvs. IIRC lcitool has been patched to work around it already.
I might check it later, but honestly got demotivated ...
No, that's fair. I'll take a better look later today. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/CKXFH... -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Jan 08, 2024 at 10:48:58AM +0100, Peter Krempa wrote:
On Mon, Jan 08, 2024 at 10:35:53 +0100, Peter Krempa wrote:
I've approved and merged
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/109
and posted
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/130
which will need to be approved.
This should fix the following integration test failure:
Grrr, this broke because debian-10 was dropped from lcitool and libvirt-python doesn't build trivially neither in debian-11 nor in debian-12.
I might check it later, but honestly got demotivated ...
Yes, it is very frustrating when updating CI with lcitool when youj want to update the version of one particlar distro, and lcitool forces you to also replace a different distro, and the latter cause breakage for some reason. This has hit me time and time and time again. IMHO it is time to change the policy for lcitool, such that we do NOT remove old distro versions for *at least* 1 year. This will give us flexibility to update individual distros without having to do every distro in lockstep. It will let us debug problems with certain new distros, without blocking updates of the rest of the world. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Jan 09, 2024 at 11:41:17 +0000, Daniel P. Berrangé wrote:
On Mon, Jan 08, 2024 at 10:48:58AM +0100, Peter Krempa wrote:
On Mon, Jan 08, 2024 at 10:35:53 +0100, Peter Krempa wrote:
I've approved and merged
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/109
and posted
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/130
which will need to be approved.
This should fix the following integration test failure:
Grrr, this broke because debian-10 was dropped from lcitool and libvirt-python doesn't build trivially neither in debian-11 nor in debian-12.
I might check it later, but honestly got demotivated ...
Yes, it is very frustrating when updating CI with lcitool when youj want to update the version of one particlar distro, and lcitool forces you to also replace a different distro, and the latter cause breakage for some reason. This has hit me time and time and time again.
IMHO it is time to change the policy for lcitool, such that we do NOT remove old distro versions for *at least* 1 year.
This will give us flexibility to update individual distros without having to do every distro in lockstep. It will let us debug problems with certain new distros, without blocking updates of the rest of the world.
I'd suggest to flag the older distros which would be deleted with a flag which will produce a warning, when regenerating the CI stuff. It might be nice to notify that the distro is out of our support policy but without forcing update.
On Tue, Jan 09, 2024 at 01:12:35PM +0100, Peter Krempa wrote:
On Tue, Jan 09, 2024 at 11:41:17 +0000, Daniel P. Berrangé wrote:
On Mon, Jan 08, 2024 at 10:48:58AM +0100, Peter Krempa wrote:
On Mon, Jan 08, 2024 at 10:35:53 +0100, Peter Krempa wrote:
I've approved and merged
https://gitlab.com/libvirt/libvirt-perl/-/merge_requests/109
and posted
https://gitlab.com/libvirt/libvirt-python/-/merge_requests/130
which will need to be approved.
This should fix the following integration test failure:
Grrr, this broke because debian-10 was dropped from lcitool and libvirt-python doesn't build trivially neither in debian-11 nor in debian-12.
I might check it later, but honestly got demotivated ...
Yes, it is very frustrating when updating CI with lcitool when youj want to update the version of one particlar distro, and lcitool forces you to also replace a different distro, and the latter cause breakage for some reason. This has hit me time and time and time again.
IMHO it is time to change the policy for lcitool, such that we do NOT remove old distro versions for *at least* 1 year.
This will give us flexibility to update individual distros without having to do every distro in lockstep. It will let us debug problems with certain new distros, without blocking updates of the rest of the world.
I'd suggest to flag the older distros which would be deleted with a flag which will produce a warning, when regenerating the CI stuff.
It might be nice to notify that the distro is out of our support policy but without forcing update.
Yep, that's a good idea, as its nice if 'lcitool manifest' warns us about outdated stuff. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Jan 09, 2024 at 12:14:38PM +0000, Daniel P. Berrangé wrote:
On Tue, Jan 09, 2024 at 01:12:35PM +0100, Peter Krempa wrote:
On Tue, Jan 09, 2024 at 11:41:17 +0000, Daniel P. Berrangé wrote:
On Mon, Jan 08, 2024 at 10:48:58AM +0100, Peter Krempa wrote:
Grrr, this broke because debian-10 was dropped from lcitool and libvirt-python doesn't build trivially neither in debian-11 nor in debian-12.
I might check it later, but honestly got demotivated ...
Yes, it is very frustrating when updating CI with lcitool when youj want to update the version of one particlar distro, and lcitool forces you to also replace a different distro, and the latter cause breakage for some reason. This has hit me time and time and time again.
IMHO it is time to change the policy for lcitool, such that we do NOT remove old distro versions for *at least* 1 year.
This will give us flexibility to update individual distros without having to do every distro in lockstep. It will let us debug problems with certain new distros, without blocking updates of the rest of the world.
Considering that we have stopped aggressively deleting mappings, this feels like a natural next step. Let's just make sure that we don't end up keeping everything around forever.
I'd suggest to flag the older distros which would be deleted with a flag which will produce a warning, when regenerating the CI stuff.
It might be nice to notify that the distro is out of our support policy but without forcing update.
Yep, that's a good idea, as its nice if 'lcitool manifest' warns us about outdated stuff.
Agreed. -- Andrea Bolognani / Red Hat / Virtualization
participants (6)
-
Andrea Bolognani -
Daniel P. Berrangé -
Erik Skultety -
Michal Privoznik -
Michal Prívozník
-
Peter Krempa