Project

Profile

Help

Story #3308

Document that a repo version is expected to be created for all sync's regardles of if there is new content remotely or now

Added by kersom over 1 year ago. Updated about 1 month ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Documentation
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

Description

Problem

We don't document the expectation that every sync should produce a repository version.

Why always make a repo version?

It's less surprising to users when they ask Pulp to sync and receive a repo version N+1 that is that same as repo version N. It's more confusing to users if they get some repo verisons for some sync's and not for others depending on the remote state.

Solution?

We should document the expectation that every sync produces a repository version in the plugin writer docs.


Related issues

Related to Ansible Plugin - Issue #4920: Collection - Repository versions not being update after successive syncs MODIFIED Actions

History

#1 Updated by kersom over 1 year ago

  • Description updated (diff)

#2 Updated by amacdona@redhat.com over 1 year ago

  • Status changed from NEW to CLOSED - WONTFIX

This is correct behavior. A new RepositoryVersion needs to be created, even if the sync does not add or remove any content units.

The reasoning for this is made clear by a worker crash scenario. When a sync is started, a new RepositoryVersion is created, (number= 2) and Repository.last_version = 2. Before the sync is completed, the worker crashes. While the crash is waiting to be cleaned up, a second sync task is run, which creates another new RepositoryVersion. The second sync task creates a new RepositoryVersion(number=3). If the crash/failure cleanup decrements Repository.last_version, then Repository.last_version will be incorrect, leading to duplicate key errors.

All of this complexity goes away if we have "empty" RepositoryVersions, which can be deleted by the user.

#3 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#4 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

#5 Updated by daviddavis 5 months ago

  • Status changed from CLOSED - WONTFIX to NEW

In pulp_ansible, we couldn't use the Stages code and we made the decision to NOT create a repo version when content doesn't change. This of course is not consistent with other plugins. I am reopening this issue to rediscuss this and also to make sure we have proper docs around the correct behavior for plugin writers.

#6 Updated by kersom 4 months ago

  • Related to Issue #4920: Collection - Repository versions not being update after successive syncs added

#7 Updated by bmbouter 4 months ago

  • Subject changed from Sync of unchanged importer update repo version to Document that a repo version is expected to be created for all sync's regardles of if there is new content remotely or now
  • Description updated (diff)
  • Sprint set to Sprint 54
  • Tags Documentation added

After discussion during today's open floor we decided:

1) the current behavior is a good behavior. It's less surprising to users when they ask Pulp to sync and receive a repo version N+1 that is that same as repo version N, and more confusing if they get some repo verisons for some sync's and not for others depending on the remote state.

2) We should document this expectation in the plugin write API, so now this is a docs story

3) it should go on the sprint

#8 Updated by amacdona@redhat.com 4 months ago

  • Tracker changed from Issue to Story
  • % Done set to 0

#9 Updated by ttereshc 4 months ago

  • Sprint changed from Sprint 54 to Sprint 55

#10 Updated by dkliban@redhat.com 3 months ago

  • Sprint changed from Sprint 55 to Sprint 56

#11 Updated by rchan 3 months ago

  • Sprint changed from Sprint 56 to Sprint 57

#12 Updated by rchan about 2 months ago

  • Sprint changed from Sprint 57 to Sprint 58

#13 Updated by bmbouter about 1 month ago

  • Sprint/Milestone deleted (3.0)

#14 Updated by rchan about 1 month ago

  • Sprint deleted (Sprint 58)

Please register to edit this issue

Also available in: Atom PDF