#2901 Deleting a side-tag does not delete its children
Closed: Dropped 2 years ago by tkopecek. Opened 2 years ago by mattia.

See for example https://koji.fedoraproject.org/koji/search?match=glob&type=tag&terms=f35-build-side-40730*

There the side-tag f35-build-side-40730 was deleted manually by the user, but that didn't delete its children -signing-pending and -testing-pending.


How these were created? There is nor reason nor expectation that any other tag depends on sidetag on koji's side. Automation which created them should delete them or we have to add/change some API to now that these child tags are exclusively dependent on existence of parent sidetag and could/should be removed in such case.

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

2 years ago

Upon pushing a side-tag update into Bodhi, Bodhi itself creates the -signing-pending and -testing-pending as children of the side-tag:

koji.createTag(pending_signing_tag, parent=from_tag)
koji.createTag(pending_testing_tag, parent=from_tag)
koji.editTag2(pending_testing_tag, perm="autosign")

As children tags, I would expect them to be deleted when I delete the parent.
If that's not true, we should make Bodhi to delete the parent AND all possible children when the update goes stable, to prevent some build from remaining tagged in a child.

But we will also have to run a cronjob to remove children tags for side-tags that were manually removed by users.

Adding @kevin to the discussion, started on devel list.

The tag child/parent relationship is arbirtrary link (one child can be child for more parents and vice versa). So, there is no way to be sure that we can delete it without this additional info. I would vote for the solution you suggests.

Other option would be to store some extra info in those childtags (something bearing info "this tag was created as to be used only with sidetag xy") In such case we can delete all of such tags during sidetag removal. It woud mean that when you create the tag you just add this info. Sidetag plugin can then delete all of these. But it is not nice as something outside of API is needed to follow correct extra info format.

So, I'm going to make Bodhi delete the side-tag and its children when an update is pushed to stable. We currently rely on Koji auto-purge when the last build is untagged, but it seems it's not working every time:
https://koji.fedoraproject.org/koji/search?match=glob&type=tag&terms=f3*-build-side-*-pending*

I wonder if we can enhance the koji-sidetag-cleanup script to also manage those -pending subtags. What can be the cleanest way?
Those -pending subtags are not tagged with side-tag=true and I think we don't want that, so the script will not find them. Should we hardcode -signing-pending and -testing-pending in the script, so that when the side-tag is deleted the script tries to delete those subtags?

Or maybe there's no need to care for that: do those subtags have impact on Koji resources, since they inherit from nothing?

What about adding option to cleanup script (e.g. --delete-prefixed) which would delete everything with "<deleted_sidetag>-*" It is dangerous but with proper naming policy it should be ok to use. Or maybe better - explicity indicate suffixes (--delete-suffix -pending --delete-suffix -signing-pending), etc? Note, that it will still miss tags deleted by users.

For the second question - yes, it doesn't matter much. It just sits in the db and is not used for anything. Deleting those is more about getting cleaner output e.g. from list-tags (even deleted tag is in the db, but doesn't show anywhere except some history queries).

About non-working deleting empty tags - do you've some example? Maybe there is some place where we don't trigger "postUntag" event?

I don't have any example to point out where I'm sure the missed delete it wasn't caused by something else.

I think if there's no impact on resources, it's better not to mess with the cleanup script. By the end, those tags will be cleaned when the release goes EOL, I suppose.
So, if you agree, I think this issue can be closed without any change.

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

2 years ago

Login to comment on this ticket.

Metadata