Description of problem: Incremental Content View feature serves as a "hotfix process" to update a content in a given CV/LE without the need to publishing a new CV version, overwriting its Library environment and re-promoting it to the given LE. However, this is supported for adding a content only, not for removing. There are use cases where a package is required to be removed from a given CV/LE. The only allowed / supported way is to remove the package from the root repo, publish a new version of the CV and promote it to the LE. That does not work well when other changes happened to the repo or CV meantime. Therefore we need "decremental CV update" as well. Version-Release number of selected component (if applicable): Sat 6.10 How reproducible: 100% Steps to Reproduce: 1. Attempt to remove a package from a CV/LE (while a newer CV version exists and the underlying repo got some more content) Actual results: 1. No way of getting that. Even trying to use direct API requests fails when calling endpoint: PUT /katello/api/repositories/:id/remove_packages due to: "Can only remove content from within the Default Content View" Expected results: Some allowed+supported way of removing a content from a CV/LE. Additional info:
Can't there be a rake script workaround for this? I was attempting to mimic the Actions::Katello::Repository::RemoveContent for a CV repo, but the best I got is: repoid=ENV['REPOID'].to_i pkgid=ENV['PKGIDS'].to_i def wait_for_task(id) t = ForemanTasks::Task::DynflowTask.find(id) puts("Waiting for completion of task #{t}") while t.state != "stopped" sleep(1) t = ForemanTasks::Task::DynflowTask.find(id) end puts("Done.") end puts("repoid=#{repoid} pkgid=#{pkgid}") repo = Katello::Repository.find(repoid) t = ForemanTasks.async_task(::Actions::Pulp3::Orchestration::Repository::RemoveUnits, repo, SmartProxy.pulp_primary, { :contents => [pkgid], :content_unit_type => "rpm" }) wait_for_task(t.id) content_units = Katello::Rpm.where(:id => [pkgid]).each do |content_unit| content_unit.remove_from_repository(repoid) end tt = ForemanTasks.async_task(::Actions::Katello::Repository::MetadataGenerate, repo, { :force_publication => true, :force => true, :contents_changed => true, :source_repository => repo } ) ttt = ForemanTasks.async_task(::Actions::Katello::Applicability::Repository::Regenerate, :repo_ids => [repoid]) wait_for_task(tt.id) wait_for_task(ttt.id) which - when called for both CV-version and CV-LE repos - should update relevant repos, but it either doesnt create Publication or doesnt update Distribution /o\ Any idea what am I doing wrongly?
Hi Pavel, Is an 'exclude' filter on the package or erratum not an alternative?
Ian, Adding a needinfo for you as you may have some input on comment 1.
(In reply to Brad Buckingham from comment #2) > Hi Pavel, > > Is an 'exclude' filter on the package or erratum not an alternative? Good idea - but can we apply filters exactly to incremental updates, or to a whole new CV version? But yes, a possible implementation in allowing filters per minor CV versions would be a solution.
Hi Pavel, Due to the complexities of CVs and how they interact with Pulpcore repository versions, a script or updated API endpoint would need to be carefully developed. For example, there would be difference cases depending on if the content view version was generated with filters or not because, without filters, we 'redirect' the user to the default library repos from the CV/LCE path. I tried it myself on a CVV by commenting out the library repo check. It looks like it's not working because a CVV repo's backend_service will point to the CVV repo's own RepositoryReference. That RepositoryReference is only meaningful if the content view version was generated with filters (this relates to the example I just mentioned). So, if we want this feature, I propose that we go through the whole design rather than trying to make the old code fit. There are quite a few pitfalls with the backend Pulp objects when it comes to modifying CVVs. For now, the only option really is to generate a new content view version using filters. It won't be a proper 'incremental update' though since the copied content will come from the library repository and old filters won't be considered. If it's really needed in an emergency sense, I think the package(s) would need to be removed from the Pulp repository directly, which would generate a new repository version. The publications / distributions would need to be updated manually along with the Katello DB.
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you.