fedora-infra / bodhi

Bodhi is a web-system that facilitates the process of publishing updates for a Fedora-based software distribution.
https://bodhi.fedoraproject.org
GNU General Public License v2.0
154 stars 195 forks source link

Cannot edit side tag updates: The supplied from_tag doesn't exist #4002

Open hroncok opened 4 years ago

hroncok commented 4 years ago

I'd like to edit https://bodhi.fedoraproject.org/updates/FEDORA-2020-cb72ecb134 to raise the karma limit, but I get: The supplied from_tag doesn't exist. error.

hroncok commented 4 years ago

I believe now that it was the state of the update (submitted to stable) that prevented me to edit it. I was able to edit it now. Still, the error message is not helpful, so keeping this open.

mattiaverga commented 4 years ago

The problem here is that, after the release activation point, the builds are tagged in the normal release tags: https://github.com/fedora-infra/bodhi/blob/599c195fdb5018808bccf3b47f2426f418878237/bodhi/server/services/updates.py#L592-L602

and the side_tag is removed from koji: https://github.com/fedora-infra/bodhi/blob/599c195fdb5018808bccf3b47f2426f418878237/bodhi/server/tasks/handle_side_and_related_tags.py#L57-L62

but is never removed from Update.from_tag. So when editing the update we hit: https://github.com/fedora-infra/bodhi/blob/599c195fdb5018808bccf3b47f2426f418878237/bodhi/server/models.py#L2432-L2437

So, @cverna I think we should nullify the from_tag property, or it could be useful for something else? Also, I think we must be sure that all builds in the Update gets tagged with the proper tag in handle_side_and_related_tags task before removing the side tag from Koji. I don't recall if koji.multicall will stop executing when it hits an error, or by default it only returns the error and go ahead to the next item in queue.

cverna commented 4 years ago

@mattiaverga yeah I think that we need to set from_tag to None since once the builds are merged to the normal release tags the update can be considered as a normal multi build update.

Currently we are removing the sidetag before tagging the builds in the new tag (https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/tasks/handle_side_and_related_tags.py#L62). We are using the multicall only for tagging the builds.

cverna commented 4 years ago

The fact that we don't reset from_tag also breaks the signed consumer (https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/consumers/signed.py#L92) making the update stuck in pending since bodhi thinks that the builds are not signed.

hroncok commented 4 years ago

From the packager point of view, it would make sense to me if the tag was preserved until the update is pushed to stable. That way, new builds can be added until the end. Adding new builds now requires tribal knowledge and possibly nonstandard privileges.

cverna commented 4 years ago

From the packager point of view, it would make sense to me if the tag was preserved until the update is pushed to stable. That way, new builds can be added until the end. Adding new builds now requires tribal knowledge and possibly nonstandard privileges.

@hroncok, when the update is created the builds are not in the side tag any more, they are merged into the normal release tag. So adding a new build would be similar to what you are doing with a normal update ?

hroncok commented 4 years ago

I would expect the builds to be tagged in "normal release tag" but also stay tagged in the side tag, so when I build a new build in the side tag, I don't need to create buildroot overrides for that.

Example:

  1. in side tag S, I build libfoo-666-1
  2. in side tag S, I build foo-app-666-1 (against libfoo-666-1)
  3. I create update from the side tag
  4. update receives negative karma: Joanna realized foo-app doesn't start on s390x
  5. I patch foo-app, build foo-app-666-2 (against libfoo-666-1) in the side tag S
  6. The update is (either manually or automatically) edited to swap foo-app-666-1 with foo-app-666-2, karma is reset
  7. Joanna tests this on s390x, all is good, positive karma...

This is currently broken. At (5), the side tag is no longer available. I need to build in regular target (but I need libfoo-666-1 buildroot override for that, right?) or in a new side tag (but I need to tag libfoo-666-1 to that side tag manually, requiring tribal knowledge and/or admin rights (not sure)).

cverna commented 4 years ago

So I started to think about how to implement this and one big down side of keeping the side tag until the update is pushed to stable is that we will have many side tags in koji for 7 days or more meaning that kojira will be even more busy that it currently is.

@nirik @mohanboddu what do you think ? Could that be a problem ?

mattiaverga commented 4 years ago

FYI The from_tag property is used in validators to prevent two updates being created from the same side tag. So we cannot remove the property from the update until the side tag is emptied and removed from Koji.

I also think it could be useful to maintain it to list all updates that got created from a side tag, if this doesn't complicate things too much.

keszybz commented 3 years ago

There's also a UI problem: a dialog is created, but it's too big to fit on (any) screen: Screenshot from 2020-12-09 09-13-12

juhp commented 2 years ago

Seems the only way is not to delete the sidetag until the update is done?

There really should be a way to decouple an update from a sidetag completely: and a deleted sidetag should really trigger that automatically.