Skip to content

Insights Export Config#78

Merged
keitwb merged 1 commit intorh-ecosystem-edge:mainfrom
keitwb:insights-config
Aug 11, 2025
Merged

Insights Export Config#78
keitwb merged 1 commit intorh-ecosystem-edge:mainfrom
keitwb:insights-config

Conversation

@keitwb
Copy link
Contributor

@keitwb keitwb commented Jul 31, 2025

There are several PRs that the SRE and Insights team need to approve before this will
work locally or in staging but it should give us most of the config we would need
to use this feature and start collecting the feedback/transcript data for research.

Summary by CodeRabbit

  • New Features

    • Added a data-export sidecar to send feedback and transcript data to an external insights service.
    • Switched enablement flags so feedback and transcript collection are enabled by default.
    • New configurable parameters for insights integration: server URL, secret reference, service ID, and collection interval.
  • Chores

    • Updated deployment and configuration to support the exporter, its config, and resource settings.

@openshift-ci openshift-ci bot requested review from maorfr and omertuc July 31, 2025 18:01
@coderabbitai
Copy link

coderabbitai bot commented Jul 31, 2025

Walkthrough

Inverted feedback/transcript flags to enabling semantics, added parameters for an external insights ingress and exporter interval, created a new exporter ConfigMap, and introduced a lightspeed-to-dataverse-exporter sidecar container and related volumes/env to export feedback and transcript data externally.

Changes

Cohort / File(s) Change Summary
Flag inversion & parameters
template.yaml
Removed LIGHTSPEED_FEEDBACK_DISABLED, LIGHTSPEED_TRANSCRIPTS_DISABLED; added LIGHTSPEED_FEEDBACK_ENABLED, LIGHTSPEED_TRANSCRIPTS_ENABLED (default true) and new parameters INSIGHTS_INGRESS_SERVER_URL, INSIGHTS_INGRESS_SECRET_NAME, INSIGHTS_SERVICE_ID, LIGHTSPEED_EXPORTER_COLLECTION_INTERVAL_SECONDS.
ConfigMaps
template.yaml
Updated lightspeed-stack config to use new enablement flags and added data_collector.enabled: false. Added lightspeed-exporter-config ConfigMap containing config.yaml with data_dir, allowed_subdirs, service/identity IDs, ingress URL, collection_interval, cleanup_after_send, and timeout.
Deployment / Sidecar
template.yaml
Added lightspeed-to-dataverse-exporter container (manual mode) with env from secret (INGRESS_SERVER_AUTH_TOKEN via INSIGHTS_INGRESS_SECRET_NAME), resource requests/limits, mounts for lightspeed-exporter-config and data-storage volumes, and added exporter ConfigMap volume.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant MainApp
    participant ExporterSidecar
    participant InsightsIngress

    User->>MainApp: Submit feedback/transcript
    MainApp->>Volume: Persist feedback/transcript files
    loop Every collection_interval
        ExporterSidecar->>Volume: Read allowed_subdirs (feedback, transcripts)
        ExporterSidecar->>InsightsIngress: POST data (uses service_id, identity_id, auth token)
        InsightsIngress-->>ExporterSidecar: Acknowledge
        ExporterSidecar->>Volume: Optionally cleanup sent files
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 30a136e and c0febba.

