Optimize (CQA) - Mng content - Content access control#4822
Optimize (CQA) - Mng content - Content access control#4822Lennonka wants to merge 2 commits intotheforeman:masterfrom
Conversation
9d3c1cc to
814fb03
Compare
|
Rebased on master. |
|
The PR preview for 814fb03 is available at theforeman-foreman-documentation-preview-pr-4822.surge.sh The following output files are affected by this PR: |
| [role="_abstract"] | ||
| Activation keys simplify the workflow for some of the content access strategies. | ||
| During registration, you use activation keys to assign content view environments, attach content overrides, and set system purpose attributes so hosts inherit the repository access you intend. | ||
| After registration, adjust access per host or through bulk actions instead of changing the keys. |
There was a problem hiding this comment.
I would avoid shortening "activation keys" to "keys":
| After registration, adjust access per host or through bulk actions instead of changing the keys. | |
| After registration, adjust access per host or through bulk actions instead of changing the activation keys. |
|
|
||
| [role="_abstract"] | ||
| Activation keys simplify the workflow for some of the content access strategies. | ||
| During registration, you use activation keys to assign content view environments, attach content overrides, and set system purpose attributes so hosts inherit the repository access you intend. |
There was a problem hiding this comment.
If possible, I suggest to leave out system purposes because it's RHEL only. It does not work for EL/Deb/SLES.
|
|
||
| [role="_abstract"] | ||
| A host can access a package or repository only when all of the following conditions are true. | ||
| A host reaches a repository only when that repository is in a content view environment of the host, survives filters, is enabled, and matches any architecture or operating system version restrictions. |
There was a problem hiding this comment.
reaches -> can access
"reaches" reminds me too much of network connectivity. "survives" feels off to me in docs.
| {Project} provides a robust set of strategies for controlling what content is accessible to your hosts. | ||
| You can restrict content access by using core mechanisms, such as content views, lifecycle environments, and content overrides. | ||
| You can use activation keys to apply these content access controls during host registration. | ||
| You can cap host access to repositories and packages with lifecycle-bound content views, overrides, composite views, and strict architecture or release rules that you evaluate in a deliberate order. |
There was a problem hiding this comment.
"lifecycle-bound" -> should be lifecycle environement or an explanation what a lifecycle in Katello stands for.
| [role="_abstract"] | ||
| To give hosts access to a specific subset of the content managed by {Project}, you can use the following strategies. | ||
| You narrow which repositories and packages registered hosts consume from {Project} by combining content views, lifecycle environments, overrides, and tighter rules where needed. | ||
| Evaluate those options from broad lifecycle design through overrides toward the strictest architecture or release limits. |
There was a problem hiding this comment.
What does "broad lifecycle design" mean? I suggest to reword it to include "lifecycle environement" or maybe describe that this is the base set, and then users can apply filters that act as restrictions/options to reduce the set of packages for hosts later on.
What changes are you introducing?
Improving the Content access control chapter of Managing content
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
Content Quality Assessment for DITA migration:
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Contributor checklists
Please cherry-pick my commits into: