[libvirt] Time to drop support for Debian 8 (Jessie)?
We currently support Debian 8 (oldstable) along with Debian 9 (stable), but not without some compromises: * the libvirt-dbus, libvirt-ocaml and virt-manager projects do not support the platform at all because it ships outdated versions of some core components; * on the CI side of things, we are forced to drag in the JRE from backports in order to be able to run the Jenkins agent. All things considered, the situation has been fairly manageable up until now, but a couple of recent developments got me thinking that perhaps it's time to let Jessie go: * the distribution has been moved from the regular Debian infrastructure to archive.debian.org[1], a change which has resulted in the daily update run failing and would require investing time to adapt to; * Debian testing has recently entered the full freeze[2], which means the release of Debian 10 can hopefully be expected to happen within the next few month; * even if the Buster freeze period turned out to be exceedingly long, according to our platform support policy[3] we only promise to support a release for the two years after the most recent major release: given that Debian 9 was released in June 2017[4], we would be able to drop Debian 8 support in three months' time regardless of whether or not Debian 10 has been released in the meantime. Based on the above, I suggest we don't invest any time trying to keep Debian 8 chugging along only to drop it in June, and instead declare it as unsupported right now and move on with our lives. Thoughts? [1] https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html [2] https://lists.debian.org/debian-devel-announce/2019/03/msg00003.html [3] https://libvirt.org/platforms.html [4] https://wiki.debian.org/DebianReleases -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Mar 27, 2019 at 02:36:37PM +0100, Andrea Bolognani wrote:
We currently support Debian 8 (oldstable) along with Debian 9 (stable), but not without some compromises:
* the libvirt-dbus, libvirt-ocaml and virt-manager projects do not support the platform at all because it ships outdated versions of some core components;
* on the CI side of things, we are forced to drag in the JRE from backports in order to be able to run the Jenkins agent.
All things considered, the situation has been fairly manageable up until now, but a couple of recent developments got me thinking that perhaps it's time to let Jessie go:
* the distribution has been moved from the regular Debian infrastructure to archive.debian.org[1], a change which has resulted in the daily update run failing and would require investing time to adapt to;
I'm a little confused why we saw any failures. The email link says that the LTS architectures were not moving to archive.debian.org x86_64 is an LTS arch so wouldn't have moved unless I'm misreading the mail.
* Debian testing has recently entered the full freeze[2], which means the release of Debian 10 can hopefully be expected to happen within the next few month;
* even if the Buster freeze period turned out to be exceedingly long, according to our platform support policy[3] we only promise to support a release for the two years after the most recent major release: given that Debian 9 was released in June 2017[4], we would be able to drop Debian 8 support in three months' time regardless of whether or not Debian 10 has been released in the meantime.
Based on the above, I suggest we don't invest any time trying to keep Debian 8 chugging along only to drop it in June, and instead declare it as unsupported right now and move on with our lives.
Thoughts?
[1] https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html [2] https://lists.debian.org/debian-devel-announce/2019/03/msg00003.html [3] https://libvirt.org/platforms.html [4] https://wiki.debian.org/DebianReleases -- Andrea Bolognani / Red Hat / Virtualization
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 Thu, 2019-03-28 at 10:59 +0000, Daniel P. Berrangé wrote:
On Wed, Mar 27, 2019 at 02:36:37PM +0100, Andrea Bolognani wrote:
We currently support Debian 8 (oldstable) along with Debian 9 (stable), but not without some compromises:
* the libvirt-dbus, libvirt-ocaml and virt-manager projects do not support the platform at all because it ships outdated versions of some core components;
* on the CI side of things, we are forced to drag in the JRE from backports in order to be able to run the Jenkins agent.
All things considered, the situation has been fairly manageable up until now, but a couple of recent developments got me thinking that perhaps it's time to let Jessie go:
* the distribution has been moved from the regular Debian infrastructure to archive.debian.org[1], a change which has resulted in the daily update run failing and would require investing time to adapt to;
I'm a little confused why we saw any failures. The email link says that the LTS architectures were not moving to archive.debian.org x86_64 is an LTS arch so wouldn't have moved unless I'm misreading the mail.
$ ./lcitool update libvirt-debian-8 libvirt ... TASK [Update installed packages] ********************************** fatal: [libvirt-debian-8]: FAILED! => {"changed": false, "msg": "Failed to update apt cache: W:Failed to fetch http://deb.debian.org/debian/dists/jessie-backports/main/binary-amd64/Packag... 404 Not Found [IP: 151.101.248.204 80]\n, E:Some index files failed to download. They have been ignored, or old ones used instead."} As mentioned above, we rely on backports for the JRE, so while we could simply disable the jessie-backport repository that would leave us with some packages that are installed on the system but can't be updated, a situation that I would not be particularly comfortable with. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Mar 28, 2019 at 12:23:24PM +0100, Andrea Bolognani wrote:
On Thu, 2019-03-28 at 10:59 +0000, Daniel P. Berrangé wrote:
On Wed, Mar 27, 2019 at 02:36:37PM +0100, Andrea Bolognani wrote:
We currently support Debian 8 (oldstable) along with Debian 9 (stable), but not without some compromises:
* the libvirt-dbus, libvirt-ocaml and virt-manager projects do not support the platform at all because it ships outdated versions of some core components;
* on the CI side of things, we are forced to drag in the JRE from backports in order to be able to run the Jenkins agent.
All things considered, the situation has been fairly manageable up until now, but a couple of recent developments got me thinking that perhaps it's time to let Jessie go:
* the distribution has been moved from the regular Debian infrastructure to archive.debian.org[1], a change which has resulted in the daily update run failing and would require investing time to adapt to;
I'm a little confused why we saw any failures. The email link says that the LTS architectures were not moving to archive.debian.org x86_64 is an LTS arch so wouldn't have moved unless I'm misreading the mail.
$ ./lcitool update libvirt-debian-8 libvirt ... TASK [Update installed packages] ********************************** fatal: [libvirt-debian-8]: FAILED! => {"changed": false, "msg": "Failed to update apt cache: W:Failed to fetch http://deb.debian.org/debian/dists/jessie-backports/main/binary-amd64/Packag... 404 Not Found [IP: 151.101.248.204 80]\n, E:Some index files failed to download. They have been ignored, or old ones used instead."}
As mentioned above, we rely on backports for the JRE, so while we could simply disable the jessie-backport repository that would leave us with some packages that are installed on the system but can't be updated, a situation that I would not be particularly comfortable with.
Ah, so the problem isn't that Jessie has been moved to archive.debian.org, it is that the jessie-backports repo has been moved / EOLd. I'm fine with dropping Jessie given that we'll be dropping it in a couple of months anyway. We should spin up Buster to replace it too 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 Thu, 2019-03-28 at 11:29 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 28, 2019 at 12:23:24PM +0100, Andrea Bolognani wrote:
As mentioned above, we rely on backports for the JRE, so while we could simply disable the jessie-backport repository that would leave us with some packages that are installed on the system but can't be updated, a situation that I would not be particularly comfortable with.
Ah, so the problem isn't that Jessie has been moved to archive.debian.org, it is that the jessie-backports repo has been moved / EOLd.
I'm fine with dropping Jessie given that we'll be dropping it in a couple of months anyway.
Alright, I'll cook some patches then :)
We should spin up Buster to replace it too
We've ever introduced support for unreleased operating systems in our CI environment[1], and I'm not sure it would be a good idea to start now... It seems to me like it would be pretty misleading. Personally I'd just live with running tests on single Debian release until Buster is actually out. [1] Fedora Rawhide, Debian sid and FreeBSD -CURRENT don't count since they're unreleased by definition :) -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Mar 28, 2019 at 03:39:53PM +0100, Andrea Bolognani wrote:
On Thu, 2019-03-28 at 11:29 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 28, 2019 at 12:23:24PM +0100, Andrea Bolognani wrote:
As mentioned above, we rely on backports for the JRE, so while we could simply disable the jessie-backport repository that would leave us with some packages that are installed on the system but can't be updated, a situation that I would not be particularly comfortable with.
Ah, so the problem isn't that Jessie has been moved to archive.debian.org, it is that the jessie-backports repo has been moved / EOLd.
I'm fine with dropping Jessie given that we'll be dropping it in a couple of months anyway.
Alright, I'll cook some patches then :)
We should spin up Buster to replace it too
We've ever introduced support for unreleased operating systems in our CI environment[1], and I'm not sure it would be a good idea to start now... It seems to me like it would be pretty misleading.
I think the fact that we've not done it in the past is a bug really, not really a good thing. Unless we have capacity problems, I don't see a good reason to avoid it, given that we already run the more flakey rawhide/sid distros.
Personally I'd just live with running tests on single Debian release until Buster is actually out.
[1] Fedora Rawhide, Debian sid and FreeBSD -CURRENT don't count since they're unreleased by definition :)
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 Thu, 2019-03-28 at 15:03 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 28, 2019 at 03:39:53PM +0100, Andrea Bolognani wrote:
On Thu, 2019-03-28 at 11:29 +0000, Daniel P. Berrangé wrote:
We should spin up Buster to replace it too
We've ever introduced support for unreleased operating systems in our CI environment[1], and I'm not sure it would be a good idea to start now... It seems to me like it would be pretty misleading.
I think the fact that we've not done it in the past is a bug really, not really a good thing. Unless we have capacity problems, I don't see a good reason to avoid it, given that we already run the more flakey rawhide/sid distros.
We only have Fedora Rawhide running on CentOS CI. And yes, capacity is an ongoing concern. Note that I would not have a problem with adding a Debian sid or Debian testing configuration (but see capacity): what I'm against is specifically installing Debian testing and calling it "Debian 10", because that's just not correct. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Mar 28, 2019 at 04:39:37PM +0100, Andrea Bolognani wrote:
On Thu, 2019-03-28 at 15:03 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 28, 2019 at 03:39:53PM +0100, Andrea Bolognani wrote:
On Thu, 2019-03-28 at 11:29 +0000, Daniel P. Berrangé wrote:
We should spin up Buster to replace it too
We've ever introduced support for unreleased operating systems in our CI environment[1], and I'm not sure it would be a good idea to start now... It seems to me like it would be pretty misleading.
I think the fact that we've not done it in the past is a bug really, not really a good thing. Unless we have capacity problems, I don't see a good reason to avoid it, given that we already run the more flakey rawhide/sid distros.
We only have Fedora Rawhide running on CentOS CI. And yes, capacity is an ongoing concern.
We're dropping 1 distro here, so we can replace it with another
Note that I would not have a problem with adding a Debian sid or Debian testing configuration (but see capacity): what I'm against is specifically installing Debian testing and calling it "Debian 10", because that's just not correct.
Just because it is a pre-release doesn't make it not "Debian 10". It just means it hasn't been declared fully stable yet, but that's no worse than the unstable distros IMHO. I don't see what useful benefit we gain from refusing to deploy Buster to CI until it is declared GA. 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 Thu, 2019-03-28 at 15:50 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 28, 2019 at 04:39:37PM +0100, Andrea Bolognani wrote:
Note that I would not have a problem with adding a Debian sid or Debian testing configuration (but see capacity): what I'm against is specifically installing Debian testing and calling it "Debian 10", because that's just not correct.
Just because it is a pre-release doesn't make it not "Debian 10". It just means it hasn't been declared fully stable yet, but that's no worse than the unstable distros IMHO.
On a Debian 9 machine: $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian ... On a fully up-to-date Debian testing machine: $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux buster/sid" NAME="Debian GNU/Linux" ID=debian ... So clearly the Debian project doesn't consider it to be something that can be called "Debian 10" (or even "Debian 10 alpha") quite yet. Unstable distributions are in a different ballpark entirely, since they're designed to be in a constant state of flux and expectations for users are clearly defined accordingly. -- Andrea Bolognani / Red Hat / Virtualization
participants (2)
-
Andrea Bolognani -
Daniel P. Berrangé