Bug 1241261

Summary: [RFE] Speed up publish Content View publish and promote especially important for Composite Content View
Product: Red Hat Satellite Reporter: Dave Sullivan <dsulliva>
Component: Content ViewsAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.1.0CC: barry.gestwicki.ctr, bbuckingham, bkearney, cduryee, jko, mmccune, prescott, riehecky, sauchter, sthirugn, xdmoon
Target Milestone: UnspecifiedKeywords: FutureFeature, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-12 13:18:59 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:
Bug Depends On:    
Bug Blocks: 1316897    

Description Dave Sullivan 2015-07-08 21:12:16 UTC
Description of problem:

Currently Content View's with rhel repos can take quite a bit of time to publish and promote due to some re-validation.

approximately 6 minutes.

This becomes more apparent as a problem when users have Composite Content Views.

e.g. If I have a very dynamic puppet module Content View and a less dynamic rhel6 Content View coupled together via a Composite Content View

Every time a puppet module is updated we on publish and promote we have to wait for the rhel6 content view to re-validate

<per_mmccune>
There is no simple way currently to calculate if nothing changed in the
Content View. If you publish with new content, or the same content, we
do not do any calculation to determine the exact delta between the prior
version and the one you are publishing. It is safer to ensure 100%
correctly generated content to generate it again upon a publish.

We are working towards future versions to optimize this process so we
don't have to pay the cost of the publish if none of the content changed
or if only a small # changed. That said, the time spent calculating the
delta may be just as expensive as doing the re-publish in the first
place so I can't promise we will see giant gains. We are hopeful that we
can. 
</per_mmccune>

<per_dsulliva>
Ok, my thoughts were that if the Content View only contained redhat repos.

And there was a master table for a repo it would have a db column to show lastmodified.

That table would have cascading triggers.

On modification of the master repo table lastmodified triggers would cascade lastmodified updates to whatever the CV points to.

Then if I publish a CCV and it sees a child CV with only Red Hat repo it can just look to see if the  filter changed and/or repo change.

No change no recalculation required. 
</per_dsulliva>

Due to these issues customer is looking to manage puppet via r10K.


Version-Release number of selected component (if applicable):


How reproducible:

self explanatory


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Another solution here is to provide a multiple CV to host/hostgroup capability.

This would allow publish/promote of the puppet modules CV to be independent of the rhel repo CV

Right now I can't tell if this RFE below is CCV only

https://bugzilla.redhat.com/show_bug.cgi?id=1203267

Comment 6 Bryan Kearney 2016-09-12 13:18:59 UTC
6.2.2 is delivering several performance improvements around content view promotions, including https://bugzilla.redhat.com/show_bug.cgi?id=1161643. I am closing this out as a duplicate of that bug. If 6.2 does not meet the goals of this bug, please feel free to re-open.

*** This bug has been marked as a duplicate of bug 1161643 ***