Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
this will be addressed using a priority or precedence scheme to favor one CV over another when there are conflicts / overlaps across collections of CVs. Also this feature will leverage existing composite CVs to accommodate host groups that require multiple CVs
*** Bug 1158550 has been marked as a duplicate of this bug. ***
Hello, is there any new update for this BZ?
IMO this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1177766 but just using CCVs. You can create a CCV with version 'lastest' for CV1 & CV2, then attach the CCV to a host. Whenever CV1 or CV2 is published it will cause CCV to also be.
This is *NOT* the same as that bz. The idea is that you should be able to present *multiple* content views to a single host. This is because, depending on the content views that would need to go into the CCV's, you can end up with a permutation number of CCV's required to satisfy the combinations required by end systems. eg. If you have a CV for the OS, plus applications A, B & C. System 1 requires OS + A System 2 requires OS + B System 3 requires OS + A + B System 4 requires OS + C etc etc so you having to make CCV's for every possible combination of OS + app(s) that a system might require. This becomes unworkable as the number of apps & OS versions increases.
With Sat6.4 the CompositeContentViews are lightweight and have auto-publishing. This shall cover this topic to create a CompositeContentView and then assign it to the Host/Hostgroup
Peter, are you suggesting a close of this bug?
Bryan, for me this RFE can be closed as there is a good and reliable working solution for the problem.
Peter: I am going to leave this open as there are some parts of this that other customers want to see. Thank you for following up.
Peter and Bryan, It would be nice to have the ability to assign multiple content views to a host. Although it is possible to address this issue with composite views, it is not practical because the number of composite views will grow proportionally to the number of combinations of content views you need to assign to a host. Also the auto publish feature is not feasible for all cases - in some cases we need to manually assign a content view version. So, please, keep this issue on the roadmap. Best regards, Felipe
Peter and Bryan, we concur with Felipe on this feature request. We have a very diverse landscape of products and services and need to combine i.e. RHEL7 with many thirdparty products in different combinations. Being able to use only one (composite) content view makes it inconvenient to manage such scenarios, as we have to build one for each combination and stack many content views on top of each other. Form our perspective it would be very desirable to have the option to include additional content views to hosts / host collections and to be able to "mix and match" products and package versions on this level. Best regards, Paul
Peter and Bryan, +1 also on our side.
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are however doing other things to make this better, for example Pulp 3 will improve the performance of all content operations making creating multiple Content Views (& Versions) much faster. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support.
After further discussion I'm reopening this.
*** Bug 1834445 has been marked as a duplicate of this bug. ***
Monolithic and the logic is flawed. Activation/Product keys should provide access to Custom Products without the need of a Composite view duplicating everything. IE: A SOE CCV for OS RHEL supported repos + upon demand, use a key to get custom products repos (in their own CV) It's an ant work to manage Content in Satellite and it lacks flexibility.
Hello, We have recently moved to Simple Content Access which made every repo in the content view available by default. Desirable behavior would be only BaseOS and AppStream enabled by default. What would you suggest as the best practice in terms of content views and activation keys, for example if we want to have RedHat repos (BaseOS and AppStream) available all the time and other software on demand (EPEL, POSTGRES etc...). As a mitigation strategy, I've overridden to disable all repos except those mentioned before in the Activation key Repository Sets. Best regards, Nazar
Hello Nazar, Currently the best way is the one you've already found - disable unneeded repos via content overrides. In future versions this experience will be improved: see https://bugzilla.redhat.com/show_bug.cgi?id=1265120#c93
The experience might be improved but we will see repo for other product we don't want. One of our app has 20 repos so all machines see those 20 repos (because we have one content view) this flood regular user that search for a repo. Also another concern about CCV: We have one main CV with all RHEL product one very small CV with out customs packages It has the auto publish feature We want to keep 6 versions of the main CV: If we update the small CV at least 6 times the CCV will get updated. If we keep last 6 versions of the CCV we would then have only one version of the main CV. We would need to remember with version was associated with wich main CV and thus not relying on automatic cleaning. We might say ok: keep X (with X > 6) but what if we publish X+1 times we fall back in the same issue. Having the possibility to assign multiple CV (gated with multiple activation keys or none) would solve these two issues at once. The proposed enhancement (https://bugzilla.redhat.com/show_bug.cgi?id=1265120#c93) is clearly a default behaviour I expect and thus might be an improvement (we had to use foreman-rake console to disable product after creation because the option wasn't available (at least at creation)) With multiple CV custom product can be enabled by default (we don't care since we can create a CV for this product only) it get really easy to expose repos.