Bug 1446098
| Summary: | [RFE] [6.3] The "Using Download Policies" section lacks detail | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Stephen Wadeley <swadeley> |
| Component: | Docs Server Administration Guide | Assignee: | Stephen Wadeley <swadeley> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Russell Dickenson <rdickens> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2.0 | CC: | adahms, jsherril |
| Target Milestone: | Unspecified | Keywords: | FutureFeature |
| 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: | 2017-08-07 01:24:53 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: | 1486095 | ||
|
Description
Stephen Wadeley
2017-04-27 09:16:57 UTC
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. |