Red Hat Bugzilla – Bug 1446098
[RFE] [6.3] The "Using Download Policies" section lacks detail
Last modified: 2018-08-31 11:20 EDT
Document URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/importing_red_hat_content#Importing_Red_Hat_Content-Using_Download_Policies Section Number and Name: 4.4. Using Download Policies Describe the issue: If a repository is set to "on demand" it should only download an RPM when required, regardless of the repository location. The repositories in Satellite Server are, I believe, handled by the integrated Capsule. The download policies are described in "Using Download Policies", but it does not make these points clear. Suggestions for improvement: Confirm with engineering that repos are handled by Capsule, integrated or isolated. Add more detail to the section to explain this and also mention, or qualify statements, for the case where you have configured the isolated Capsule not to have the Pulp database to store repos. Also confirm that if "on demand" repo in integrated Capsule is asked for an RPM by host1 via Capsule1, the RPM will not be pushed to Capsule2 just because it has the same repo. Additional information: https://access.redhat.com/discussions/3015961
Assigning to Stephen for review.
Hey Stephen, Let me describe the feature a bit and hopefully answer your questions. For the Satellite there are three Download Policies (Immediate, Background, On demand). I wouldn't worry about thinking about an 'internal capsule' as it will only confuse things, just think about the satellite as a whole. For an on demand repo, the packages in that repo can be added to content views and promoted around to lifecycle environments. Any packages in that repository (or any content view copy) are not downloaded until some client requests them from the Satellite (or through a capsule). For Capsules there are Four Download Policies (Immediate, Background, On Demand, and Inherit). Setting a Capsule to On Demand means that no rpm files will be downloaded by the capsule from the Satellite until a client requests them from the Capsule. If a client does request a package from the capsule, and the satellite has not yet downloaded it, the Satellite will download it, pass it to the capsule, and the capsule will pass it to the client. In this case the package will be saved on the Satellite and the Capsule. If a client requests a package from the Satellite only, it will not cause it to be downloaded to the Capsule. If a user has two external capsules and a client requests a package from Capsule A, it will not cause the package to be downloaded to Capsule B. The inherit setting is how Capsules behaved in 6.2. The capsule just uses the same download policy for each repo as that on the Satellite. If Repo A is using On Demand, then the capsule will use On Demand for Repo A. But if Repo B is using immediate on the Satellite, the Capsule will use Immediate for Repo B and still use ON Demand for Repo A. Keep in mind there are some combinations that do not make sense to use. Such setting a Repository on the Satellite ot use ON Demand, but setting a Capsule's download policy to "Immediate" This would cause all packages to be downloaded on the Satellite rendering its usage of On Demand pointless (as all package are going to be downloaded during its capsule sync) As for your question about 'for the case where you have configured the isolated Capsule not to have the Pulp database to store repos.' I assume this is the case where you install a capsule, but tell the installer to not install pulp at all? In that case there is no content on the capsule and you cannot sync content to the capsule, so none of this information is relevant. Let me know if there are any additional questions! (Hopefully i didn't confuse you more)
(In reply to Justin Sherrill from comment #2) Thank you Justin I am expanded that section to two lists, one for Satellite and one for Capsule, and adding your new info. > As for your question about 'for the case where you have configured the > isolated Capsule not to have the Pulp database to store repos.' I assume > this is the case where you install a capsule, but tell the installer to not > install pulp at all? In that case there is no content on the capsule and > you cannot sync content to the capsule, so none of this information is > relevant. > IIRC, this is the flag that could be used to control if a Capsule is a "content" proxy using Pulp --[no-]enable-foreman-proxy-plugin-pulp Enable 'foreman_proxy_plugin_pulp' puppet module (default: true) I think it will be enough if at the end of the update section I say: These policies will not be available if a Capsule was installed or updated with `--enable-foreman-proxy-plugin-pulp` set to false. Thank you
This request has now been addressed. Closing.