On Tue, Jun 24, 2025 at 3:25 PM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Tue, Jun 24, 2025 at 1:41 PM Warner Losh <i...@bsdimp.com> wrote: > > > > On Tue, Jun 24, 2025 at 11:16 AM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > > > > On Tue, Jun 24, 2025 at 12:28 PM Warner Losh <i...@bsdimp.com> wrote: > > > > > > > > On Tue, Jun 24, 2025 at 10:02 AM Thomas Huth <th...@redhat.com> wrote: > > > > > > > > > > On 22/06/2025 03.46, Warner Losh wrote: > > > > > > > > > > > > > > > > > > On Sat, Jun 21, 2025, 6:01 PM Stefan Hajnoczi <stefa...@gmail.com > > > > > > <mailto:stefa...@gmail.com>> wrote: > > > > > > > > > > > > On Sat, Jun 21, 2025 at 7:59 PM Stefan Hajnoczi > > > > > > <stefa...@gmail.com > > > > > > <mailto:stefa...@gmail.com>> wrote: > > > > > > > > > > > > (I forgot to CC qemu-devel) > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > This might only be temporary, but the CI is getting HTTP 404 > > > > > > Not Found > > > > > > > for the following URL: > > > > > > > > > > > > > https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.1/ > > > > > > FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso <https:// > > > > > > download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.1/ > > > > > > FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso> > > > > > > > > > > > > > > https://gitlab.com/qemu-project/qemu/-/jobs/10424901718#L848 > > > > > > <https://gitlab.com/qemu-project/qemu/-/jobs/10424901718#L848> > > > > > > > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > Time to bump the version to 14.3. > > > > > > > > > > Hmm, while we're used to refresh the CI images for the *host* > > > > > environments, > > > > > it's rather ugly to see images for the *guests* of the functional > > > > > tests > > > > > disappear. Maybe we should rather remove that test if the URL is not > > > > > stable? > > > > > > > > Yes. Most of our images have a shelf life of about a year to 18 months. > > > > And QEMU > > > > should be testing all the 'supported' FreeBSD images, just like for > > > > other projects. > > > > The question becomes how can we, the FreeBSD Project, remove the > > > > friction that's > > > > here now because we timeout / move the older images as they pass out of > > > > support. > > > > > > > > We've also just shifted to a more frequent release cadence, so the > > > > releases have gone > > > > from living for 18-24 months down to just 12. We just released > > > > FreeBSD 14.3, and 14.1 > > > > is only a year old. So what's the best way of dealing with this? We > > > > could have a 14-latest > > > > but the md5 would change... > > > > > > > > So I'm open to making a change, but I need help crafting something > > > > that will work, since > > > > I'm not clever enough to suggest something here. > > > > > > A test run should be repeatable. If a test passes on a given qemu.git > > > commit then it should continue to pass when run again. Using -latest > > > breaks this property, so let's avoid it. > > > > > > Ideas: > > > 1. FreeBSD provides convenient permanent URLs. > > > 2. QEMU uses a permanent FreeBSD ISO mirror URL instead. Need to find > > > a mirror that is fast and reliable. > > > 3. Someone agrees to regularly update the URL in QEMU's test suite so > > > that breakage isn't exposed. IMO the least desirable solution because > > > an old copy of the test will start failing after 12 months. > > > > So there's two issues at play. > > > > FreeBSD does maintain all our archival releases forever. They never change. > > But, we don't have permanent links to them today. We start with one URL and > > then migrate to a second one when they transition from supported to > > unsupported. > > We do this, in part, to make sure people upgrade. So in effect, this > > breakage > > means that our notion is "working" in the sense that the FreeBSD project's > > goals > > of making people "keep up to date." > > > > This does, I realize, clash with the views that QEMU wants to have some > > stable > > way to test images over time, even if the upstream's notion of supported or > > not > > changes. > > > > One easy idea might be to 'prestage' the 'legacy' releases when they > > are supported > > on the 'legacy' server so that tests can be written with the legacy > > path so that these > > tests always work, now and in the future. > > > > So, this is terrible from a FreeBSD point of view. We'd like it if > > qemu always tested > > all of our releases, as well as snapshots of the tip of the spear. > > There's got to be some > > way to have some shared responsibility that we can automate. FreeBSD could > > test > > the most recent release of qemu against a bunch of images in our CI > > cluster. But we > > don't actually have a CI cluster we could put that into (our focus is > > just a little different) > > today. Ideally, your (3) above would happen as we rotate in new > > versions and out old > > versions of FreeBSD. But honestly, I'm the person (or one of the > > people) that should > > be keeping his eye on the ball, but we see how well that has worked > > out. So the question > > becomes is this a management failure (eg, someone/something needs to prompt > > me > > or others in the FreeBSD project to update it via reminders, release > > checklists, etc)? > > Or is it something that can fixed by automations somehow? I don't know... > > How about doing both: > 1. Making the "legacy" URL available immediately so that anything that > needs a permalink can use it (but they will explicitly specify the > word "legacy" in the URL, which is a hint that it's not the latest and > greatest release). > 2. You set up a calendar reminder to send a patch updating QEMU's test > suite to the latest FreeBSD release every 12 months. A shell script > could perform the steps of updating the URL, committing the change, > and sending a patch email. > > That way FreeBSD's latest release will be tested in a timely manner > and a snapshot of the QEMU test suite will still pass after 12 months. > > What do you think?
So, ideally, we could try two URLs. The "download" path has the full CDN that we operate behind it. It's the least load on our infrastructure. However, if that fails, the "archive" path will have the same images. The "archive" path could be used all the time if the two URL strategy can't be used. The downloads will be slower, but the images are already transferred to the archive machine (not cdn) about a week or so after the release. If the load is going to be super low, this would be acceptable (and I suspect that it would be since we cache these images). This would allow older releases to keep working (once we transition to either the two or one url strategies), and all the other nice features having the same tests today and 4 years from now, should we ever need to test that, say for regressions. What's the anticipated load, measured in downloads per day say, this testing generates? As for the second one, I've added reminders as well as a request to our release team to ask me if I've done it a month after the release. We'll see how well that works out since the update takes minutes. Speaking of which, has someone done the update? I'm a bit behind on my qemu stuff and haven't been paying attention. Warner