docs: Add deployment guide based on revised kustomization logic#228
docs: Add deployment guide based on revised kustomization logic#228shayan1995 merged 6 commits intomainfrom
Conversation
|
Thanks @shayan1995 Revised doc location and added some edits. Will continue tomorrow. |
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-03-11 02:00:14 UTC | Commit: 09020a9 |
🛡️ Vulnerability Scan🚨 Found 64 vulnerability(ies) Severity Breakdown:
🔗 View full details in Security tab 🕐 Last updated: 2026-03-11 02:00:20 UTC | Commit: 09020a9 |
Signed-off-by: Tareque Hossain <thossain@nvidia.com>
📝 WalkthroughWalkthroughAdds comprehensive Kubernetes deployment documentation (quick-start and detailed installation) and a new bash script to generate and optionally deploy a self-signed root CA for cluster PKI; no code or API surface changes. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
thossain-nv
left a comment
There was a problem hiding this comment.
Looks good, thanks @shayan1995
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
scripts/gen-site-ca.sh (2)
145-171: Consider avoidingevalby executing commands directly.Using
evalto execute shell commands stored in variables can be fragile and is generally discouraged. Since the commands are well-defined, they can be executed directly.♻️ Suggested refactor
-# ---- Build kubectl commands ---------------------------------------- -APPLY_NS_CMD="kubectl create secret tls ca-signing-secret \ - --cert=$TMP_DIR/ca.crt \ - --key=$TMP_DIR/ca.key \ - -n $NAMESPACE \ - --dry-run=client -o yaml | kubectl apply -f -" - -APPLY_CM_CMD="kubectl create secret tls ca-signing-secret \ - --cert=$TMP_DIR/ca.crt \ - --key=$TMP_DIR/ca.key \ - -n cert-manager \ - --dry-run=client -o yaml | kubectl apply -f -" +# ---- Helper function to apply secret ------------------------------ +apply_secret() { + local ns="$1" + kubectl create secret tls ca-signing-secret \ + --cert="$TMP_DIR/ca.crt" \ + --key="$TMP_DIR/ca.key" \ + -n "$ns" \ + --dry-run=client -o yaml | kubectl apply -f - +} + +# For dry-run display +show_cmd() { + local ns="$1" + echo " kubectl create secret tls ca-signing-secret \\" + echo " --cert=$TMP_DIR/ca.crt \\" + echo " --key=$TMP_DIR/ca.key \\" + echo " -n $ns \\" + echo " --dry-run=client -o yaml | kubectl apply -f -" +} if [[ "$DRY_RUN" == "true" ]]; then warn "Dry-run mode — commands that would be run:" - echo " $APPLY_NS_CMD" - echo " $APPLY_CM_CMD" + show_cmd "$NAMESPACE" + show_cmd "cert-manager" exit 0 fi # ---- Apply CA secrets to cluster ---------------------------------- info "Creating ca-signing-secret in namespace '${NAMESPACE}'…" -eval "$APPLY_NS_CMD" +apply_secret "$NAMESPACE" ok "ca-signing-secret created in '${NAMESPACE}'" info "Creating ca-signing-secret in namespace 'cert-manager'…" if kubectl get namespace cert-manager >/dev/null 2>&1; then - eval "$APPLY_CM_CMD" + apply_secret "cert-manager" ok "ca-signing-secret created in 'cert-manager'" else warn "Namespace 'cert-manager' not found — skipping. Create it after cert-manager is installed:" - echo " $APPLY_CM_CMD" + show_cmd "cert-manager" fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/gen-site-ca.sh` around lines 145 - 171, The script currently builds kubectl command strings in APPLY_NS_CMD and APPLY_CM_CMD and executes them with eval, which is fragile; change the implementation to execute the kubectl commands directly (or store the command as a bash array and call it) instead of using eval: replace the eval "$APPLY_NS_CMD" and eval "$APPLY_CM_CMD" invocations with direct command execution (or array expansion) and ensure the DRY_RUN handling still prints the command strings when DRY_RUN=="true"; update both the namespace-create and cert-manager-create code paths (references: APPLY_NS_CMD, APPLY_CM_CMD, DRY_RUN, and the two eval usages).
114-120: Consider preserving stderr for debugging.Redirecting stderr to
/dev/nullhides potentially useful error messages from OpenSSL if the command fails.📝 Suggested improvement
openssl req -x509 -sha256 -nodes -newkey rsa:4096 \ -keyout "$TMP_DIR/ca.key" \ -out "$TMP_DIR/ca.crt" \ -days "$CA_DAYS" \ -config "$TMP_DIR/ca.cnf" \ - -extensions v3_ca \ - 2>/dev/null + -extensions v3_caIf suppressing output is intentional (e.g., to hide progress indicators), consider redirecting only specific output or using
-quietif available.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/gen-site-ca.sh` around lines 114 - 120, The openssl req invocation in scripts/gen-site-ca.sh currently hides all stderr with "2>/dev/null", which suppresses useful error messages; update the openssl command that writes TMP_DIR/ca.key and TMP_DIR/ca.crt (using CA_DAYS and TMP_DIR/ca.cnf with -extensions v3_ca) to either remove the "2>/dev/null" redirection so errors are visible, or redirect stderr to a log file or variable (e.g., "$TMP_DIR/openssl.err") or use the "-quiet" flag if you only want to silence progress, ensuring any real errors remain captured for debugging.deploy/INSTALLATION.md (2)
292-292: Minor grammar: use hyphens for compound adjectives.The phrase "static/well known in cluster services" should use hyphens for clarity.
📝 Suggested fix
-The ClusterIssuer is used for generating mTLS certs for static/well known in cluster services. +The ClusterIssuer is used for generating mTLS certs for static/well-known in-cluster services.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/INSTALLATION.md` at line 292, The sentence describing the ClusterIssuer uses unhyphenated compound adjectives; update the phrase "static/well known in cluster services" to use hyphens so it reads "static/well-known in-cluster services" (keep the existing references to carbide-rest-ca-issuer and ca-signing-secret unchanged).
20-43: Consider adding language identifiers to fenced code blocks.Static analysis flagged several code blocks without language specifiers. While these are directory structure diagrams (not executable code), adding a language identifier improves rendering and accessibility.
📝 Suggested fix for the directory structure block
-``` +```text deploy/kustomize/ ├── base/ # Reusable base manifests (not applied directly)Similarly, consider using
textorplaintextfor other non-code blocks at lines 67, 111, 332, and 727.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/INSTALLATION.md` around lines 20 - 43, The fenced directory-tree code block beginning with the block containing "deploy/kustomize/" and other non-code fenced blocks that show directory diagrams should include a language identifier (e.g., change ``` to ```text) so they render/accessibly as plain text; locate the fenced block that starts with the deploy/kustomize directory tree and any other similar directory-listing fenced blocks in the INSTALLATION.md and replace the opening backticks with ```text (or ```plaintext) for each.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deploy/INSTALLATION.md`:
- Line 932: Update the Secrets Reference table entry for `db-creds` (currently
showing only `carbide-rest-db-migration`) to include all actual consumers: add
`carbide-rest-api` and `carbide-rest-workflow` alongside
`carbide-rest-db-migration`, and ensure the source column still points to
`base/common/db-creds.yaml` and the secret owner/service column still notes
`carbide-rest`; update any surrounding doc text if it references the old
consumer list so the sections for `carbide-rest-api` and `carbide-rest-workflow`
accurately reflect that they consume the `db-creds` secret.
In `@deploy/README.md`:
- Around line 61-63: Update the README command to remove the redundant namespace
flag: change the Keycloak apply command to use only "kubectl apply -k
deploy/kustomize/base/keycloak" because the namespace is already declared in the
kustomization.yaml (namespace: carbide-rest) — ensure you reference the
kustomization.yaml (the file declaring namespace) and update the README line
that currently includes "-n carbide-rest".
---
Nitpick comments:
In `@deploy/INSTALLATION.md`:
- Line 292: The sentence describing the ClusterIssuer uses unhyphenated compound
adjectives; update the phrase "static/well known in cluster services" to use
hyphens so it reads "static/well-known in-cluster services" (keep the existing
references to carbide-rest-ca-issuer and ca-signing-secret unchanged).
- Around line 20-43: The fenced directory-tree code block beginning with the
block containing "deploy/kustomize/" and other non-code fenced blocks that show
directory diagrams should include a language identifier (e.g., change ``` to
```text) so they render/accessibly as plain text; locate the fenced block that
starts with the deploy/kustomize directory tree and any other similar
directory-listing fenced blocks in the INSTALLATION.md and replace the opening
backticks with ```text (or ```plaintext) for each.
In `@scripts/gen-site-ca.sh`:
- Around line 145-171: The script currently builds kubectl command strings in
APPLY_NS_CMD and APPLY_CM_CMD and executes them with eval, which is fragile;
change the implementation to execute the kubectl commands directly (or store the
command as a bash array and call it) instead of using eval: replace the eval
"$APPLY_NS_CMD" and eval "$APPLY_CM_CMD" invocations with direct command
execution (or array expansion) and ensure the DRY_RUN handling still prints the
command strings when DRY_RUN=="true"; update both the namespace-create and
cert-manager-create code paths (references: APPLY_NS_CMD, APPLY_CM_CMD, DRY_RUN,
and the two eval usages).
- Around line 114-120: The openssl req invocation in scripts/gen-site-ca.sh
currently hides all stderr with "2>/dev/null", which suppresses useful error
messages; update the openssl command that writes TMP_DIR/ca.key and
TMP_DIR/ca.crt (using CA_DAYS and TMP_DIR/ca.cnf with -extensions v3_ca) to
either remove the "2>/dev/null" redirection so errors are visible, or redirect
stderr to a log file or variable (e.g., "$TMP_DIR/openssl.err") or use the
"-quiet" flag if you only want to silence progress, ensuring any real errors
remain captured for debugging.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 704c2369-b56e-4f03-a24a-260a71b90ecd
📒 Files selected for processing (4)
README.mddeploy/INSTALLATION.mddeploy/README.mdscripts/gen-site-ca.sh
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
deploy/INSTALLATION.md (4)
292-292: Clarify the phrase "static/well known in cluster services."The phrase "static/well known in cluster services" could be clearer with hyphens: "static/well-known, in-cluster services" to better convey that these are well-known services running within the cluster.
📝 Suggested rewording
-The ClusterIssuer is used for generating mTLS certs for static/well known in cluster services. +The ClusterIssuer is used for generating mTLS certs for static, well-known in-cluster services.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/INSTALLATION.md` at line 292, Update the sentence that mentions "static/well known in cluster services" to a clearer phrasing: replace it with "static/well-known, in-cluster services" (or similar) so it reads that the ClusterIssuer `carbide-rest-ca-issuer` (using `ca-signing-secret`) is used for generating mTLS certs for static/well-known, in-cluster services; ensure the ClusterIssuer name `carbide-rest-ca-issuer` and secret `ca-signing-secret` remain unchanged.
20-43: Consider adding language identifier to code block.The directory structure code block (line 20) is missing a language identifier. Adding
textorplaintextwould improve syntax highlighting and markdown compliance.📝 Suggested fix
-``` +```text deploy/kustomize/ ├── base/ # Reusable base manifests (not applied directly)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/INSTALLATION.md` around lines 20 - 43, The fenced code block showing the deploy/kustomize directory tree lacks a language identifier; update the opening fence (the triple backticks before "deploy/kustomize/") to include a language such as text or plaintext (e.g., change ``` to ```text) so the block becomes a properly annotated code block; ensure the closing triple backticks remain unchanged and commit the updated INSTALLATION.md.
417-431: Add verification for Temporal namespace creation.After creating the
cloudandsitenamespaces, consider adding a verification step to confirm they were created successfully before proceeding.📋 Suggested verification commands
# Verify namespaces were created kubectl exec -it -n temporal deployment/temporal-admintools -- \ temporal operator namespace list \ --address temporal-frontend.temporal:7233 | grep -E 'cloud|site'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/INSTALLATION.md` around lines 417 - 431, Add a verification step after the two temporal operator namespace create commands: run the temporal operator namespace list command from the temporal-admintools pod (using the same --address temporal-frontend.temporal:7233) and confirm the output contains both "cloud" and "site"; document the expected success output and a suggested retry/exit action if either namespace is missing so the installer can stop and re-run creation before proceeding.
186-189: Consider centralizing database credential management.Requiring manual synchronization of passwords across four separate files (
admin-creds.yaml,init-configmap.yaml,base/common/db-creds.yaml,base/temporal-helm/db-creds.yaml) is error-prone and creates a maintenance burden. Password mismatches can lead to authentication failures at runtime.Consider one of these approaches:
- Use Kustomize
secretGeneratorwith a single source file that all components reference- Document a script or tool to update all locations atomically
- Use an external secret management solution (e.g., External Secrets Operator, Vault) to inject credentials at runtime
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/INSTALLATION.md` around lines 186 - 189, The docs currently require manually syncing DB passwords across admin-creds.yaml, init-configmap.yaml, base/common/db-creds.yaml, and base/temporal-helm/db-creds.yaml which is error-prone; update INSTALLATION.md to prescribe a single source-of-truth credential approach: replace the manual step with instructions to centralize credentials using one of the suggested methods (e.g., add a Kustomize secretGenerator workflow referencing one creds file and show how components reference that secret, or include a short documented script to propagate an updated password to all four files atomically, or outline how to use an external secret manager like External Secrets Operator/Vault to inject credentials); reference the four filenames (admin-creds.yaml, init-configmap.yaml, base/common/db-creds.yaml, base/temporal-helm/db-creds.yaml) and provide concise commands/examples for the chosen approach so operators can follow a single canonical procedure.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deploy/INSTALLATION.md`:
- Around line 736-755: The TEMPORAL_SUBSCRIBE_QUEUE value in the kubectl patch
for the configmap carbide-rest-site-agent-config is incorrectly set to the
literal "site" instead of the site UUID; update the patch that replaces
/data/TEMPORAL_SUBSCRIBE_QUEUE to use the $SITE_UUID variable (same as
/data/CLUSTER_ID) so TEMPORAL_SUBSCRIBE_QUEUE is the per-site queue name,
ensuring the site agent polls the correct Temporal queue.
---
Nitpick comments:
In `@deploy/INSTALLATION.md`:
- Line 292: Update the sentence that mentions "static/well known in cluster
services" to a clearer phrasing: replace it with "static/well-known, in-cluster
services" (or similar) so it reads that the ClusterIssuer
`carbide-rest-ca-issuer` (using `ca-signing-secret`) is used for generating mTLS
certs for static/well-known, in-cluster services; ensure the ClusterIssuer name
`carbide-rest-ca-issuer` and secret `ca-signing-secret` remain unchanged.
- Around line 20-43: The fenced code block showing the deploy/kustomize
directory tree lacks a language identifier; update the opening fence (the triple
backticks before "deploy/kustomize/") to include a language such as text or
plaintext (e.g., change ``` to ```text) so the block becomes a properly
annotated code block; ensure the closing triple backticks remain unchanged and
commit the updated INSTALLATION.md.
- Around line 417-431: Add a verification step after the two temporal operator
namespace create commands: run the temporal operator namespace list command from
the temporal-admintools pod (using the same --address
temporal-frontend.temporal:7233) and confirm the output contains both "cloud"
and "site"; document the expected success output and a suggested retry/exit
action if either namespace is missing so the installer can stop and re-run
creation before proceeding.
- Around line 186-189: The docs currently require manually syncing DB passwords
across admin-creds.yaml, init-configmap.yaml, base/common/db-creds.yaml, and
base/temporal-helm/db-creds.yaml which is error-prone; update INSTALLATION.md to
prescribe a single source-of-truth credential approach: replace the manual step
with instructions to centralize credentials using one of the suggested methods
(e.g., add a Kustomize secretGenerator workflow referencing one creds file and
show how components reference that secret, or include a short documented script
to propagate an updated password to all four files atomically, or outline how to
use an external secret manager like External Secrets Operator/Vault to inject
credentials); reference the four filenames (admin-creds.yaml,
init-configmap.yaml, base/common/db-creds.yaml,
base/temporal-helm/db-creds.yaml) and provide concise commands/examples for the
chosen approach so operators can follow a single canonical procedure.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 9d184877-c7f0-488e-b1bd-229eeb908c38
📒 Files selected for processing (3)
README.mddeploy/INSTALLATION.mddeploy/README.md
🚧 Files skipped from review as they are similar to previous changes (2)
- README.md
- deploy/README.md
| ```bash | ||
| SITE_UUID=<your-site-uuid> | ||
| OTP=<otp-from-site-cr-status> | ||
| CA_B64=$(kubectl get secret ca-signing-secret -n carbide-rest -o jsonpath='{.data.tls\.crt}') | ||
|
|
||
| kubectl patch secret site-registration -n carbide-rest --type='json' -p="[ | ||
| {\"op\": \"replace\", \"path\": \"/data/site-uuid\", \"value\": \"$(echo -n $SITE_UUID | base64)\"}, | ||
| {\"op\": \"replace\", \"path\": \"/data/otp\", \"value\": \"$(echo -n $OTP | base64)\"}, | ||
| {\"op\": \"replace\", \"path\": \"/data/cacert\", \"value\": \"$CA_B64\"} | ||
| ]" | ||
|
|
||
| # Also update CLUSTER_ID in the configmap to match SITE_UUID | ||
| kubectl patch configmap carbide-rest-site-agent-config -n carbide-rest --type='json' -p="[ | ||
| {\"op\": \"replace\", \"path\": \"/data/CLUSTER_ID\", \"value\": \"$SITE_UUID\"}, | ||
| {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_NAMESPACE\", \"value\": \"$SITE_UUID\"}, | ||
| {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_QUEUE\", \"value\": \"site\"} | ||
| ]" | ||
|
|
||
| kubectl rollout restart statefulset/carbide-rest-site-agent -n carbide-rest | ||
| ``` |
There was a problem hiding this comment.
Critical inconsistency in TEMPORAL_SUBSCRIBE_QUEUE configuration.
Line 751 sets TEMPORAL_SUBSCRIBE_QUEUE to the literal string "site", but line 712 documents that this variable should be set to the site UUID to match the per-site Temporal queue. This mismatch would cause the site agent to poll the wrong queue and fail to receive site-specific workflow tasks.
🐛 Proposed fix
kubectl patch configmap carbide-rest-site-agent-config -n carbide-rest --type='json' -p="[
{\"op\": \"replace\", \"path\": \"/data/CLUSTER_ID\", \"value\": \"$SITE_UUID\"},
{\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_NAMESPACE\", \"value\": \"$SITE_UUID\"},
- {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_QUEUE\", \"value\": \"site\"}
+ {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_QUEUE\", \"value\": \"$SITE_UUID\"}
]"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```bash | |
| SITE_UUID=<your-site-uuid> | |
| OTP=<otp-from-site-cr-status> | |
| CA_B64=$(kubectl get secret ca-signing-secret -n carbide-rest -o jsonpath='{.data.tls\.crt}') | |
| kubectl patch secret site-registration -n carbide-rest --type='json' -p="[ | |
| {\"op\": \"replace\", \"path\": \"/data/site-uuid\", \"value\": \"$(echo -n $SITE_UUID | base64)\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/otp\", \"value\": \"$(echo -n $OTP | base64)\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/cacert\", \"value\": \"$CA_B64\"} | |
| ]" | |
| # Also update CLUSTER_ID in the configmap to match SITE_UUID | |
| kubectl patch configmap carbide-rest-site-agent-config -n carbide-rest --type='json' -p="[ | |
| {\"op\": \"replace\", \"path\": \"/data/CLUSTER_ID\", \"value\": \"$SITE_UUID\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_NAMESPACE\", \"value\": \"$SITE_UUID\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_QUEUE\", \"value\": \"site\"} | |
| ]" | |
| kubectl rollout restart statefulset/carbide-rest-site-agent -n carbide-rest | |
| ``` | |
| SITE_UUID=<your-site-uuid> | |
| OTP=<otp-from-site-cr-status> | |
| CA_B64=$(kubectl get secret ca-signing-secret -n carbide-rest -o jsonpath='{.data.tls\.crt}') | |
| kubectl patch secret site-registration -n carbide-rest --type='json' -p="[ | |
| {\"op\": \"replace\", \"path\": \"/data/site-uuid\", \"value\": \"$(echo -n $SITE_UUID | base64)\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/otp\", \"value\": \"$(echo -n $OTP | base64)\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/cacert\", \"value\": \"$CA_B64\"} | |
| ]" | |
| # Also update CLUSTER_ID in the configmap to match SITE_UUID | |
| kubectl patch configmap carbide-rest-site-agent-config -n carbide-rest --type='json' -p="[ | |
| {\"op\": \"replace\", \"path\": \"/data/CLUSTER_ID\", \"value\": \"$SITE_UUID\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_NAMESPACE\", \"value\": \"$SITE_UUID\"}, | |
| {\"op\": \"replace\", \"path\": \"/data/TEMPORAL_SUBSCRIBE_QUEUE\", \"value\": \"$SITE_UUID\"} | |
| ]" | |
| kubectl rollout restart statefulset/carbide-rest-site-agent -n carbide-rest |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deploy/INSTALLATION.md` around lines 736 - 755, The TEMPORAL_SUBSCRIBE_QUEUE
value in the kubectl patch for the configmap carbide-rest-site-agent-config is
incorrectly set to the literal "site" instead of the site UUID; update the patch
that replaces /data/TEMPORAL_SUBSCRIBE_QUEUE to use the $SITE_UUID variable
(same as /data/CLUSTER_ID) so TEMPORAL_SUBSCRIBE_QUEUE is the per-site queue
name, ensuring the site agent polls the correct Temporal queue.
Description
Added the installation guide based on the latest kustomization logic
Type of Change
Services Affected
Breaking Changes
Testing
Additional Notes
None