Make a Fedora Respins main method of get ISO images of Fedora

Yeah, that’s a good summary. To me there’s a problem that’s kinda…if we want to make these images more important than the original release images, we need to throw a bunch of process around it to make sure we don’t screw anything up. If we want to avoid all the process, it would be kinda risky to promote these images over the original release images. So, how do we want to square that circle?

Kevin Fenzi wrote:

What does this gain us? I see two things:

(did I miss any?)

I’m primarily thinking of a third thing: increased automated integration testing of updates will improve the experience of end-users, by helping us catch bugs before they become issues.[1].

I hope it will also help spread the problem-fixing load more to packagers. This is related to a conversation with @dustymabe about what they do in CoreOS, where they actively manage and bug-fix their update streams — and where they’d also like help from packagers pushing updates which fail their tests.

Adam Williamson wrote:

If we want to avoid all the process, it would be kinda risky to promote these images over the original release images. So, how do we want to square that circle?

Tepid change for the somewhat better!

We don’t need to have all the process there at once. I think there is value in measuring (that is, running the tests, seeing the problems) even if we don’t promote the images.

How can we make it so you don’t feel like you need to fix problems that such testing might reveal?


  1. and issues before they become problem reports ↩︎

Kevin Fenzi wrote:

What does this gain us? I see two things:

(did I miss any?)

I’m primarily thinking of a third thing: increased automated integration testing of updates will improve the experience of end-users, by helping us catch bugs before they become issues.[1].

I guess so. I think we do a lot already though…

I hope it will also help spread the problem-fixing load more to packagers. This is related to a conversation with @dustymabe about what they do in CoreOS, where they actively manage and bug-fix their update streams — and where they’d also like help from packagers pushing updates which fail their tests.

I don’t know if we block on the openqa tests yet, but we could?

Adam Williamson wrote:

If we want to avoid all the process, it would be kinda risky to promote these images over the original release images. So, how do we want to square that circle?

Tepid change for the somewhat better!

We don’t need to have all the process there at once. I think there is value in measuring (that is, running the tests, seeing the problems) even if we don’t promote the images.

How can we make it so you don’t feel like you need to fix problems that such testing might reveal?

Some group of people stepping up saying they would investigate problems
with this? :slight_smile: If we just say we are going to do it, then I am suspecting
it would just end up adam and I doing it as we do now…

But again, I’m not sure this is all worth it. :slight_smile:


  1. and issues before they become problem reports ↩︎

I guess I’m missing a logical connection here: what is the relation between doing official respins for public consumption, and increase automated integration testing of updates? OK, doing official respins more or less requires us to do a bit more of one specific type of integration testing: testing that updates don’t break the compose and deployment process. But we would only need to do that because we were providing updated images. If we don’t provide updated images, those problems are never going to get “exposed” to end users.

We can do more automated testing of updates in the contexts that they might cause problems for end users without doing official respins. It’s just a question of resources and time to investigate failures. (I’m actually planning to look at extending the set of tests we run on updates already, it’s just another thing on the list of things to get around to - the work on critical path groups was part of this too, to let us be more focused in exactly what tests run on on what updates).

1 Like

Could you elaborate, please? I’m interested in what differences you have
encountered using the netinstall ISO.

I’m not intending to hijack the discussion here. But one of the
solutions to avoiding a large download of the Live ISO and subsequent
large download of updates[1] (if I understood the OP’s issue correctly)
is using a netinst ISO. The netinst ISOs are, imho, a bit undervalued[2]:


  1. especially true when updating late in the release cycle ↩︎

  2. for lack of finding a better term at closing in on 02:00 AM local time ↩︎

I am trying to install via netboot ISO and Workstation ISO to be sure. I want to verify if pass impression still valid with F38 or not.

Just got this issue:

For comparison, with Everything-netinst, Anaconda get past that task without issues.

I had a look at the issue. Will leave a comment there.