Skip to content

docs(accessanalyzer): document the aa operations command in 26.1 - #1839

Draft
thobed wants to merge 1 commit into
devfrom
thobed/aa-1977-aa-ops-command
Draft

thobed wants to merge 1 commit into
devfrom
thobed/aa-1977-aa-ops-command

Conversation

@thobed

@thobed thobed commented Nov 7, 2026

Copy link
Copy Markdown
Collaborator

Documents the aa command that netwrix-corp/access-analyzer adds to the Access Analyzer installer (AA-1977, https://netwrix.atlassian.net/browse/AA-1977).

Merge after the Access Analyzer release that ships aa. The page has a TODO for that release's version.

  • New page Install > Run Common Operations with aa (docs/accessanalyzer/26.1/install/run-common-operations-with-aa.md). It covers status, database shells, restarts, shells in a service, scan jobs, the kubectl passthrough, logs, tab completion and troubleshooting.
  • Seven VHS recordings (animated WebP) made on a k3s installer VM as a non-root user.
  • A tip on View and Export Logs and a short section in the installer reference link to the page.

Vale and Dale pass on the new page.

Adds Run Common Operations with aa: status, database shells (psql,
clickhouse-client, redis-cli), rolling restarts, shells in a service,
scan jobs, the kubectl passthrough, logs and tab completion, with seven
VHS recordings from an installer VM. Links it from View and Export Logs
and the installer reference. AA-1977.
@thobed
thobed deployed to development November 7, 2026 12:29 — with GitHub Actions Active
@github-actions github-actions Bot added the access-analyzer Access Analyzer 26.1 (latest version) label Nov 7, 2026
@github-actions

github-actions Bot commented Nov 7, 2026

Copy link
Copy Markdown
Contributor

Documentation PR Review

Editorial Review

docs/accessanalyzer/26.1/install/installer-reference.md

  • Clarity — Line 494: This one sentence lists four actions with "and" and then adds a fifth clause with ", and it runs itself with sudo...", so the sudo behavior reads like a fifth task. Split it in two. Suggested fix: "The installer links /usr/local/bin/aa to dspm-installer. Run under that name, the binary checks service status, opens database shells, restarts services, and runs kubectl in the access-analyzer namespace. When you start it as an account other than root, it runs itself again with sudo. See Run Common Operations with aa."

docs/accessanalyzer/26.1/install/run-common-operations-with-aa.md

  • Completeness — Line 9: The {/* TODO: name the Access Analyzer release whose installer first adds aa */} marker is still there. Readers on older releases need to know whether they have aa, and the Troubleshooting row for aa: command not found depends on that fact. Suggested fix: Replace the TODO with a sentence such as "The installer adds aa starting with Access Analyzer ."
  • Structure — Line 17: "Every aa command acts with full administrator rights on the cluster..." isn't something the reader has to do before they begin. It's a caution, so it gets lost in the prerequisites list. Suggested fix: Move it out of the list into a :::warning after Before You Begin: "Every aa command runs with full administrator rights on the cluster. A database query you run or a service you restart takes effect immediately."
  • Clarity — Line 41: "Argo CD applications" is the first and only mention of Argo CD on the page, and the term isn't defined. Readers who are new to Kubernetes won't know what an Argo CD application is or why it matters to them. Suggested fix: "aa status lists the Argo CD applications (the deployment units that install and update each part of Access Analyzer), with their sync and health status, and then every pod in the access-analyzer namespace."
  • Clarity — Line 71: "Ctrl+C cancels the running query and keeps the session open" covers all three clients. In redis-cli interactive mode, Ctrl+C usually exits the session. Check the behavior of each client and limit the statement to the clients where it holds. Suggested fix: "In psql and clickhouse-client, Ctrl+C cancels the running query and keeps the session open."
  • Clarity — Line 90: "Kubernetes starts a new pod, and stops the old one when the new pod is ready" describes how a Deployment restarts. The same paragraph names clickhouse as a service you can restart, and it runs as a StatefulSet. A StatefulSet restart stops each pod before it starts the replacement, so that service is briefly unavailable. Suggested fix: Add "For a StatefulSet such as clickhouse or postgres, Kubernetes replaces one pod at a time, so the service is unavailable until its new pod is ready."
  • Completeness — Line 99: The example aa k rollout status deployment/webapp works only for Deployments. The paragraph doesn't say what to run for a StatefulSet service such as clickhouse. Suggested fix: "aa k rollout status deployment/<service> waits until the restart finishes. For a StatefulSet, use statefulset/<service>."
  • Clarity — Line 156: In "such as within a few minutes after you run another aa command", the phrase "such as" doesn't fit, and "a few minutes" is vague. Suggested fix: "For an account other than root, they complete only while sudo still has your password cached, which by default is 15 minutes after you last entered it."
  • Completeness — Line 163: "Run the commands as sudo dspm-installer instead" assumes every aa subcommand also exists under dspm-installer. The page confirms this only for logs and export-logs (line 141). Readers won't know whether sudo dspm-installer psql or sudo dspm-installer restart works. Suggested fix: Say which commands are available under dspm-installer, for example "Run the same commands as sudo dspm-installer <command>, such as sudo dspm-installer status." If only some of them work there, say which.

docs/accessanalyzer/26.1/install/view-and-export-logs.md

  • Clarity — Line 15: "and don't need sudo" can be read as saying that aa works for accounts without sudo rights. It doesn't: aa runs itself with sudo, so the account still needs sudo rights and might be asked for its password. Suggested fix: "aa logs and aa export-logs run the same commands with a shorter name, and you don't need to type sudo. Your account still needs sudo rights. See Run Common Operations with aa."

Summary

10 editorial suggestions across 3 files. Vale and Dale issues are auto-fixed separately.


What to do next:

Comment @claude on this PR followed by your instructions to get help:

  • @claude fix all issues — fix all editorial issues
  • @claude help improve the flow of this document — get writing assistance
  • @claude explain the voice issues — understand why something was flagged

You can ask Claude anything about the review or about Netwrix writing standards.

Automated fixes are only available for branches in this repository, not forks.

@github-actions

github-actions Bot commented Nov 7, 2026

Copy link
Copy Markdown
Contributor

Auto-Fix Summary

0 issues fixed, 2 skipped across 3 files

Skipped (needs manual review) Reason

| docs/accessanalyzer/26.1/install/run-common-operations-with-aa.md:119 — Dale: passive-voice | 'how the run was started' has no stated actor (user, schedule, or system), so an active rewrite would have to invent one |
| docs/accessanalyzer/26.1/install/installer-reference.md:34 — Dale: wordiness | 'There are no single-letter flags.' is already short; a rewrite would not be meaningfully more concise |

Ask @claude on this PR if you'd like an explanation of any fix.

This branch was successfully deployed

1 active deployment
development — b2d06f4b Deployed Nov 7, 2026 by thobed via build-and-deploy #5062
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

access-analyzer Access Analyzer 26.1 (latest version)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant