ROX-30739: Docs for process baseline auto locking #100444
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@JoukoVirtanen: This pull request references ROX-30739 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
the
size/S
openshift-ci
bot
added
size/M
| * `/v1/processbaselines/bulk/unlock` | ||
| The following is an example input for the endpoints: | ||
|
|
There was a problem hiding this comment.
needs the correct tag - see: https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/doc_guidelines.adoc#code-blocks-command-syntax-and-example-output
for example [source,yaml] and the ---- to set off the code block
| Central, Central DB, and Sensor will consume more resources when process baseline auto-locking is enabled. | ||
|
|
||
| The following results were obtained from tests with 1,000 deployments in which 5,000 process were spawned every 30 seconds (166.67 processes per second). The test was run with the feature enabled and disabled. Resource usage was compared between the two tests. For the tests the process baseline generation duration was set to three minutes and the rate of process creation did not change after the baseline generation period ended. | ||
|
|
There was a problem hiding this comment.
I normally only see a general level of detail included for test results like these in user documentation. Basically, what users need to know is the takeaway from these tests and the results.
example: Testing of this feature with 1,000 deployments where 5,000 processes were spawned every 30 seconds showed that resource usage increased when baseline auto-locking was enabled.
You could list the bullet points here, but I think what you want to get at is, is enabling this something that will affect performance or something else about the user experience? Then you might need to say something like "Depending on the number of deployments, Sensor and Central can use more memory and possibly affect performance." (or whatever the actual case is) As a user, will they look at the bullets and know that Central using 175 mb more memory will cause a slowdown (for example)?
There was a problem hiding this comment.
I clarified the potential negative consequences of enabling the feature in the abstract.
Co-authored-by: Kerry Carmichael <kcarmich@redhat.com>
There was a problem hiding this comment.
The use of "auto-lock" vs "auto-locking" is kind of inconsistent. I would suggest using "auto-lock" to refer to the feature, item, etc. and "automatically locking" to refer to the action of using the auto-lock feature. Maybe just check throughout that we are being consistent.
It's not a huge issue but it would be good to be consistent. We would typically not use "auto locking" to refer to the action of locking because the Style Guide prohibits "auto" for shortening "automatically". In the case of "auto-lock feature" or the configurable option, the name includes the shortened form, so that's fine.
| The following results were obtained from tests with 1,000 deployments in which 5,000 process were spawned every 30 seconds (166.67 processes per second). The test was run with the feature enabled and disabled. Resource usage was compared between the two tests. For the tests the process baseline generation duration was set to three minutes and the rate of process creation did not change after the baseline generation period ended. | ||
|
|
||
| * Sensor used 24 Mb more memory. | ||
| * The difference in sensor memory usage didn’t seem to be increasing with time. |
There was a problem hiding this comment.
OK, if we are leaving these in here, there are a couple of changes I would suggest.
| * The difference in sensor memory usage didn’t seem to be increasing with time. | |
| * The difference in sensor memory usage apparently did not appear to increase over time. |
There was a problem hiding this comment.
I went with
The difference in Sensor memory usage did not appear to increase with time
|
@JoukoVirtanen: This pull request references ROX-30739 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
Co-authored-by: Kerry Carmichael <kcarmich@redhat.com>
I am no longer using "auto-locking". |
|
@JoukoVirtanen: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
4 participants
Version(s):
4.9
Issue:
Link to docs preview: https://100444--ocpdocs-pr.netlify.app/openshift-acs/latest/operating/evaluate-security-risks.html#auto-lock-process-baselines_evaluate-security-risks
QE review:
Additional information: