Bug 2088903

Summary: [RFE] Incremental Content View Version to support also removing content
Product: Red Hat Satellite Reporter: Pavel Moravec <pmoravec>
Component: Content ViewsAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.10.5CC: iballou, sajha, thadzhie
Target Milestone: UnspecifiedKeywords: FutureFeature, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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 Pavel Moravec 2022-05-21 13:40:56 UTC
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:

Comment 1 Pavel Moravec 2022-05-21 13:54:01 UTC
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?

Comment 2 Brad Buckingham 2022-05-23 11:42:02 UTC
Hi Pavel,

Is an 'exclude' filter on the package or erratum not an alternative?

Comment 3 Brad Buckingham 2022-05-23 11:42:52 UTC
Ian,

Adding a needinfo for you as you may have some input on comment 1.

Comment 4 Pavel Moravec 2022-05-23 13:17:32 UTC
(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.

Comment 5 Ian Ballou 2022-05-23 14:58:51 UTC
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.

Comment 13 Brad Buckingham 2023-07-21 21:06:39 UTC
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.