Issue #2616
closedafter sync with remove_missing option the next publish is no-op sometimes
Description
Steps to reproduce:
- create repo A with feed, sync, publish
- create repo B with feed pointed to repo A and remove_missing enabled, sync
- remove any units from repo A, publish
- re-sync repo B
- observe negative removed_count in sync report
{
...
"added_count": 0,
"updated_count": 0,
"removed_count": -2
}
- for puppet plugin it will result in no-op publish
The calculation of `removed_count` is done here
which explains how it can be negative.
Check for update `last_units_removed` relies on removed_count being positive.
If the only change during the sync was a removal of some units, the next publish will be no-op, because `last_units_removed` timestamp was not updated.
Updated by kersom over 7 years ago
I am currently writing a test for this issue. And I would like to clarify few points.
- Is it legal to remove_count be negative for all plugins types?
- Is it expected this issue to behave in the same manner for all plugins types?
More details on the final assertions will be very helpful.
Updated by Ichimonji10 over 7 years ago
kersom, to answer your questions:
1. No, remove_count
shouldn't be negative, ever.
2. The mis-behaving code is in the core of Pulp, so yes, this bug should manifest itself for all plugins. I'm not aware of any concrete evidence showing that the bug really does manifest itself for all plugins. But it should manifest itself for all plugins.
So, a test for this issue could go like this:
1. Create, sync, and publish repo A.
2. Create and sync repo B, where B's feed references A and remove_missing is enabled.
3. Remove an arbitrary number of units from repo A and re-publish it.
4. Re-sync repo B.
The report for the sync performed in step 4 should not show a negative removed_count
.
Updated by ttereshc over 7 years ago
Maybe it's worth checking that the removed_count
equals the number of removed packages and not just that it's non-negative.
Right now this number is calculated from other variables so there easily could be mistakes like off-by-one error I guess.
Updated by bmbouter over 5 years ago
- Status changed from NEW to CLOSED - WONTFIX
Updated by bmbouter over 5 years ago
Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.