Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2098271 - Library/Default Organization View (metadata,database) are not matching
Summary: Library/Default Organization View (metadata,database) are not matching
Keywords:
Status: CLOSED DUPLICATE of bug 2089580
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Pulp
Version: 6.10.6
Hardware: x86_64
OS: Linux
high
high
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Lai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-17 20:01 UTC by Ricardo Santamaria
Modified: 2022-06-30 19:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-29 17:35:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ricardo Santamaria 2022-06-17 20:01:33 UTC
Description of problem:

When syncing the new content, at the end of the process, the metadata and db information regarding to packages are not matching. Also, for this specific scenario, the customer has ~46 capsules and he is also syncing Library. Which means, the information should be the same at the end of the day on all the capsules (Library/Default Organization View) and what we are seeing is a different behavior.

Version-Release number of selected component (if applicable):
satellite-6.10.6-1.el7sat.noarch

Comment 3 Daniel Alley 2022-06-17 22:22:00 UTC
> Once they are re-synced, it will work fine.

A force-sync on the capsule, given that as mentioned the capsules might be optimizing out the syncs.

Comment 15 wclark 2022-06-28 23:41:04 UTC
The reason repositories in Library are not getting synced on Capsules, after the very first sync of that repository on Satellite, is that the smart_proxy_sync_history used by the 'optimized' sync method is not getting cleared like it should:

# sudo -u postgres psql -d foreman -c 'select * from katello_smart_proxy_sync_history where repository_id = 1 and smart_proxy_id = 2;'
could not change directory to "/root": Permission denied
 id | smart_proxy_id | repository_id |         started_at         |        finished_at         
----+----------------+---------------+----------------------------+----------------------------
 23 |              2 |             1 | 2022-06-21 19:52:04.032127 | 2022-06-21 20:07:31.965945
(1 row)

The reason the smart_proxy_sync_history doesn't get cleared like it should, is that this only happens when Actions::Pulp3::Orchestration::Repository::GenerateMetadata is called with `contents_changed => true`. For Repository syncs in Library (unlike in CV publish/promote), the value of contents_changed should come from the output of Actions::Pulp3::Repository::SaveVersion, but there is a bug on Satellite 6.10 where regardless of the actual output value, Actions::Pulp3::Repository::SaveVersion always passes contents_changed => nil to the GenerateMetadata step. A hotfix[1] is available for this bug.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2089580#c12

However, installing the hotfix will not necessarily cause the next repository sync on Satellite to immediately trigger repository syncs on Capsules, unless the sync from the upstream repository downloaded new packages/metadata, because passing (correctly) `contents_changed => false` will not clear the smart_proxy_sync_history. Depending on the urgency, the following approaches may be taken.

I. PASSIVE APPROACH

  1. install the hotfix linked above.
  2. wait for a repository sync from the upstream repository that includes some changes.
  3. when the sync on Satellite detects new changes on the upstream repository, it will trigger syncs on Capsules (that have the Library environment assigned).

II. ACTIVE APPROACH (Specific Repos Only)

  1. install the hotfix linked above (to prevent the issue from occurring when the repositories are synced with new changes in the future).
  2. use `hammer repository list --organization-id 1` (substitute the ID for your organization on Satellite if other than 1) and get a list of the IDs for repositories which need to be synced in the next optimized sync on each Capsule
  3. download the script to reset smart proxy sync histories:

    # wget -O reset_sync_histories.rb https://gist.githubusercontent.com/wbclark/489781bc4d146e554c1103c72e934c2a/raw/c0bc82b432e64daf2272d32db77f0d14ee677129/clear_smart_proxy_sync_histories.rb

  4. edit the list of repository_ids on line 26 to match your list from step II.2 above
  5. run the script using the foreman-rake console:

    # cat reset_sync_histories.rb |foreman-rake console

  6. run 'Optimized' Capsule syncs for each of the affected Capsules, and notice the repositories which had their smart_proxy_sync_histories cleared are included in this optimized sync

III. ACTIVE APPROACH (Blanket all Repositories in the Library Environment, which is still faster than a 'Complete' sync that includes other LCEs than Library)

  1. install the hotfix linked above (to prevent the issue from occurring when the repositories are synced with new changes in the future).
  2. clear smart proxy sync histories for all Library repos with this command:

    # echo "Katello::RootRepository.all.map { |repo| repo.id }.each { |repo_id| Katello::Repository.find(repo_id).clear_smart_proxy_sync_histories }" |foreman-rake console

  3. run 'Optimized' syncs of the affected Capsules



The third approach (III) is the recommended approach to assure immediate correctness of all Library repos on all Capsules.

Comment 17 wclark 2022-06-30 19:34:19 UTC
Amendment to step III.2. from comment #15 above:

The correct script should instead be this instead, which does not rely on the faulty assumption of a correspondence between Katello::Repository and Katello::RootRepository ids:

III. ACTIVE APPROACH (Blanket all Repositories in the Library Environment, which is still faster than a 'Complete' sync that includes other LCEs than Library)

  1. install the hotfix linked above (to prevent the issue from occurring when the repositories are synced with new changes in the future).
  2. clear smart proxy sync histories for all Library repos with this command:

    # echo "Katello::Repository.where(content_view_version_id: 1).each(&:clear_smart_proxy_sync_histories)" |foreman-rake console

  3. run 'Optimized' syncs of the affected Capsules


Note You need to log in before you can comment on or make changes to this bug.