#7825 Please fix the python-blivet-3.1.0-2.fc29 update
Closed: Fixed 5 years ago Opened 5 years ago by mohanboddu.

  • Describe the issue
    As part of the RC compose, we have included python-blivet-3.1.0-2.fc29 build in the compose but the update got unpushed. We have included a newer version of anaconda which is not in the update mentioned, but we need the python-blivet. So, the update needs to be fixed so that we can push python-blivet to stable when we are a go with the beta release.

  • When do you need this? (YYYY/MM/DD)
    ASAP, before F29 Beta unfreeze

  • When is this no longer needed or useful? (YYYY/MM/DD)

  • If we cannot complete your request, what is the impact?
    World will break.


Proposed fix: I can remove blivet from that update, which I believe would allow a new update to be created with it. Does that sound reasonable?

I don't see the big panic here. I was planning all along to request both updates be pushed stable, just as both updates were included in the compose. I don't know why @m4rtink unpushed the first update.

I mean, if you want, you can take blivet out of the older update and we can add it to the newer one. But I don't see that there's any actual problem with having both updates. Well, now there sort of is, because the first got unpushed, and if we push it back to u-t weird stuff may happen with its anaconda being taken over the newer one in the second update...

@adamwill Is the process for these cases (two updates sharing packages that should both go stable) documented somewhere ?

Frankly, cancelling the old update and pushing a single new update with all relevant packages still seems more sane to me that pushing two updates with different versions of some packages, but not others.

In addition to the above proposal, I further propose that I will add blivet to this update: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f16a71bc92

Ah, after submitting my comment I saw that there were other comments added (Pagure didn't show them as they came in). I think we should probably not try pushing the older update since we don't want that Anaconda. I'm not really sure what would happen if we tried to push it. IMO, the cleanest thing is to do what I proposed:

Remove blivet from the old update, and add it to the new update.

I will need an FBR to do the first part of that, and I can add it to the second update without an FBR as a PP.

I'm not really sure what would happen if we tried to push it.

@bowlofeggs AFAIK, since bodhi uses pungi and pungi uses the latest tagged builds, so the older build would be discarded and the latest build will be used to generate the repo.
But in this case, there is no composing as the stable updates are just tagged into f29. We should be careful when we push the stable updates to make sure that we push the older one's first and then the newer builds.

IMO, the cleanest thing is to do what I proposed:

Remove blivet from the old update, and add it to the new update.

I agree.

@m4rtink "Is the process for these cases (two updates sharing packages that should both go stable) documented somewhere?" - no, because there isn't a sane process, unfortunately. The "process" is "don't do that", but in cases like this that turns out to be hard.

What would really help is the ability to move a package from one update to another, but - aside from @bowlofeggs going and bashing things behind the scenes - that is currently not possible. If you wind up stuck in the case where you need two separate updates to be pushed stable together, the only way to (probably) achieve this is to be very careful to submit them for stable at the same time.

@adamwill Yeah moving builds between updates could be cool feature. I'm not sure there's a filed RFE for that or not. Something else that might be useful is the ability to group updates together:

https://github.com/fedora-infra/bodhi/issues/2029

If we had something like that it would be possible for packagers to express that two updates go together atomically, without needing provenpackager powers. Sadly, as always, I just can't prioritize fixing these things right now due to too much to do :/

Update:

The FBR bit has been applied and blivet is no longer in the old update.

I attempted to add blivet to the new update which failed due to a bodhi bug that was fixed in 3.10.0, but 3.10.0 is not deployed to production yet :/ If you try to add it, you will see this error:

Builds : Cannot find release associated with build: python-blivet-3.1.0-2.fc29, tags: ['f29-compose', 'f29-updates-candidate', 'f29-iot']

I'm currently thinking of options to solve this. Here's a few ideas:

  1. Is it an option to temporarily remove the f29-compose tag, add the build to the new Bodhi update, and then re-add the f29-compose tag? I don't have perms to do that and do not know what the consequences would be, but I think it would work around the Bodhi bug.
  2. I could make a bodhi 3.9.1 release with @otaylor's patch and get an FBR to deploy it.
  3. I could try to fiddle in the db some more, but unfortunately the code to add builds to updates is not as simple as the code to remove them and requires a Pyramid Request object, and I'd rather not try to have to fake a web request in an FBR.

OK, @mohanboddu and I did option #1 above, though we ended up needing to do it to all the builds in the update. python-blivet-3.1.0-2.fc29 is now part of FEDORA-2018-f16a71bc92.

@mohanboddu: reminder to add the f29-compose tag back to all the builds in that update. Once that's done, I think we can close this ticket.

Closing the ticket as all the builds are now tagged back into f29-compose tag.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata