Bug 1997186
Summary: | [regression] data.yml is referring to old sync plain id which does not exist in katello_sync_plans | |||
---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Joniel Pasqualetto <jpasqual> | |
Component: | Satellite Maintain | Assignee: | Eric Helms <ehelms> | |
Status: | CLOSED ERRATA | QA Contact: | Griffin Sullivan <gsulliva> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 6.9.0 | CC: | ahumbe, apatel, egolov, ehelms, gsulliva, kgaikwad, msunil, ngalvin, pcreech, pdwyer, qfz769, rcavalca, risantam, rrajput, saydas | |
Target Milestone: | 6.13.0 | Keywords: | PrioBumpGSS, Regression, Triaged, Upgrades, WorkAround | |
Target Release: | Unused | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | rubygem-foreman_maintain-1.2.6 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 2175007 (view as bug list) | Environment: | ||
Last Closed: | 2023-05-03 13:21:03 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: |
Description
Joniel Pasqualetto
2021-08-24 15:01:19 UTC
I am on 6.11.4 and having this issue still.. Going with this work around while waiting for a solution - not great not terrible. https://access.redhat.com/solutions/6967460 Red Hat, when do you expect it to be fixed? Hello, There is a much better solution present than what is documented in the KB. A) mv /var/lib/foreman-maintain/data.yml /tmp/ B) use "hammer sync-plan list" to check the current list of sync plans and note down their IDs C) Use "hammer sync-plan update --id X --enabled true" to enable the sync plans manually [ if found any disabled ] [ here X should be replaced by ID of the sync plan ] D) Now fix satellite-maintain : # satellite-maintain advanced procedure run sync-plans-disable # cat /var/lib/foreman-maintain/data.yml --> It should record the ID of currently present sync plans under "disabled" section # satellite-maintain advanced procedure run sync-plans-enable # cat /var/lib/foreman-maintain/data.yml --> It should record the ID of currently present sync plans under "enabled" section And now, you are good to normally use satellite-maintain or foreman-maintain command for upgrade or backup or restore without needing to whitelist any steps. hehe fixed! Thank you - works like a charm :) Verified on 6.13 snap 14 Deleting sync plans when disabled does not disrupt foreman-maintain's ability to enable the right sync plans. Steps to Reproduce: 1. Create 2 sync plans 2. # foreman-maintain advanced procedure run sync-plans-disable 3. # hammer sync-plan delete --id 3 4. # foreman-maintain advanced procedure run sync-plans-enable Results: Running ForemanMaintain::Scenario ================================================================================ re-enable sync plans: | Total 1 sync plans are now enabled. [OK] -------------------------------------------------------------------------------- You can also see the proper list of enabled and disabled sync plans in /var/lib/foreman-maintain/data.yml Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Satellite 6.13 Release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:2097 |