Hide Forgot
Description of problem: Deletion of Custom repo deletes it from all versions of CV where it is included but the behavior is different for Red Hat based repos in Satellite 7.0 Version-Release number of selected component (if applicable): Satellite 7.0 (snap 9) How reproducible: Always Steps to Reproduce: 1. Install RHEL 7 + Satellite 7.0 2. Create a custom product and a custom repo in the product and sync it. 3. Enable a redhat provided repo and sync it. 4. Add both Custom and RedHat repo in same CV, Publish + promote 5. Try to delete the custom repo from Content --> Products page 6. Try to disable the RH repo from Content --> Red Hat repositories page Actual results: Step 5: The delete api of custom repo, now uses "remove_from_content_view_versions=true" by default, Prompts the user that repo is part of a version of CV and LCE and then removes the repo completely from all versions of CV forcefully even if that version of CV is having a lifecycle environment promoted. 2022-02-12T10:27:23 [I|app|c4b3d9a6] Started DELETE "/katello/api/v2/repositories/10?organization_id=3&remove_from_content_view_versions=true" for 10.74.16.27 at 2022-02-12 10:27:23 -0500 2022-02-12T10:27:23 [I|app|c4b3d9a6] Processing by Katello::Api::V2::RepositoriesController#destroy as HTML 2022-02-12T10:27:23 [I|app|c4b3d9a6] Parameters: {"organization_id"=>"3", "remove_from_content_view_versions"=>"true", "api_version"=>"v2", "id"=>"10"} 2022-02-12T10:27:23 [I|bac|c4b3d9a6] Task {label: , id: 7c57aba8-49c4-4af4-a768-21119860d250, execution_plan_id: 84918b10-04ff-4a3e-95ae-a2a1a7c114e9} state changed: pending 2022-02-12T10:27:23 [I|bac|c4b3d9a6] Task {label: Actions::Katello::Repository::Destroy, id: 7c57aba8-49c4-4af4-a768-21119860d250, execution_plan_id: 84918b10-04ff-4a3e-95ae-a2a1a7c114e9} state changed: planning But in APIDOC of Satellite 7.0 , this "remove_from_content_view_versions=true" option is clearly marked as Optional. Step 6: The behavior of RH repo disabling, remains the same i.e. if itis part of a published CV, it cannot be disabled. 2022-02-17T01:08:19 [I|app|28de83c4] Started PUT "/katello/api/v2/products/4/repository_sets/12092/disable" for 10.74.8.85 at 2022-02-17 01:08:19 -0500 2022-02-17T01:08:19 [I|app|28de83c4] Processing by Katello::Api::V2::RepositorySetsController#disable as JSON 2022-02-17T01:08:19 [I|app|28de83c4] Parameters: {"id"=>"12092", "product_id"=>"4", "basearch"=>"noarch", "releasever"=>nil, "api_version"=>"v2", "repository_set"=>{"id"=>"12092", "product_id"=>"4", "basearch"=>"noarch", "releasever"=>nil}} 2022-02-17T01:08:19 [I|bac|28de83c4] Task {label: , id: 9faa69f3-b1fa-4f42-bb94-1cc1d637d2e3, execution_plan_id: e4cb17f4-2e13-4e28-b38c-49c78b8601e9} state changed: pending 2022-02-17T01:08:19 [I|bac|28de83c4] Task {label: Actions::Katello::RepositorySet::DisableRepository, id: 9faa69f3-b1fa-4f42-bb94-1cc1d637d2e3, execution_plan_id: e4cb17f4-2e13-4e28-b38c-49c78b8601e9} state changed: planning 2022-02-17T01:08:19 [E|bac|28de83c4] Repository cannot be deleted since it has already been included in a published Content View. Please delete all Content View versions containing this repository before attempting to delete it. (RuntimeError) Expected results: A) The behavior should be same for both RedHat and Custom repos. Either in both cases get them deleted\remoced from all CV versions or else don't allow doing it if they are part of CV versions. B) When deleting the custom repo from "Content --> Products --> Click open the product --> Click open the repo" page, then It for now only shows us this Repository will also be removed from the following published content view versions! Content View Versions RHEL8 Version 2.0 Are you sure you want to remove repository Satellite_Client_7_RHEL8? Delete Cancel So depending on A, this part needs to be changed as well i.e. fails instead of allowing the deletion or else continue to allow the force deletion. Additional info: * This is a big change in Satellite 7.0 and is unavailable for any earlier versions. * If someone accidentally deletes a custom repo from UI without properly reading the message or understanding the consequences of the action, they will lose the repo entirely from everywhere. * So if we want to keep it behaving in this way, Make sure to document this change in behavior in the Content Management guide as well as Release notes for Sat 7.0
I confirm that: If we don't try to disable the Red Hat repo but try to delete it from the Content --> Products page, that deletes the repo from every published version of CV or CCV as well as disables it. So the behavior of deletion for custom and RH repos are the same. But this is a big change and we should not expose it directly as a default option. My suggestion is the following : For Product: Have a global settings inside Administer --> Settings --> Content that will be disabled by default i.e. will not allow\use remove_from_content_view_versions=true with DELETE API but if that is manually turned on, Then "remove_from_content_view_versions=true" will be used. For Documentation Team: Please document this option somewhere and the purpose of the same [ i.e. how repo deletion is affected by it ]
Creating a new user permission rather than a setting might be better. While a setting would prevent all users from force deleting the repo, a permission would allow only the correct users to force delete the repo. The default would be the administrator. I feel like that would be better UX because a user who really wants to delete something will go and flip the setting if they have the power to.
An idea that Justin mentioned that might help would be an extra checkbox in the UI on the warning modal that pops up. The user would need to check it to confirm that they're serious about deleting the repo. That plus a new user permission would make this new feature pretty safe I think.
(In reply to Ian Ballou from comment #5) > An idea that Justin mentioned that might help would be an extra checkbox in > the UI on the warning modal that pops up. The user would need to check it > to confirm that they're serious about deleting the repo. That plus a new > user permission would make this new feature pretty safe I think. I am fine as long as we have a second layer of protection on top of the Bulk Deletion. But whatever we improve here, that also needs to be documented somewhere as it's a big behavioral change. I am happy to open a doc bz if that is needed.
Created redmine issue https://projects.theforeman.org/issues/34576 from this bug
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/34576 has been resolved.
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 (Moderate: Satellite 6.11 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-2022:5498