📒 Files selected for processing (1)
  • template.yaml (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • template.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Red Hat Konflux / assisted-chat-saas-main-on-pull-request
✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

‼️ IMPORTANT
Auto-reply has been disabled for this repository in the CodeRabbit settings. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@openshift-ci
Copy link

openshift-ci bot commented Jul 31, 2025

Hi @keitwb. Thanks for your PR.

I'm waiting for a rh-ecosystem-edge member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🔭 Outside diff range comments (1)
template.yaml (1)

365-383: Incorrect parameter syntax – ${{…}} will not be substituted by oc

OpenShift template parameters use ${PARAM}. The double-brace form appears in several places and will leak into the rendered manifest.

-replicas: ${{REPLICAS_COUNT}}
+replicas: ${REPLICAS_COUNT}

-            containerPort: ${{SERVICE_PORT}}
+            containerPort: ${SERVICE_PORT}

Same issue further down for Service.port and Route.targetPort.

Without this fix the generated deployment is invalid.

🧹 Nitpick comments (5)
template-params.dev.yaml (1)

1-8: Consider renaming the file or adding a header to avoid format confusion

The file is named *.yaml but actually follows the KEY=VALUE format expected by oc process --param-file. New contributors (or linters) may assume strict YAML and mis-edit the file.

Two lightweight options:

- template-params.dev.yaml
+ template-params.dev.env         # clearer

or keep the name but add a short comment header:

+## NOTE: Not YAML – plain KEY=VALUE lines consumed by `oc process --param-file`
 IMAGE_TAG=latest
scripts/generate.sh (2)

8-16: Quote path variables to guard against spaces

OVERRIDE_FILE may legitimately live in a directory containing spaces, which would break the generated command line.

-OVERRIDE_FILE=$PROJECT_ROOT/.template-params.override.yaml
+OVERRIDE_FILE="$PROJECT_ROOT/.template-params.override.yaml"

Same applies to ${OVERRIDE_PARAMS-} in the oc process invocation.


28-35: OVERRIDE_PARAMS is used without early initialisation

If the override file does not exist, ${OVERRIDE_PARAMS-} expands to the empty string ‑ good.
When the file does exist, OVERRIDE_PARAMS is defined inside the subshell of the if block; this still works in Bash, but explicit initialisation improves readability:

-# implicit unset
+OVERRIDE_PARAMS=""
 if [[ -f "$OVERRIDE_FILE" ]]; then
-  OVERRIDE_PARAMS="--param-file=$OVERRIDE_FILE"
+  OVERRIDE_PARAMS="--param-file=\"$OVERRIDE_FILE\""
 fi
template.yaml (2)

79-84: Description copy-paste error for INSIGHTS_DATA_COLLECTOR_ENABLED

The description repeats the interval text and doesn’t state what the flag does.

- description: "How often to send feedback/transcript archives to the insights service"
+ description: "Enable/disable periodic upload of archives to the insights service"

169-172: Quoting numeric & boolean substitutions inside ConfigMap for predictable types

YAML interprets bare true/false as booleans and bare numbers as ints.
If any parameter ever becomes a string (e.g., "false" vs false), the resulting type drift can break the application. Consider quoting all substituted values inside ConfigMaps.

Example:

-        feedback_enabled: ${LIGHTSPEED_FEEDBACK_ENABLED}
+        feedback_enabled: "${LIGHTSPEED_FEEDBACK_ENABLED}"
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8315c15 and 8ef0c05.

📒 Files selected for processing (4)
  • lightspeed-stack.template.yaml (0 hunks)
  • scripts/generate.sh (2 hunks)
  • template-params.dev.yaml (1 hunks)
  • template.yaml (5 hunks)
💤 Files with no reviewable changes (1)
  • lightspeed-stack.template.yaml
🔇 Additional comments (1)
template.yaml (1)

64-72: Boolean parameter defaults invert behaviour between template & dev param file

Template default sets both LIGHTSPEED_FEEDBACK_ENABLED and LIGHTSPEED_TRANSCRIPTS_ENABLED to "true" whereas template-params.dev.yaml sets them to false.
That is fine for dev ↔ prod differences, but please document this explicitly in README or the parameter descriptions to avoid future confusion.

Comment on lines 32 to 28
oc process --local \
-f $PROJECT_ROOT/template.yaml \
${OVERRIDE_PARAMS-} \
--param-file=$PROJECT_ROOT/template-params.dev.yaml | \
yq '.items[] | select(.kind == "ConfigMap" and .metadata.name == "lightspeed-stack-config").data."lightspeed-stack.yaml"' -r \
> $PROJECT_ROOT/config/lightspeed-stack.yaml

yq -r '.objects[] | select(.metadata.name == "lightspeed-stack-config") | .data.system_prompt' "$PROJECT_ROOT/template.yaml" > "$PROJECT_ROOT/config/system_prompt"

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

System-prompt extraction bypasses parameter substitution

system_prompt is taken straight from template.yaml, while lightspeed-stack.yaml is produced from the processed template.
If the prompt ever becomes parameterised, the two files will diverge.

Recommend extracting from the processed output as well:

-yq -r '.objects[] | select(.metadata.name == "lightspeed-stack-config") | .data.system_prompt' "$PROJECT_ROOT/template.yaml" > "$PROJECT_ROOT/config/system_prompt"
+oc process --local \
+  -f "$PROJECT_ROOT/template.yaml" \
+  ${OVERRIDE_PARAMS-} \
+  --param-file="$PROJECT_ROOT/template-params.dev.yaml" | \
+  yq -r '.items[] | select(.kind == "ConfigMap" and .metadata.name == "lightspeed-stack-config").data.system_prompt' \
+  > "$PROJECT_ROOT/config/system_prompt"
📝 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.

Suggested change
oc process --local \
-f $PROJECT_ROOT/template.yaml \
${OVERRIDE_PARAMS-} \
--param-file=$PROJECT_ROOT/template-params.dev.yaml | \
yq '.items[] | select(.kind == "ConfigMap" and .metadata.name == "lightspeed-stack-config").data."lightspeed-stack.yaml"' -r \
> $PROJECT_ROOT/config/lightspeed-stack.yaml
yq -r '.objects[] | select(.metadata.name == "lightspeed-stack-config") | .data.system_prompt' "$PROJECT_ROOT/template.yaml" > "$PROJECT_ROOT/config/system_prompt"
oc process --local \
-f $PROJECT_ROOT/template.yaml \
${OVERRIDE_PARAMS-} \
--param-file=$PROJECT_ROOT/template-params.dev.yaml | \
yq '.items[] | select(.kind == "ConfigMap" and .metadata.name == "lightspeed-stack-config").data."lightspeed-stack.yaml"' -r \
> $PROJECT_ROOT/config/lightspeed-stack.yaml
oc process --local \
-f "$PROJECT_ROOT/template.yaml" \
${OVERRIDE_PARAMS-} \
--param-file="$PROJECT_ROOT/template-params.dev.yaml" | \
yq -r '.items[] | select(.kind == "ConfigMap" and .metadata.name == "lightspeed-stack-config").data.system_prompt' \
> "$PROJECT_ROOT/config/system_prompt"
🤖 Prompt for AI Agents
In scripts/generate.sh around lines 32 to 40, the system_prompt is extracted
directly from the unprocessed template.yaml, bypassing parameter substitution,
which can cause divergence if parameters are added. Modify the script to extract
system_prompt from the processed output (the result of oc process) instead of
the raw template.yaml, ensuring both lightspeed-stack.yaml and system_prompt
reflect the same parameter substitutions.

Copy link
Collaborator

@eranco74 eranco74 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@eranco74
Copy link
Collaborator

/hold

We can't use the data collection yet until the SRE team merges all of the policy MRs.

Copy link
Member

@omertuc omertuc Jul 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extension is .yaml but it doesn't seem like a YAML file. Also any reason not to use the existing .env and .env.template files for this?

Copy link
Contributor Author

@keitwb keitwb Jul 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, fixed the file extension.

Copy link
Contributor Author

@keitwb keitwb Jul 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to be a difference between referencing things in the template via the ${env.FOO} and just direct template params.

@omertuc
Copy link
Member

omertuc commented Jul 31, 2025

/ok-to-test

@keitwb keitwb force-pushed the insights-config branch 5 times, most recently from bd55b1f to f2017bf Compare August 4, 2025 15:44
@keitwb keitwb marked this pull request as draft August 4, 2025 19:52
@keitwb keitwb changed the title Insights Export Config + Local Config from template.yaml Insights Export Config Aug 5, 2025
@keitwb keitwb force-pushed the insights-config branch 4 times, most recently from 4793533 to 0fb7dbb Compare August 6, 2025 16:55
@keitwb keitwb force-pushed the insights-config branch 2 times, most recently from cecb6ee to e752432 Compare August 6, 2025 19:40
@keitwb keitwb marked this pull request as ready for review August 6, 2025 19:44
@openshift-ci openshift-ci bot requested a review from omertuc August 6, 2025 19:44
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f2017bf and e752432.

📒 Files selected for processing (1)
  • template.yaml (4 hunks)
🔇 Additional comments (1)
template.yaml (1)

59-65: Default-to-“enabled” silently flips previous behavior

The old parameters were _DISABLED with default false; replacing them with _ENABLED and default "true" enables feedback & transcript collection in every fresh deployment. Unless this is an intentional policy change already communicated to all environments, consider defaulting to "false" (opt-in) to avoid unexpected data capture.

template.yaml Outdated
Comment on lines +75 to +79
value: "1800" # 30 minutes
description: "How often to send feedback/transcript archives to the insights service"
- name: INSIGHTS_DATA_COLLECTOR_ENABLED
value: "true"
description: "Whether the data export of feedback/transcripts to the insights ingress server is enabled or not"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

INSIGHTS_DATA_COLLECTOR_ENABLED is unused – side-car always runs

The template defines a flag to toggle the exporter but never references it when assembling spec.template.spec.containers. The exporter container will therefore launch even when the parameter is set to "false". Gate the container (or at least set command: ["sleep","infinity"]) behind this parameter.

🤖 Prompt for AI Agents
In template.yaml around lines 75 to 79, the INSIGHTS_DATA_COLLECTOR_ENABLED
parameter is defined but not used to conditionally include or disable the
exporter sidecar container. To fix this, modify the container specification in
spec.template.spec.containers to check the value of
INSIGHTS_DATA_COLLECTOR_ENABLED. If it is "false", either omit the exporter
container or set its command to ["sleep","infinity"] to prevent it from running.
This ensures the exporter sidecar only runs when explicitly enabled.

Comment on lines +152 to +155
feedback_enabled: ${LIGHTSPEED_FEEDBACK_ENABLED}
feedback_storage: "${STORAGE_MOUNT_PATH}/feedback"
transcripts_disabled: ${LIGHTSPEED_TRANSCRIPTS_DISABLED}
transcripts_enabled: ${LIGHTSPEED_TRANSCRIPTS_ENABLED}
transcripts_storage: "${STORAGE_MOUNT_PATH}/transcripts"
data_collector:
# We use the external collector as a sidecar
enabled: false
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Mismatch between internal & external collectors

user_data_collection.data_collector.enabled is hard-coded to false. If the exporter side-car is disabled (see issue above) the system will collect data to disk but never ship it. Consider wiring enabled: ${INSIGHTS_DATA_COLLECTOR_ENABLED} so both components stay consistent.

🤖 Prompt for AI Agents
In template.yaml around lines 152 to 158, the data_collector.enabled field is
hard-coded to false, causing a mismatch between internal data collection and the
external exporter sidecar. To fix this, replace the hard-coded false with a
parameter reference like ${INSIGHTS_DATA_COLLECTOR_ENABLED} so that enabling or
disabling the data collector is consistent across components.

Comment on lines +450 to +475
- name: lightspeed-to-dataverse-exporter
# TODO: change this to the official repo once it gets integrated in lightspeed build
# pipeline
image: quay.io/ometelka/lightspeed-dataverse-exporter:latest
imagePullPolicy: Always
args:
- "--mode"
- "manual"
- "--config"
- "/etc/config/config.yaml"
- "--log-level"
- "INFO"
env:
- name: INGRESS_SERVER_AUTH_TOKEN
valueFrom:
secretKeyRef:
name: ${INSIGHTS_INGRESS_SECRET_NAME}
key: auth_token
resources:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Side-car image is mutable latest and lives in a personal repo

quay.io/ometelka/lightspeed-dataverse-exporter:latest + the TODO comment jeopardises reproducibility and supply-chain security. Pin to a digest or versioned tag in an official org namespace before merging. Example:

- image: quay.io/ometelka/lightspeed-dataverse-exporter:latest
+ image: quay.io/lightspeed-core/lightspeed-dataverse-exporter:v0.1.0   # pinned
📝 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.

Suggested change
- name: lightspeed-to-dataverse-exporter
# TODO: change this to the official repo once it gets integrated in lightspeed build
# pipeline
image: quay.io/ometelka/lightspeed-dataverse-exporter:latest
imagePullPolicy: Always
args:
- "--mode"
- "manual"
- "--config"
- "/etc/config/config.yaml"
- "--log-level"
- "INFO"
env:
- name: INGRESS_SERVER_AUTH_TOKEN
valueFrom:
secretKeyRef:
name: ${INSIGHTS_INGRESS_SECRET_NAME}
key: auth_token
resources:
- name: lightspeed-to-dataverse-exporter
# TODO: change this to the official repo once it gets integrated in lightspeed build
# pipeline
image: quay.io/lightspeed-core/lightspeed-dataverse-exporter:v0.1.0 # pinned
imagePullPolicy: Always
args:
- "--mode"
- "manual"
- "--config"
- "/etc/config/config.yaml"
- "--log-level"
- "INFO"
env:
- name: INGRESS_SERVER_AUTH_TOKEN
valueFrom:
secretKeyRef:
name: ${INSIGHTS_INGRESS_SECRET_NAME}
key: auth_token
resources:
🤖 Prompt for AI Agents
In template.yaml around lines 450 to 468, the sidecar image uses the mutable
'latest' tag from a personal repository, which risks reproducibility and
supply-chain security. Replace the image tag with a fixed versioned tag or a
digest from an official organization namespace, and update the TODO comment
accordingly to reflect this change before merging.

@eranco74
Copy link
Collaborator

eranco74 commented Aug 6, 2025

/ok-to-test

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (4)
template.yaml (4)

149-156: Internal/external collector mismatch remains
user_data_collection.data_collector.enabled is still hard-coded to false, so the application writes feedback/transcripts to disk while the in-process collector is disabled. If the exporter side-car is also gated (see previous comment) nothing will ever ship the data. Wire this flag to the same parameter you use to control the exporter so they stay consistent.


450-451: Mutable latest tag from a personal repository – pin the image
Using quay.io/ometelka/lightspeed-dataverse-exporter:latest compromises reproducibility and supply-chain security. Pin to a digest or a versioned tag in an official org namespace before you merge.


65-76: Exporter cannot be disabled – introduce an INSIGHTS_EXPORTER_ENABLED flag
The template adds multiple Insights-related parameters but never provides a way to disable the exporter. Given the SRE “/hold” until policies are merged, the inability to turn the side-car off is risky (PII leakage / policy breach).

Add a boolean parameter and reference it in the container block (see lines 447-478).

+# Controls whether the dataverse exporter side-car is started
+- name: INSIGHTS_EXPORTER_ENABLED
+  value: false
+  description: "Enable the lightspeed-to-dataverse exporter side-car"

Then gate the container with a simple entry-point guard (or omit the container entirely when false).


447-478: Side-car always runs regardless of policy flag – potential PII leak
Because the exporter container is unconditionally listed, it will start in every environment, even where data export is forbidden. Until the SRE policies are merged this must be suppressible.

Minimal workaround (assuming you add INSIGHTS_EXPORTER_ENABLED, default false):

         env:
+        - name: INSIGHTS_EXPORTER_ENABLED
+          value: ${INSIGHTS_EXPORTER_ENABLED}
@@
-          args:
-          - "--mode"
-          - "manual"
-          - "--config"
-          - "/etc/config/config.yaml"
-          - "--log-level"
-          - "INFO"
+          command:
+          - /bin/bash
+          - -c
+          - |
+            if [[ "${INSIGHTS_EXPORTER_ENABLED}" == "true" ]]; then
+              exec /usr/local/bin/lightspeed-dataverse-exporter \
+                   --mode manual \
+                   --config /etc/config/config.yaml \
+                   --log-level INFO
+            else
+              exec sleep infinity
+            fi

This prevents the binary from executing unless explicitly enabled.

🧹 Nitpick comments (2)
template.yaml (2)

59-65: Prefer un-quoted booleans for template parameters
Quoting the default values ("true") turns them into strings. Several downstream components (especially Helm/YAML-parsed configs) expect a real boolean and will silently treat the string "true" as truthy but not boolean, which can break .Values interpolation and logical checks.
Remove the quotes so the parameters expand to the native YAML boolean.

-  value: "true"
+  value: true

542-543: collection_interval should be numeric
The parameter default is quoted, so the rendered YAML becomes a string ("1800"). If the exporter strictly parses integers this will fail at start-up. Drop the quotes in the parameter default or wrap the value here in !!int to force YAML integer typing.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e752432 and 4dd3d3d.

📒 Files selected for processing (1)
  • template.yaml (4 hunks)

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (4)
template.yaml (4)

450-451: Mutable latest tag from a personal repo – still unresolved
The image reference quay.io/ometelka/lightspeed-dataverse-exporter:latest repeats the supply-chain & reproducibility concerns flagged in the previous review. Pin to a digest or versioned tag in an official org namespace before shipping.


447-478: Side-car unconditionally runs ‒ gate it or sleep
Same issue raised previously: the exporter container is inserted regardless of whether the feature is enabled.
A minimal fix that keeps the template simple is to wrap the real command in a shell gate:

-          args:
-          - "--mode"
-          - "manual"
-          - "--config"
-          - "/etc/config/config.yaml"
-          - "--log-level"
-          - "INFO"
+          command:
+          - /bin/sh
+          - "-c"
+          - |
+            if [ "${INSIGHTS_DATA_COLLECTOR_ENABLED}" = "true" ]; then
+              exec /usr/local/bin/lightspeed-dataverse-exporter \
+                   --mode manual \
+                   --config /etc/config/config.yaml \
+                   --log-level INFO
+            else
+              echo "Insights exporter disabled"; sleep infinity
+            fi
+          env:
+          - name: INSIGHTS_DATA_COLLECTOR_ENABLED
+            value: ${INSIGHTS_DATA_COLLECTOR_ENABLED}

66-76: Missing master toggle for the exporter side-car
You introduce several parameters for exporter connectivity, but there is still no boolean such as INSIGHTS_DATA_COLLECTOR_ENABLED (or similar) to decide whether the side-car should even be started.
Without it, clusters that do not have the secret or external approval will still launch a container that loops and fails.

+# - name: INSIGHTS_DATA_COLLECTOR_ENABLED
+#   value: "false"
+#   description: "Set to true to start the insights exporter side-car"

149-156: Keep internal & external collectors consistent
data_collector.enabled is hard-coded to false while the exporter side-car is always present. Couple this field to the (missing) master toggle so the YAML cannot get out of sync:

-  enabled: false
+  enabled: ${INSIGHTS_DATA_COLLECTOR_ENABLED}
🧹 Nitpick comments (2)
template.yaml (2)

483-485: Tighten ConfigMap volume permissions
Mount the exporter config read-only to prevent accidental mutation from the container:

-        - name: lightspeed-exporter-config
-          configMap:
-            name: lightspeed-exporter-config
+        - name: lightspeed-exporter-config
+          configMap:
+            name: lightspeed-exporter-config
+          defaultMode: 0440

532-539: YAML list indentation is off by one space
The items under allowed_subdirs must be indented two spaces deeper than the key to be valid YAML.

-      allowed_subdirs:
-       - feedback
-       - transcripts
+      allowed_subdirs:
+        - feedback
+        - transcripts
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4dd3d3d and 30a136e.

📒 Files selected for processing (1)
  • template.yaml (4 hunks)
🔇 Additional comments (1)
template.yaml (1)

59-65: Positive-logic flags are clearer – good move
Switching from “_DISABLED” to “_ENABLED” parameters removes the double-negative mental overhead and aligns with Kubernetes style conventions.

Copy link
Collaborator

@eranco74 eranco74 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
Just the exporter image issue.

- name: lightspeed-to-dataverse-exporter
# TODO: change this to the official repo once it gets integrated in lightspeed build
# pipeline
image: quay.io/ometelka/lightspeed-dataverse-exporter:latest
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can use this image in app sre env

@openshift-ci openshift-ci bot added the lgtm label Aug 7, 2025
There are several PRs that the SRE and Insights team need to approve before this will
work locally or in staging but it should give us most of the config we would need
to use this feature and start collecting the feedback/transcript data for research.
@openshift-ci openshift-ci bot removed the lgtm label Aug 11, 2025
@eranco74
Copy link
Collaborator

/approve
/lgtm

@openshift-ci openshift-ci bot added the lgtm label Aug 11, 2025
@openshift-ci
Copy link

openshift-ci bot commented Aug 11, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eranco74, keitwb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@keitwb keitwb merged commit 0383036 into rh-ecosystem-edge:main Aug 11, 2025
5 checks passed
@keitwb keitwb deleted the insights-config branch August 11, 2025 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants