Duplicate repositories in CCV

I am testing a ccv for my katello 3.15.3 server. Now I see this message:

You have selected more than one component Content View Version with the same repository resulting in slower publishing:

Extra Packages for Enterprise Linux 7 - x86_64
    CentOS 7 42.0
    EPEL 7 1.0

Duplicate repositories between the selected Content View Versions will merge, resulting in a Composite Content View with all packages that exist among the duplicates.

How serious is this “slower” publishing? My scenario is like this here even though I don’t see, why it’s an serious issue.

My standard CV “CentOS 7” has a a filter on EPEL7 allowing only ~70 rpms into the view. For tests I also a CV “EPEL 7” only with EPEL7 and no filter.

Now for servers which require full EPEL7 and have a CCV containing the standard CV “CentOS 7” and the “EPEL 7” CV. So yes, I want that merged which it does fine.

What is that ‘slower’ penalty. Do I have to be concerned merging 70+ rpms with 13000+ rpms?

If it is a bad idea: what would be the better alternative:

Two CVs, both identical except for the one has the EPEL7 filter and the other doesn’t.

Or three CVs and two CCVs:

CV 1: all standard repositories, but no EPEL7
CV 2: filtered EPEL7
CV 3: unfiltered EPEL7

CCV 1: with filtered EPEL7 (i.e. CV 1 & CV 2)
CCV 2: with full EPEL7 (i.e. CV 1 & CV 3)

Which would be the better alternative. The second one requires a lot more publishing and I guess it would put an additional burden on the smart proxies which need to be synced from the main server…


Does anyone have an insight, what the best approach would be? By now, I have a couple of other hosts for which I would require some additional filtering or pinning to prevent some updates…

Hi @gvde sorry for the delay until now. Just to make sure I understand, you are wondering how significantly impacted the sync time will be for a CCV with duplicate repositories and if there is a better way i.e. your proposed structure?

Yes. I am wondering what the penalty would be for duplicate repositories in a CCV. To understand if I should really avoid it. And if so, what the best approach would be to support something like in my example.

It’s not recommended but I don’t think its going to be a huge performance hit with the scenario mentioned. I can dig through the code and ask around to get you a more concrete answer.

As far as structure, it would make more sense for the composite content view to have them broken up into filtered and unfilted EPEL repos, but you then are publishing more as you mentioned.

I really don’t think I can give you a concrete answer of what would be best since there are trade-offs on both sides, but maybe if any other users have ran into this decision they can weigh in!