[INFRA-275] Plane-EE: Add plane AI Services #180
Conversation
- Added OpenSearch service configuration in values.yaml, including image, credentials, and service settings. - Introduced new PI service configurations with options for AI providers and worker settings. - Updated PostgreSQL configuration to create an additional database for PI. - Enhanced deployment templates to include pod scheduling for various services. - Added environment variables for OpenSearch and PI services to support new functionalities.
- Introduced new settings for the Plane AI (PI) service, including options for enabling the service, configuring AI providers, and setting resource limits. - Added environment variables for OAuth and CORS settings related to the PI service. - Included configurations for PI Worker and PI Beat Worker with resource management options. - Updated external secrets configuration for PI API and common environments.
- Renamed groups for PI Worker and PI Beat Worker settings to improve clarity. - Added new configuration options for OpenSearch, including installation settings, Docker image, pull policy, service port, volume size, and authentication details. - Introduced external secrets configuration for OpenSearch to enhance security and manageability.
- Modified default password values in questions.yml and values.yaml for OpenSearch to enhance security. - Updated references in opensearchdb.yaml and pgdb.yaml to reflect the new password format. - Cleaned up whitespace in values.yaml for better readability.
…db.yaml - Introduced OPENSEARCH_INITIAL_ADMIN_PASSWORD to the OpenSearch secrets configuration. - Ensured the new password field defaults to the existing password value for consistency.
…yaml - Removed initContainers and integrated pod scheduling directly into the container spec. - Added environment variable OPENSEARCH_USER sourced from a ConfigMap for user creation. - Updated volume mounts to include a new ConfigMap for initialization scripts. - Cleaned up unused volume definitions to streamline the configuration.
…teful.yaml - Introduced an init container to verify the availability of the OpenSearch service and validate user authentication before the main container starts. - Added environment variables sourced from a ConfigMap for user credentials. - Updated volume mount configurations for initialization scripts to ensure proper permissions and access.
…ssion fixes - Added an initialization script to opensearchdb.yaml for modifying internal user configurations and ensuring the necessary directory structure. - Introduced an init container in opensearch.stateful.yaml to fix permissions for the OpenSearch data directory, ensuring proper access rights. - Updated security context settings for both the main and init containers to enhance security and compliance with best practices.
….stateful.yaml - Eliminated the init container responsible for adjusting permissions on the OpenSearch data directory, streamlining the configuration. - Retained the init container for user verification to ensure proper service availability before the main container starts.
….stateful.yaml - Removed the 'set -e' command from the OpenSearch initialization script in opensearchdb.yaml for improved script execution flow. - Eliminated resource limits and requests from the OpenSearch StatefulSet configuration in opensearch.stateful.yaml to simplify resource management. - Added OPENSEARCH_JAVA_OPTS environment variable to optimize Java memory settings for OpenSearch.
…stateful.yaml - Eliminated the init container that verified OpenSearch service availability and user authentication, simplifying the deployment configuration. - Adjusted environment variable settings to ensure proper configuration without the init container.
- Changed the default Docker image for OpenSearch from version 2.11.0 to version 3 in both questions.yml and values.yaml to ensure the latest features and improvements are utilized.
…yaml - Removed security context settings for the OpenSearch container and pod, simplifying the configuration. - Updated volume mount names for consistency and added service account configuration for improved access control.
…ty context updates - Added commands to ensure the OpenSearch data directory exists and is writable in opensearchdb.yaml. - Updated security context in opensearch.stateful.yaml to specify user and group IDs for improved security compliance.
- Added new ingress paths for the pi-api and marketplace services in ingress.yaml. - Updated readiness probe path for the pi-api deployment to match the new API endpoint in pi-api.deployment.yaml.
- Introduced new configuration options for the PI database, including 'PI DB Name' and 'PI DB Remote URL'. - These options are conditionally displayed based on the local setup of the PostgreSQL service.
…env.yaml - Removed trailing slashes from PLANE_FRONTEND_URL and CORS_ALLOWED_ORIGINS to ensure proper URL formatting. - Updated conditional logic to maintain consistency across environment configurations.
…ling slash - Modified the FEATURE_FLAG_SERVER_BASE_URL to eliminate the trailing slash for consistent URL formatting across configurations.
- Introduced a new configuration option for the Coherence API Key in questions.yml and values.yaml. - Updated pi-api-env.yaml to conditionally include the COHERENCE_API_KEY in the generated secrets based on the new configuration.
- Added conditional logic for OPENSEARCH_PASSWORD, OPENSEARCH_ENABLED, OPENSEARCH_URL, OPENSEARCH_USERNAME, and OPENSEARCH_INDEX_PREFIX in app-env.yaml and pi-common-env.yaml based on local setup and environment variables. - Updated pi-api-env.yaml to rename COHERENCE_API_KEY to COHERE_API_KEY for consistency.
|
Linked to Plane Work Item(s) This comment was auto-generated by Plane |
WalkthroughAdds Plane AI (PI) feature: new PI workloads (api, worker, beat, migrator), PI ConfigMaps/Secrets and values/questions; optional local OpenSearch (init script, Secret/ConfigMap, StatefulSet); adjusted Postgres secret/config guards; ingress paths for /pi/ and /marketplace/; and consolidated pod-scheduling includes into pod template specs. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Client
participant Ingress
participant PI_API as "pi-api Service"
participant Postgres
participant RabbitMQ
participant OpenSearch
participant PI_Worker as "pi-worker / pi-beat"
Client->>Ingress: HTTP request (/pi/...)
Ingress->>PI_API: route to pi-api (port 8000)
PI_API->>Postgres: read/write PI DB (local or remote)
PI_API->>RabbitMQ: publish Celery tasks
PI_API->>OpenSearch: index/query vectors (local or remote)
RabbitMQ->>PI_Worker: deliver task messages
PI_Worker->>OpenSearch: index vectors / ML operations
Note right of OpenSearch: if local_setup=true, create-user.sh runs during init to ensure user
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🪛 YAMLlint (1.37.1)charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml[error] 1-1: syntax error: expected the node content, but found '-' (syntax) 🔇 Additional comments (1)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🧹 Nitpick comments (11)
charts/plane-enterprise/values.yaml (5)
322-356: PI service configuration structure is sound, but documentation and validation may be needed.The new Plane AI (PI) service block with nested
ai_providersfollows the existing patterns in the chart and provides flexibility for multi-provider support. However, consider:
- Documentation: Users need clarity on which AI providers are supported and how to configure them. Add inline comments explaining the purpose of each provider's
enabledandapi_keyfields.- Validation: No apparent runtime validation ensures that required
api_keyvalues are provided when a provider is enabled. Consider adding validation logic in Helm templates or noting this requirement in documentation.- Dependency tracking: If
pi.enabled=true, the configuration ofpi_envs(lines 478–494) becomes mandatory. Document this relationship.Would you like me to help add validation logic to the Helm templates to ensure that when PI is enabled, required secrets and configuration values are present?
405-407: Verify interdependencies between database configurations.The PR introduces a separate PI database configuration (
pg_pi_db_name,pg_pi_db_remote_url). Ensure that:
- When
pg_pi_db_remote_urlis empty andservices.postgres.local_setup=true, the PI database is properly initialized in the shared PostgreSQL instance.- Documentation clarifies whether PI requires a dedicated PostgreSQL instance or can share with the main database.
- Any required database initialization scripts or migrations are executed during deployment.
Can you verify that the Postgres initialization template (if one exists) properly provisions the PI database when local_setup is enabled?
421-424: OpenSearch URL configuration requires validation and documentation.The
opensearch_urlis empty by default, which means:
- If
services.opensearch.local_setup=true, the URL must be auto-derived or set by the deployment templates.- If
services.opensearch.local_setup=false, this value must be provided by the user, but there is no validation to enforce this.Ensure templates handle this dependency and document the requirement.
Can you verify that the OpenSearch-consuming templates (e.g., PI API) properly validate and use this configuration?
478-494: PI environment configuration: Clarify OAuth and Celery settings.The new
pi_envsblock introduces several configuration options:
plane_oauth: Theredirect_uriis empty by default. Is this auto-generated based on the deployment ingress, or must users provide it? Document or automate this.state_expiry_seconds(hardcoded to 82800): Consider whether this should be configurable or if 23 hours is always appropriate.- Celery settings: The
vector_sync_enabledanddocs_sync_enableddefault tofalse. Clarify whether users should enable these and what the performance implications are.Add comments or examples to guide users through configuration.
83-96: Consider versioning strategy for OpenSearch image.The OpenSearch image is pinned to the major version only (
opensearchproject/opensearch:3). This allows minor/patch updates automatically, which is good for security, but:
- Verify compatibility: Ensure that Helm templates and environment variables are tested against OpenSearch 3.x versions (e.g., 3.0, 3.1+).
- Document breaking changes: If OpenSearch 4.x is released during the lifecycle of this chart, document the upgrade path.
Consider whether you want tighter pinning (e.g.,
3.2.0) for reproducibility or looser pinning for automatic security updates.charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml (2)
54-55: Remove redundantserviceAccountfield; keep onlyserviceAccountName.Both fields reference the same value. Modern Kubernetes uses only
serviceAccountName(line 55). TheserviceAccountfield (line 54) is deprecated and redundant.serviceAccount: {{ .Release.Name }}-srv-account - serviceAccountName: {{ .Release.Name }}-srv-account + serviceAccountName: {{ .Release.Name }}-srv-account
1-61: Remove excess blank lines at end of file.Lines 60–61 contain unnecessary blank lines. YAMLlint reports "too many blank lines (4 > 0)".
{{- end }} - - - -charts/plane-enterprise/templates/config-secrets/opensearchdb.yaml (1)
67-68: Remove extra blank line at end of file.YAMLlint reports "too many blank lines (1 > 0)" at line 68.
charts/plane-enterprise/templates/workloads/opensearch.stateful.yaml (1)
1-106: Remove extra blank line at end of file.YAMLlint reports "too many blank lines (1 > 0)" at line 107.
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml (2)
37-49: Consider centralizing OpenSearch configuration logic.Lines 37–49 duplicate the three-tier OpenSearch conditional logic from app-env.yaml (lines 90–105). While this ensures PI has correct configuration, the duplication increases maintenance burden. Consider using a Helm template helper or shared ConfigMap to reduce duplication.
This is a refactor opportunity for future work, but the current implementation is functionally correct.
71-71: Simplify DEBUG flag assignment.Line 71 uses inline conditional with extra whitespace. Consider simplifying:
- DEBUG: {{ if .Values.services.pi.debug }} "1" {{- else -}} "0" {{ end }} + DEBUG: {{ .Values.services.pi.debug | ternary "1" "0" | quote }}This improves readability and consistency with other ternary patterns in the file.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (32)
charts/plane-enterprise/questions.yml(5 hunks)charts/plane-enterprise/templates/config-secrets/app-env.yaml(2 hunks)charts/plane-enterprise/templates/config-secrets/opensearchdb.yaml(1 hunks)charts/plane-enterprise/templates/config-secrets/pgdb.yaml(2 hunks)charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml(1 hunks)charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml(1 hunks)charts/plane-enterprise/templates/config-secrets/postgres-init.yaml(1 hunks)charts/plane-enterprise/templates/ingress.yaml(1 hunks)charts/plane-enterprise/templates/workloads/admin.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/api.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/automation-consumer.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/beat-worker.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/email.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/iframely.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/live.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/migrator.job.yaml(1 hunks)charts/plane-enterprise/templates/workloads/minio.stateful.yaml(2 hunks)charts/plane-enterprise/templates/workloads/monitor.stateful.yaml(1 hunks)charts/plane-enterprise/templates/workloads/opensearch.stateful.yaml(1 hunks)charts/plane-enterprise/templates/workloads/outbox-poller.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-api.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/postgres.stateful.yaml(2 hunks)charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml(1 hunks)charts/plane-enterprise/templates/workloads/redis.stateful.yaml(1 hunks)charts/plane-enterprise/templates/workloads/silo.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/space.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/web.deployment.yaml(2 hunks)charts/plane-enterprise/templates/workloads/worker.deployment.yaml(1 hunks)charts/plane-enterprise/values.yaml(5 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml
[warning] 61-61: too many blank lines (4 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/opensearchdb.yaml
[warning] 68-68: too many blank lines (1 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml
[warning] 50-50: too many blank lines (4 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/postgres-init.yaml
[warning] 16-16: too many blank lines (1 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/opensearch.stateful.yaml
[warning] 107-107: too many blank lines (1 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/pgdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-api.deployment.yaml
[warning] 92-92: too many blank lines (4 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml
[warning] 61-61: too many blank lines (4 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (34)
charts/plane-enterprise/templates/workloads/automation-consumer.deployment.yaml (1)
21-21: Pod scheduling consolidation looks good.The podScheduling include is correctly placed at the pod spec level before containers, aligning with the systematic consolidation pattern across workload templates.
charts/plane-enterprise/templates/workloads/redis.stateful.yaml (1)
42-42: Pod scheduling consolidation for StatefulSet is correct.The podScheduling include is properly placed at the StatefulSet pod spec level before containers, following the refactor pattern consistently.
charts/plane-enterprise/templates/workloads/live.deployment.yaml (1)
43-43: Pod scheduling consolidation is correctly positioned.The podScheduling include is placed at the appropriate pod spec level before containers, maintaining consistency with the broader refactor.
charts/plane-enterprise/templates/workloads/iframely.deployment.yaml (1)
40-40: Pod scheduling consolidation properly integrated.The podScheduling include is correctly positioned at the pod spec level before containers, maintaining the refactor consistency even with the service conditional gating.
charts/plane-enterprise/templates/workloads/silo.deployment.yaml (1)
44-44: Pod scheduling consolidation is correctly placed before initContainers.The podScheduling include is properly positioned at the pod spec level before initContainers, which is the appropriate ordering for pod-level configuration in the Kubernetes spec structure.
charts/plane-enterprise/templates/workloads/api.deployment.yaml (1)
43-43: Pod scheduling consolidation is correctly positioned in complex deployment.The podScheduling include is properly placed at the pod spec level before the volumes block, maintaining all existing functionality including airgapped S3 certificate handling and multiple secret references.
charts/plane-enterprise/templates/workloads/web.deployment.yaml (1)
43-43: Pod scheduling consolidation is correctly positioned.The podScheduling include is properly placed at the pod spec level before containers, maintaining consistency with the systematic refactor across workload templates.
charts/plane-enterprise/templates/workloads/space.deployment.yaml (1)
43-43: Pod scheduling consolidation is correctly positioned.The podScheduling include is properly placed at the pod spec level before containers, maintaining consistency with the systematic refactor across all workload templates.
charts/plane-enterprise/templates/workloads/outbox-poller.deployment.yaml (1)
20-22: Verify podScheduling include consolidation across templates.The
podSchedulinginclude has been moved earlier in the pod spec (before containers). This aligns with the broader refactoring across multiple workload templates. Ensure that the include directive properly expands pod-level scheduling hints (nodeSelector, affinity, tolerations) and that there are no duplicate scheduling configurations elsewhere in the template.charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml (1)
42-44: Consistent pod scheduling placement in StatefulSet.The
podSchedulinginclude is properly positioned at the pod spec level for the StatefulSet, before containers. This maintains consistency with the Deployment templates refactored in this PR.charts/plane-enterprise/templates/workloads/admin.deployment.yaml (1)
42-44: Pod scheduling consolidation consistent with refactoring pattern.The
podSchedulinginclude positioned before containers in the Deployment pod spec follows the established pattern in this PR. No concerns detected.charts/plane-enterprise/templates/workloads/monitor.stateful.yaml (1)
39-41: Pod scheduling consolidation in StatefulSet maintained.The
podSchedulinginclude is correctly positioned at the StatefulSet pod spec level, consistent with the PR's refactoring across multiple workloads.charts/plane-enterprise/templates/workloads/worker.deployment.yaml (1)
19-21: Pod scheduling consolidation in Deployment maintained.The
podSchedulinginclude is correctly positioned before containers, consistent with the broader refactoring across all workload templates.charts/plane-enterprise/templates/workloads/minio.stateful.yaml (1)
42-44: Pod scheduling consolidation in StatefulSet and Job maintained.The
podSchedulinginclude is correctly positioned in both the StatefulSet pod spec (line 43) and the Job template spec (line 97), consistent with the refactoring pattern. Both placements are semantically correct for their respective workload types.charts/plane-enterprise/templates/workloads/email.deployment.yaml (1)
48-50: Pod scheduling consolidation in Deployment maintained.The
podSchedulinginclude is correctly positioned before containers, maintaining consistency with the refactoring pattern across all workload templates.charts/plane-enterprise/templates/workloads/migrator.job.yaml (1)
1-46: Pod scheduling consolidation looks good.The podScheduling include is correctly positioned at the pod spec level before the containers block, aligning with the broader refactoring across workload templates.
charts/plane-enterprise/templates/ingress.yaml (1)
76-89: New ingress paths for PI and Marketplace integrations look correct.The routes correctly map
/pi/to the pi-api service and/marketplace/to the api service, both on port 8000. Ensure the referenced service names exist in the cluster before deployment.charts/plane-enterprise/templates/workloads/beat-worker.deployment.yaml (1)
20-20: Pod scheduling placement and syntax are correct.The include is properly positioned and uses dashes to strip whitespace, maintaining YAML integrity.
charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml (1)
24-36: Verify PI configuration ConfigMaps and Secrets are created in the chart.The deployment references four external configurations:
{{ .Release.Name }}-pi-api-vars(ConfigMap){{ .Release.Name }}-pi-api-secrets(Secret){{ .Release.Name }}-pi-common-vars(ConfigMap){{ .Release.Name }}-pi-common-secrets(Secret)Ensure these are generated by the corresponding config-secrets templates (e.g., pi-api-env.yaml, pi-common-env.yaml) before this Job executes, as required fields are marked
optional: false.charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml (1)
37-49: Verify PI configuration ConfigMaps and Secrets are created in the chart.The deployment references PI-specific configurations with
optional: false, requiring them to exist before pod scheduling. Confirm that config-secrets templates create:
{{ .Release.Name }}-pi-api-vars(ConfigMap){{ .Release.Name }}-pi-api-secrets(Secret){{ .Release.Name }}-pi-common-vars(ConfigMap){{ .Release.Name }}-pi-common-secrets(Secret)charts/plane-enterprise/templates/workloads/pi-api.deployment.yaml (2)
1-88: PI API Deployment structure and configuration look solid.The Service and Deployment are correctly gated on
.Values.services.pi.enabled, with proper pod scheduling, resource limits, and a reasonable readiness probe (30s timeout with 10s intervals). The probe path/pi/correctly aligns with the ingress routing added in ingress.yaml.
58-70: Verify PI configuration ConfigMaps and Secrets are created in the chart.The deployment requires the same set of PI-specific configurations as other PI workloads, all marked as non-optional. Ensure config-secrets templates (pi-api-env.yaml, pi-common-env.yaml) create these resources before the Deployment is instantiated.
charts/plane-enterprise/templates/config-secrets/app-env.yaml (2)
39-45: LGTM: OpenSearch password configuration properly gated.The three-level conditional (local_setup → external URL → disabled) correctly handles different deployment scenarios with sensible defaults.
90-105: LGTM: OpenSearch environment variables well-structured.Configuration properly responds to deployment mode with appropriate URL construction for local in-cluster access and fallback for external instances. Index prefix and username defaults are sensible.
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml (1)
52-57: LGTM: Celery sync configuration well-structured.Proper use of ternary operators with sensible defaults. Configuration enables flexible control over vector sync, workspace plan sync, and docs sync intervals.
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml (2)
10-49: LGTM: Secret configuration comprehensive and properly gated.AI provider keys, database URLs, and broker configuration are well-structured with appropriate conditional logic and fallbacks. Default empty strings prevent unintended errors.
89-89: Quote PLANE_OAUTH_CLIENT_ID value.Line 89 assigns PLANE_OAUTH_CLIENT_ID without quotes, which could cause YAML parsing errors if the value contains special characters or spaces.
- PLANE_OAUTH_CLIENT_ID: {{ .Values.env.pi_envs.plane_oauth.client_id | quote }} + PLANE_OAUTH_CLIENT_ID: {{ .Values.env.pi_envs.plane_oauth.client_id | quote }}Ensure the filter
| quoteis applied to properly escape the value.Likely an incorrect or invalid review comment.
charts/plane-enterprise/questions.yml (5)
747-902: LGTM: PI service configuration comprehensive and well-organized.The PI service block properly gates functionality with enable flags and provides well-structured subquestions for all major configuration needs (OAuth, AI providers, Celery). The pattern matches existing service configuration style.
1046-1065: LGTM: PI database variables properly introduced.New PI database variables (
pg_pi_db_namefor local,pg_pi_db_remote_urlfor remote) follow established pattern from main database configuration. Conditional visibility based onpostgres.local_setupis correct.
1067-1125: LGTM: OpenSearch configuration follows service setup patterns.OpenSearch local_setup block properly mirrors Redis and RabbitMQ patterns with image, credentials, storage, and external URL fallback. Configuration is comprehensive and well-organized.
1336-1340: LGTM: OpenSearch external secret integration properly configured.External secret option for OpenSearch follows existing pattern and appears in correct group. Enables users to provide pre-created secrets.
1361-1370: LGTM: PI external secrets properly integrated.New PI API and PI Common environment external secret options follow established pattern and provide flexibility for secret management integrations.
charts/plane-enterprise/templates/config-secrets/opensearchdb.yaml (1)
21-65: The OpenSearch image configuration is correct and includes the required security plugin.The default image
opensearchproject/opensearch:3specified inquestions.yml(line 1077) includes the Security plugin with thehash.shtool at/usr/share/opensearch/plugins/opensearch-security/tools/. The script references in the initialization file will execute successfully without modification.charts/plane-enterprise/templates/workloads/opensearch.stateful.yaml (1)
59-72: Review comment contains factual errors and is based on incorrect assumptions.The review comment claims "container resource limits default to 1000Mi (lines 33)" which is incorrect:
- Line 33 contains the
serviceNamedefinition, not resource limits.- No container resource limits are defined anywhere in the opensearch.stateful.yaml template. Lines 100-102 reference storage requests in the PersistentVolumeClaim, not container memory limits.
- The
plane.podSchedulingtemplate only handles nodeSelector, tolerations, and affinity—not resources.- The values.yaml opensearch configuration contains no memory or resource settings.
While the JAVA_OPTS are indeed hardcoded to
-Xms768m -Xmx768m(lines 63-64), there is no container memory limit to exceed. The actual issue is the absence of resource limits and the inability to configure JAVA_OPTS via values.A valid concern would be to either:
- Add container resource limits (requests/limits) aligned with the JAVA_OPTS, or
- Make JAVA_OPTS configurable through values.yaml instead of hardcoding them.
Likely an incorrect or invalid review comment.
| if grep -q "^${OPENSEARCH_USER}:" "$INTERNAL_USERS_FILE"; then | ||
| echo "User ${OPENSEARCH_USER} already exists in internal_users.yml" | ||
| else | ||
| echo "Adding user ${OPENSEARCH_USER} to internal_users.yml" | ||
| cat << EOF >> "$INTERNAL_USERS_FILE" |
There was a problem hiding this comment.
Escape OPENSEARCH_USER in grep pattern to prevent regex injection.
The variable ${OPENSEARCH_USER} is used in an unquoted grep regex pattern (line 47). If the username contains regex metacharacters, it could cause unintended matches or failures.
Apply this fix to escape the username:
- if grep -q "^${OPENSEARCH_USER}:" "$INTERNAL_USERS_FILE"; then
+ if grep -qF "^${OPENSEARCH_USER}:" "$INTERNAL_USERS_FILE"; thenThe -F flag treats the pattern as a fixed string, preventing regex interpretation.
📝 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.
| if grep -q "^${OPENSEARCH_USER}:" "$INTERNAL_USERS_FILE"; then | |
| echo "User ${OPENSEARCH_USER} already exists in internal_users.yml" | |
| else | |
| echo "Adding user ${OPENSEARCH_USER} to internal_users.yml" | |
| cat << EOF >> "$INTERNAL_USERS_FILE" | |
| if grep -qF "^${OPENSEARCH_USER}:" "$INTERNAL_USERS_FILE"; then | |
| echo "User ${OPENSEARCH_USER} already exists in internal_users.yml" | |
| else | |
| echo "Adding user ${OPENSEARCH_USER} to internal_users.yml" | |
| cat << EOF >> "$INTERNAL_USERS_FILE" |
🤖 Prompt for AI Agents
In charts/plane-enterprise/templates/config-secrets/opensearchdb.yaml around
lines 47 to 51, the grep call uses the unescaped ${OPENSEARCH_USER} as a regex
which allows regex metacharacters to alter matching; change the grep invocation
to treat the pattern as a fixed string (for example use grep -F) and ensure the
variable is properly quoted to avoid word-splitting so the check becomes a
fixed-string search of "${OPENSEARCH_USER}" in "$INTERNAL_USERS_FILE".
| {{- if .Values.env.pi_envs.cors_allowed_origins }} | ||
| CORS_ALLOWED_ORIGINS: {{ .Values.env.pi_envs.cors_allowed_origins | quote }} | ||
| {{- else }} | ||
| CORS_ALLOWED_ORIGINS: ["http://{{ .Values.license.licenseDomain }}", "https://{{ .Values.license.licenseDomain }}"] | ||
| {{- end }} |
There was a problem hiding this comment.
🧩 Analysis chain
Script executed:
#!/bin/bash
# Search for CORS_ALLOWED_ORIGINS usage in the repository
rg -n 'CORS_ALLOWED_ORIGINS' -C 3Repository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stdout:
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-75- PI_BASE_PATH: "/pi"
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-76-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-77- {{- if .Values.env.pi_envs.cors_allowed_origins }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:78: CORS_ALLOWED_ORIGINS: {{ .Values.env.pi_envs.cors_allowed_origins | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-79- {{- else }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:80: CORS_ALLOWED_ORIGINS: ["http://{{ .Values.license.licenseDomain }}", "https://{{ .Values.license.licenseDomain }}"]
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-81- {{- end }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-82-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-83- {{- if .Values.env.pi_envs.plane_oauth.redirect_uri }}
--
charts/plane-enterprise/templates/config-secrets/app-env.yaml-80- {{- end }}
charts/plane-enterprise/templates/config-secrets/app-env.yaml-81-
charts/plane-enterprise/templates/config-secrets/app-env.yaml-82- {{- if eq .Values.env.cors_allowed_origins "*"}}
charts/plane-enterprise/templates/config-secrets/app-env.yaml:83: CORS_ALLOWED_ORIGINS: "*"
charts/plane-enterprise/templates/config-secrets/app-env.yaml-84- {{- else if .Values.env.cors_allowed_origins }}
charts/plane-enterprise/templates/config-secrets/app-env.yaml:85: CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }},{{ .Values.env.cors_allowed_origins }}"
charts/plane-enterprise/templates/config-secrets/app-env.yaml-86- {{- else}}
charts/plane-enterprise/templates/config-secrets/app-env.yaml:87: CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }}"
charts/plane-enterprise/templates/config-secrets/app-env.yaml-88- {{- end }}
charts/plane-enterprise/templates/config-secrets/app-env.yaml-89-
charts/plane-enterprise/templates/config-secrets/app-env.yaml-90- {{- if .Values.services.opensearch.local_setup }}
--
charts/plane-enterprise/templates/config-secrets/silo.yaml-70- SILO_BASE_PATH: "/silo"
charts/plane-enterprise/templates/config-secrets/silo.yaml-71-
charts/plane-enterprise/templates/config-secrets/silo.yaml-72- {{- if eq .Values.env.silo_envs.cors_allowed_origins "*"}}
charts/plane-enterprise/templates/config-secrets/silo.yaml:73: CORS_ALLOWED_ORIGINS: "*"
charts/plane-enterprise/templates/config-secrets/silo.yaml-74- {{- else if .Values.env.silo_envs.cors_allowed_origins }}
charts/plane-enterprise/templates/config-secrets/silo.yaml:75: CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }},{{ .Values.env.silo_envs.cors_allowed_origins }}"
charts/plane-enterprise/templates/config-secrets/silo.yaml-76- {{- else}}
charts/plane-enterprise/templates/config-secrets/silo.yaml:77: CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }}"
charts/plane-enterprise/templates/config-secrets/silo.yaml-78- {{- end }}
charts/plane-enterprise/templates/config-secrets/silo.yaml-79-
charts/plane-enterprise/templates/config-secrets/silo.yaml-80- APP_BASE_URL: "https://{{ .Values.license.licenseDomain }}"
--
charts/plane-ce/templates/config-secrets/app-env.yaml-56-
charts/plane-ce/templates/config-secrets/app-env.yaml-57-
charts/plane-ce/templates/config-secrets/app-env.yaml-58- {{- if eq .Values.env.cors_allowed_origins "*"}}
charts/plane-ce/templates/config-secrets/app-env.yaml:59: CORS_ALLOWED_ORIGINS: "*"
charts/plane-ce/templates/config-secrets/app-env.yaml-60- {{- else if and .Values.ingress.appHost .Values.env.cors_allowed_origins }}
charts/plane-ce/templates/config-secrets/app-env.yaml:61: CORS_ALLOWED_ORIGINS: "http://{{ .Values.ingress.appHost }},https://{{ .Values.ingress.appHost }},{{ .Values.env.cors_allowed_origins }}"
charts/plane-ce/templates/config-secrets/app-env.yaml-62- {{- else if .Values.env.cors_allowed_origins }}
charts/plane-ce/templates/config-secrets/app-env.yaml:63: CORS_ALLOWED_ORIGINS: "{{ .Values.env.cors_allowed_origins }}"
charts/plane-ce/templates/config-secrets/app-env.yaml-64- {{- else if .Values.ingress.appHost}}
charts/plane-ce/templates/config-secrets/app-env.yaml:65: CORS_ALLOWED_ORIGINS: "http://{{ .Values.ingress.appHost }},https://{{ .Values.ingress.appHost }}"
charts/plane-ce/templates/config-secrets/app-env.yaml-66- {{- else }}
charts/plane-ce/templates/config-secrets/app-env.yaml:67: CORS_ALLOWED_ORIGINS: ""
charts/plane-ce/templates/config-secrets/app-env.yaml-68- {{- end }}
</shell_result>
Script executed:
#!/bin/bash
# Search for pi-api or plane-api related directories
fd -t d -n 'pi*' | head -20Repository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stderr:
error: Found argument '-n' which wasn't expected, or isn't valid in this context
If you tried to supply '-n' as a value rather than a flag, use '-- -n'
Usage: fd [OPTIONS] [pattern] [path]...
For more information try '--help'
</shell_result>
Script executed:
#!/bin/bash
# Look for any Python or configuration files that might handle CORS_ALLOWED_ORIGINS
rg -n 'cors' -i --type py -C 2 | head -50Repository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stderr:
No files were searched, which means ripgrep probably applied a filter you didn't expect.
Running with --debug will show why files are being skipped.
</shell_result>
Script executed:
#!/bin/bash
# Search for environment variable parsing patterns
rg -n 'environ|getenv|os\.get' --type py -C 2 | head -50Repository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stderr:
No files were searched, which means ripgrep probably applied a filter you didn't expect.
Running with --debug will show why files are being skipped.
</shell_result>
Script executed:
#!/bin/bash
# Find values.yaml files to understand configuration
find . -name "values.yaml" -o -name "values*.yaml" | head -20Repository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stdout:
./charts/plane-ce/values.yaml
./charts/plane-enterprise/values.yaml
</shell_result>
Script executed:
#!/bin/bash
# Search for documentation about pi_envs
rg -n 'pi_envs' -C 3Repository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stdout:
charts/plane-enterprise/values.yaml-475- exchange_name: "plane.event_stream"
charts/plane-enterprise/values.yaml-476- event_types: "issue"
charts/plane-enterprise/values.yaml-477-
charts/plane-enterprise/values.yaml:478: pi_envs:
charts/plane-enterprise/values.yaml-479- plane_oauth:
charts/plane-enterprise/values.yaml-480- client_id: ''
charts/plane-enterprise/values.yaml-481- client_secret: ''
--
charts/plane-enterprise/questions.yml-788- label: "Assign Cluster IP"
charts/plane-enterprise/questions.yml-789- type: boolean
charts/plane-enterprise/questions.yml-790- default: false
charts/plane-enterprise/questions.yml:791: - variable: env.pi_envs.plane_oauth.client_id
charts/plane-enterprise/questions.yml-792- label: "Plane OAuth Client ID"
charts/plane-enterprise/questions.yml-793- type: string
charts/plane-enterprise/questions.yml-794- default: ""
charts/plane-enterprise/questions.yml:795: - variable: env.pi_envs.plane_oauth.client_secret
charts/plane-enterprise/questions.yml-796- label: "Plane OAuth Client Secret"
charts/plane-enterprise/questions.yml-797- type: password
charts/plane-enterprise/questions.yml-798- default: ""
charts/plane-enterprise/questions.yml:799: - variable: env.pi_envs.plane_oauth.redirect_uri
charts/plane-enterprise/questions.yml-800- label: "Plane OAuth Redirect URI"
charts/plane-enterprise/questions.yml-801- type: string
charts/plane-enterprise/questions.yml-802- default: ""
charts/plane-enterprise/questions.yml:803: - variable: env.pi_envs.plane_oauth.state_expiry_seconds
charts/plane-enterprise/questions.yml-804- label: "Plane OAuth State Expiry Seconds"
charts/plane-enterprise/questions.yml-805- type: int
charts/plane-enterprise/questions.yml-806- default: 82800
charts/plane-enterprise/questions.yml:807: - variable: env.pi_envs.plane_api_host
charts/plane-enterprise/questions.yml-808- label: "Plane API Host"
charts/plane-enterprise/questions.yml-809- type: string
charts/plane-enterprise/questions.yml-810- default: ""
charts/plane-enterprise/questions.yml:811: - variable: env.pi_envs.cors_allowed_origins
charts/plane-enterprise/questions.yml-812- label: "CORS Allowed Origins"
charts/plane-enterprise/questions.yml-813- type: string
charts/plane-enterprise/questions.yml-814- default: ""
charts/plane-enterprise/questions.yml:815: - variable: env.pi_envs.coherence_api_key
charts/plane-enterprise/questions.yml-816- label: "Coherence API Key"
charts/plane-enterprise/questions.yml-817- type: string
charts/plane-enterprise/questions.yml-818- default: ""
charts/plane-enterprise/questions.yml:819: - variable: env.pi_envs.celery.vector_sync_enabled
charts/plane-enterprise/questions.yml-820- label: "Vector Sync Enabled"
charts/plane-enterprise/questions.yml-821- type: boolean
charts/plane-enterprise/questions.yml-822- default: false
charts/plane-enterprise/questions.yml:823: - variable: env.pi_envs.celery.vector_sync_interval
charts/plane-enterprise/questions.yml-824- label: "Vector Sync Interval"
charts/plane-enterprise/questions.yml-825- type: int
charts/plane-enterprise/questions.yml-826- default: 3
charts/plane-enterprise/questions.yml:827: - variable: env.pi_envs.celery.workspace_plan_sync_enabled
charts/plane-enterprise/questions.yml-828- label: "Workspace Plan Sync Enabled"
charts/plane-enterprise/questions.yml-829- type: boolean
charts/plane-enterprise/questions.yml-830- default: false
charts/plane-enterprise/questions.yml:831: - variable: env.pi_envs.celery.workspace_plan_sync_interval
charts/plane-enterprise/questions.yml-832- label: "Workspace Plan Sync Interval"
charts/plane-enterprise/questions.yml-833- type: int
charts/plane-enterprise/questions.yml-834- default: 86400
charts/plane-enterprise/questions.yml:835: - variable: env.pi_envs.celery.docs_sync_enabled
charts/plane-enterprise/questions.yml-836- label: "Docs Sync Enabled"
charts/plane-enterprise/questions.yml-837- type: boolean
charts/plane-enterprise/questions.yml-838- default: false
charts/plane-enterprise/questions.yml:839: - variable: env.pi_envs.celery.docs_sync_interval
charts/plane-enterprise/questions.yml-840- label: "Docs Sync Interval"
charts/plane-enterprise/questions.yml-841- type: int
charts/plane-enterprise/questions.yml-842- default: 86400
--
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml-49- {{- end }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml-50- OPENSEARCH_ML_MODEL_ID: {{ .Values.env.opensearch_ml_model_id | default "" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml-51-
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml:52: CELERY_VECTOR_SYNC_ENABLED: {{ .Values.env.pi_envs.celery.vector_sync_enabled | ternary "1" "0" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml:53: CELERY_VECTOR_SYNC_INTERVAL: {{ .Values.env.pi_envs.celery.vector_sync_interval | default 3 | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml:54: CELERY_WORKSPACE_PLAN_SYNC_ENABLED: {{ .Values.env.pi_envs.celery.workspace_plan_sync_enabled | ternary "1" "0" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml:55: CELERY_WORKSPACE_PLAN_SYNC_INTERVAL: {{ .Values.env.pi_envs.celery.workspace_plan_sync_interval | default 86400 | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml:56: CELERY_DOCS_SYNC_ENABLED: {{ .Values.env.pi_envs.celery.docs_sync_enabled | ternary "1" "0" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml:57: CELERY_DOCS_SYNC_INTERVAL: {{ .Values.env.pi_envs.celery.docs_sync_interval | default 86400 | quote }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml-58-
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml-59- {{- if .Values.services.minio.local_setup }}
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml-60- AWS_ACCESS_KEY_ID: {{ .Values.services.minio.root_user | default "admin" | quote }}
--
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-7- namespace: {{ .Release.Namespace }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-8- name: {{ .Release.Name }}-pi-api-secrets
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-9-stringData:
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:10: PLANE_OAUTH_CLIENT_SECRET: {{ .Values.env.pi_envs.plane_oauth.client_secret | default "" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-11- {{- if .Values.services.pi.ai_providers.openai.enabled }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-12- OPENAI_API_KEY: {{ .Values.services.pi.ai_providers.openai.api_key | default "" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-13- {{- end }}
--
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-42- CELERY_BROKER_URL: ""
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-43- {{- end }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-44-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:45: {{- if .Values.env.pi_envs.coherence_api_key }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:46: COHERE_API_KEY: {{ .Values.env.pi_envs.coherence_api_key | default "" | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-47- {{- else }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-48- COHERE_API_KEY: ""
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-49- {{- end }}
--
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-63- PLANE_FRONTEND_URL: "http://{{ .Values.license.licenseDomain }}"
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-64- {{- end }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-65-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:66: {{- if .Values.env.pi_envs.plane_api_host }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:67: PLANE_API_HOST: {{ .Values.env.pi_envs.plane_api_host | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-68- {{- else }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-69- PLANE_API_HOST: "http://{{ .Release.Name }}-api.{{ .Release.Namespace }}.svc.cluster.local:8000"
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-70- {{- end }}
--
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-74- FEATURE_FLAG_SERVER_BASE_URL: "http://{{ .Release.Name }}-monitor.{{ .Release.Namespace }}.svc.cluster.local:8080"
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-75- PI_BASE_PATH: "/pi"
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-76-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:77: {{- if .Values.env.pi_envs.cors_allowed_origins }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:78: CORS_ALLOWED_ORIGINS: {{ .Values.env.pi_envs.cors_allowed_origins | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-79- {{- else }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-80- CORS_ALLOWED_ORIGINS: ["http://{{ .Values.license.licenseDomain }}", "https://{{ .Values.license.licenseDomain }}"]
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-81- {{- end }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-82-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:83: {{- if .Values.env.pi_envs.plane_oauth.redirect_uri }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:84: PLANE_OAUTH_REDIRECT_URI: {{ .Values.env.pi_envs.plane_oauth.redirect_uri | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-85- {{- else }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-86- PLANE_OAUTH_REDIRECT_URI: "http://{{ .Values.license.licenseDomain }}/pi/api/v1/oauth/callback/"
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-87- {{- end }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:88: PLANE_OAUTH_STATE_EXPIRY_SECONDS: {{ .Values.env.pi_envs.plane_oauth.state_expiry_seconds | default 82800 | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml:89: PLANE_OAUTH_CLIENT_ID: {{ .Values.env.pi_envs.plane_oauth.client_id | quote }}
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-90-
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-91----
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml-92-{{- end }}
</shell_result>
Script executed:
#!/bin/bash
# Check values.yaml for pi_envs configuration
sed -n '475,510p' charts/plane-enterprise/values.yamlRepository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stdout:
exchange_name: "plane.event_stream"
event_types: "issue"
pi_envs:
plane_oauth:
client_id: ''
client_secret: ''
redirect_uri: ''
state_expiry_seconds: 82800
plane_api_host: ''
cors_allowed_origins: ''
coherence_api_key: ''
celery:
vector_sync_enabled: false
vector_sync_interval: 3
workspace_plan_sync_enabled: false
workspace_plan_sync_interval: 86400
docs_sync_enabled: false
docs_sync_interval: 86400
# Global extra environment variables that will be applied to all workloads
extraEnv: []
# - name: HTTP_PROXY
# value: "http://proxy.example.com:8080"
# - name: HTTPS_PROXY
# value: "http://proxy.example.com:8080"
# - name: NO_PROXY
# value: "localhost,127.0.0.1,.example.com"
</shell_result>
Script executed:
#!/bin/bash
# Look for any comments or documentation about cors_allowed_origins
rg -n 'cors_allowed_origins' -B 2 -A 2 charts/plane-enterprise/values.yamlRepository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stdout:
431- sentry_environment: ''
432-
433: cors_allowed_origins: ''
434- instance_admin_email: ''
435-
--
449- hmac_secret_key: ''
450- aes_secret_key: 'dsOdt7YrvxsTIFJ37pOaEVvLxN8KGBCr'
451: cors_allowed_origins: ''
452-
453- email_service_envs:
--
483- state_expiry_seconds: 82800
484- plane_api_host: ''
485: cors_allowed_origins: ''
486- coherence_api_key: ''
487-
</shell_result>
Script executed:
#!/bin/bash
# Compare CORS handling across all services
echo "=== PI-API CORS handling ===" && \
sed -n '77,81p' charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml && \
echo -e "\n=== App/Silo CORS handling ===" && \
sed -n '72,78p' charts/plane-enterprise/templates/config-secrets/silo.yaml && \
echo -e "\n=== Default values ===" && \
grep -A 1 "cors_allowed_origins:" charts/plane-enterprise/values.yamlRepository: makeplane/helm-charts
<shell_result>
Repository: makeplane/helm-charts
Exit code: 0
stdout:
=== PI-API CORS handling ===
{{- if .Values.env.pi_envs.cors_allowed_origins }}
CORS_ALLOWED_ORIGINS: {{ .Values.env.pi_envs.cors_allowed_origins | quote }}
{{- else }}
CORS_ALLOWED_ORIGINS: ["http://{{ .Values.license.licenseDomain }}", "https://{{ .Values.license.licenseDomain }}"]
{{- end }}
=== App/Silo CORS handling ===
{{- if eq .Values.env.silo_envs.cors_allowed_origins "*"}}
CORS_ALLOWED_ORIGINS: "*"
{{- else if .Values.env.silo_envs.cors_allowed_origins }}
CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }},{{ .Values.env.silo_envs.cors_allowed_origins }}"
{{- else}}
CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }}"
{{- end }}
=== Default values ===
cors_allowed_origins: ''
instance_admin_email: ''
--
cors_allowed_origins: ''
--
cors_allowed_origins: ''
coherence_api_key: ''
</shell_result>
Consolidate CORS_ALLOWED_ORIGINS format to comma-separated string consistent with other services (app, silo).
The pi-api template produces different formats depending on whether a user value is provided:
- User-provided value (line 78):
"http://a,https://b"(string, via| quote) - Default (line 80):
["http://domain", "https://domain"](JSON array, literal)
This diverges from all other services (app-env.yaml, silo.yaml), which consistently output comma-separated strings. The inconsistency creates parsing ambiguity—the PI API cannot reliably handle both string and array formats.
Recommended fix: Align pi-api to use the same comma-separated string pattern as other services:
{{- if eq .Values.env.pi_envs.cors_allowed_origins "*" }}
CORS_ALLOWED_ORIGINS: "*"
{{- else if .Values.env.pi_envs.cors_allowed_origins }}
CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }},{{ .Values.env.pi_envs.cors_allowed_origins }}"
{{- else }}
CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }}"
{{- end }}🤖 Prompt for AI Agents
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml around lines
77-81: the template currently emits user-provided CORS_ALLOWED_ORIGINS as a
quoted string but the default as a JSON array, causing inconsistent formats;
change the conditionals so CORS_ALLOWED_ORIGINS is always a comma-separated
string (handle the special case where the value is exactly "*" to emit "*", if a
user-provided value exists append it to the default
http://<licenseDomain>,https://<licenseDomain> pair separated by commas,
otherwise emit only the two default domains), and ensure the final value is
wrapped in quotes to match other services.
charts/plane-enterprise/templates/config-secrets/postgres-init.yaml
Outdated
Show resolved
Hide resolved
| GRANT ALL PRIVILEGES ON DATABASE plane_pi TO {{ .Values.env.pgdb_username | default "plane" }}; | ||
| --- | ||
| {{- end }} | ||
|
|
There was a problem hiding this comment.
Remove extra blank lines at end of file.
YAMLlint flags excessive blank lines (more than 0 allowed at EOF).
---
{{- end }}
-Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 YAMLlint (1.37.1)
[warning] 16-16: too many blank lines (1 > 0)
(empty-lines)
🤖 Prompt for AI Agents
In charts/plane-enterprise/templates/config-secrets/postgres-init.yaml around
line 16, the file contains extra blank lines at the end which YAMLlint flags;
remove any trailing blank lines so the file ends immediately after the last YAML
content line (no blank lines or whitespace at EOF) and save the file.
charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml
Outdated
Show resolved
Hide resolved
| annotations: | ||
| timestamp: {{ now | quote }} | ||
| spec: | ||
| {{ include "plane.podScheduling" .Values.services.pi_worker }} |
There was a problem hiding this comment.
Add leading dash to Helm include to strip whitespace.
The include statement is missing the leading dash, which preserves whitespace and causes YAML indentation issues. Other templates in this PR correctly use {{- include ....
- {{ include "plane.podScheduling" .Values.services.pi_worker }}
+ {{- include "plane.podScheduling" .Values.services.pi_worker }}📝 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.
| {{ include "plane.podScheduling" .Values.services.pi_worker }} | |
| {{- include "plane.podScheduling" .Values.services.pi_worker }} |
🤖 Prompt for AI Agents
In charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml around
line 21 the Helm include lacks the leading dash which allows unwanted whitespace
into the rendered YAML; update the include invocation to add a leading dash so
whitespace is stripped (i.e. change the include to use a leading dash before the
first curly brace) ensuring proper YAML indentation and consistency with other
templates.
|
|
||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
Remove excessive blank lines at end of file.
YAMLlint flags 4 blank lines when only 0 are allowed at EOF.
serviceAccount: {{ .Release.Name }}-srv-account
serviceAccountName: {{ .Release.Name }}-srv-account
---
{{- end }}
-
-
-
-📝 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.
| serviceAccount: {{ .Release.Name }}-srv-account | |
| serviceAccountName: {{ .Release.Name }}-srv-account | |
| --- | |
| {{- end }} |
🧰 Tools
🪛 YAMLlint (1.37.1)
[warning] 61-61: too many blank lines (4 > 0)
(empty-lines)
🤖 Prompt for AI Agents
In charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml around
line 61, there are four excessive blank lines at the end of the file; remove all
trailing empty lines so the file ends immediately after the last YAML line (no
extra blank lines at EOF) to satisfy YAMLlint.
- Renamed 'coherence_api_key' to 'cohere_api_key' for consistency in questions.yml and values.yaml. - Introduced a new configuration option for 'PI Internal Secret' in questions.yml and values.yaml. - Updated app-env.yaml and pi-api-env.yaml to include the new 'PI Internal Secret' in the generated secrets.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml (1)
77-81: CORS_ALLOWED_ORIGINS format is inconsistent across user and default values.Lines 77–81 create a format mismatch:
- When user provides
env.pi_envs.cors_allowed_origins(line 78): outputs"value"(quoted string)- When using default (line 80): outputs
["http://domain", "https://domain"](JSON array, unquoted)This divergence violates consistency with app-env.yaml and silo.yaml, which both use comma-separated strings. The PI API cannot reliably parse both formats.
Recommended fix: Align pi-api to use comma-separated string format throughout:
{{- if eq .Values.env.pi_envs.cors_allowed_origins "*" }} CORS_ALLOWED_ORIGINS: "*" {{- else if .Values.env.pi_envs.cors_allowed_origins }} CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }},{{ .Values.env.pi_envs.cors_allowed_origins }}" {{- else }} CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }}" {{- end }}charts/plane-enterprise/questions.yml (1)
1107-1111: OpenSearch password hardcoded with weak guidance in questions UI.Lines 1107–1111 expose the hardcoded OpenSearch password default
"Secure@Pass#123!%^&*"in the Rancher/questions UI. This should not appear as a preset value; it risks deployments using identical credentials across instances.Recommended actions:
- Change default to empty string (users must set their own)
- Add a required flag and clear guidance: "Must be a strong password. Use a password generator if needed."
- Document in README that local_setup credentials must be changed before production
- variable: services.opensearch.password label: "Password" type: password default: "" required: true show_if: "services.opensearch.local_setup=true" description: "Must be a strong password; leave empty to auto-generate"charts/plane-enterprise/values.yaml (1)
83-96: OpenSearch service definition has hardcoded credentials unsuitable for production.Lines 83–96 introduce the OpenSearch service block with:
- Line 90: Hardcoded password
"Secure@Pass#123!%^&*"- This is exposed in version control and creates a security risk if deployed without override
For local development this is acceptable, but production deployments must enforce credential override. The global
secret_key(line 427) follows the same pattern and has the same concern.Recommended approach:
- Document prominently in README or values.yaml comments that these are local-development-only defaults.
- Consider marking defaults as
CHANGE_MEor providing a pre-commit hook to catch uncommitted secrets.- For production-ready deployments, use
external_secrets.opensearch_existingSecretto source credentials from a pre-created Secret.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
charts/plane-enterprise/questions.yml(5 hunks)charts/plane-enterprise/templates/config-secrets/app-env.yaml(3 hunks)charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml(1 hunks)charts/plane-enterprise/values.yaml(5 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (12)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (3)
12-12: Document PI_INTERNAL_SECRET as requiring override for production.Line 12 adds a hardcoded default PI_INTERNAL_SECRET to the Secret. While consistent with the existing
secret_keypattern, this should be documented in the chart's README or values comments to clarify that users must override this in production environments.Verify that the PI service expects this secret and will fail safely if not provided, and confirm this pattern aligns with team security standards for secret management in Helm charts.
40-46: OpenSearch password handling logic is sound.Lines 40-46 correctly implement three-branch logic:
- Local setup: uses configured password with default fallback
- Remote setup: uses configured password with empty fallback
- Disabled: empty password
This aligns with the pattern used for Redis and Postgres.
91-106: OpenSearch configuration correctly wired.Lines 91-106 properly gate OpenSearch environment variables based on setup mode, with appropriate defaults and fallbacks. ConfigMap values are consistent with Secret definitions above.
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml (1)
1-1: Wrap conditional guard with proper YAML comment syntax.Line 1 uses a Helm conditional
{{- if ... }}at the start of the file. While syntactically valid in Helm, YAMLlint reports a syntax error. This is likely a false positive (YAMLlint doesn't parse Helm templating), but ensure your Helm validation passes.Confirm that
helm lintand your CI pipeline validation passes for this template without errors or warnings.charts/plane-enterprise/questions.yml (4)
747-907: PI service configuration structure is comprehensive and consistent.Lines 747–907 add well-organized PI service questions with:
- Deployment resource controls (replicas, memory, CPU)
- OAuth and Celery configuration
- Six AI provider integrations (OpenAI, Claude, Mistral, Groq, AssemblyAI, Deepgram) with optional API keys
- Proper conditional visibility (show_subquestion_if)
The structure mirrors existing services and should integrate cleanly with the Helm templates.
1050-1069: PI Postgres database configuration properly scoped.Lines 1050–1069 add PI-specific database configuration with:
env.pg_pi_db_name: shown only when local Postgres is enabledenv.pg_pi_db_remote_url: shown only when local Postgres is disabledThis correctly allows users to specify separate database(s) for PI workload.
1071-1130: OpenSearch setup section properly gate-conditioned but with password security concern.Lines 1071–1130 add OpenSearch configuration with proper conditional visibility and local/remote setup branching. However, the hardcoded password default on line 1110 is the main issue (see separate comment).
Confirm that the OpenSearch service block in values.yaml (opensearch.local_setup and credentials) and the questions.yml setup here are coordinated, and verify that no other templates inadvertently expose these defaults.
1340-1393: External secrets configuration properly extends for PI and OpenSearch.Lines 1340–1393 add three new external_secrets options:
external_secrets.opensearch_existingSecretexternal_secrets.pi_api_env_existingSecretexternal_secrets.pi_common_env_existingSecretThis allows users to supply pre-created Kubernetes Secrets, which is a good practice for production. Structure is consistent with existing patterns.
charts/plane-enterprise/values.yaml (4)
322-382: PI service configuration structure is well-organized and complete.Lines 322–382 add three PI service blocks:
- PI API service (322–356): Main deployment with 6 AI providers (OpenAI, Claude, Mistral, Groq, AssemblyAI, Deepgram), each with enable flag and api_key field
- PI Beat Worker (357–368): Celery beat worker for scheduled tasks
- PI Worker (370–381): Background worker for async tasks
All three follow the established pattern with resource limits/requests, Kubernetes scheduling (nodeSelector, tolerations, affinity), and metadata (labels, annotations). AI provider nesting is clean and supports future provider additions.
405-407: PI database configuration supports both local and remote setups.Lines 405–407 add:
pg_pi_db_name: "plane_pi"– Local database name, clearly separated from main app DBpg_pi_db_remote_url: ""– Remote URL option for external PostgresThis design allows flexibility and prevents naming conflicts between the main Plane app and PI workloads.
421-424: OpenSearch environment configuration properly exposed.Lines 421–424 add OpenSearch environment variables:
opensearch_url: ""– Remote URL overrideopensearch_index_prefix: 'plane_'– Index naming strategyopensearch_ml_model_id: ""– Optional ML model ID for AI featuresThese align with the OpenSearch service block and are used by pi-api-env.yaml and pi-common-env.yaml templates.
478-495: PI environment variables block is comprehensive and supports Celery task configuration.Lines 478–495 add
env.pi_envswith:
- OAuth configuration (client_id, client_secret, redirect_uri, state_expiry_seconds)
plane_api_hostfor inter-service communicationcors_allowed_origins(subject to format consistency concern in pi-api-env.yaml)cohere_api_keyfor AI modelsinternal_secret(hardcoded, consistent with app secret_key pattern)- Celery task configuration (vector_sync, workspace_plan_sync, docs_sync with enable flags and intervals)
This structure properly separates PI-specific configuration from the main app config.
Verify that the
cohere_api_keyvscoherence_api_keynaming is consistent across templates (pi-api-env.yaml referencescohere_api_keyon line 45, which matches the values.yaml key on line 486).
| - variable: env.pi_envs.internal_secret | ||
| label: "PI Internal Secret" | ||
| type: string | ||
| default: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" |
There was a problem hiding this comment.
PI_INTERNAL_SECRET hardcoded default should be documented as local-setup-only.
Line 903-906 adds a hardcoded PI_INTERNAL_SECRET default visible in version control. While this mirrors the pattern used for other secrets in the chart, users must understand that this is only suitable for local development and must be overridden for production.
Consider:
- Adding a prominent comment in the default value:
"tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk # CHANGE FOR PRODUCTION" - Documenting in the chart README that all defaults marked as local-setup must be overridden before production deployment
- Adding validation or warnings for secrets that have not been changed from defaults
🤖 Prompt for AI Agents
In charts/plane-enterprise/questions.yml around lines 903 to 906, the
PI_INTERNAL_SECRET default is hardcoded and checked into VCS; update the chart
to mark this default explicitly as local-only and require override: change the
default string to include a clear inline note such as
"tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk # LOCAL-ONLY: CHANGE FOR PRODUCTION", add an
entry in the chart README listing all "local-setup" defaults that must be
overridden before production, and implement a validation/warning (values schema
or helm hook) that emits a clear error or warning when the secret equals the
default to prevent accidental production use.
- Changed the default value of OPENSEARCH_INDEX_PREFIX from 'plane_' to an empty string in values.yaml. - Updated app-env.yaml and pi-common-env.yaml to reflect the new default value for OPENSEARCH_INDEX_PREFIX, ensuring consistency across environment configurations.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (7)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (2)
12-12: PI_INTERNAL_SECRET should use placeholder or generated defaults for production.Following the same pattern as other hardcoded secrets in this template, this value is version-controlled and should not be a usable default in production.
Consider updating to a placeholder and documenting that production deployments must override this value via external secrets or values override.
40-46: Hardcoded OpenSearch default password presents security risk.The default password
Secure@Pass#123!%^&*is version-controlled and visible in templates. While suitable for local development, this presents a security risk if not explicitly overridden in production.This mirrors concerns flagged in prior reviews. Consider requiring explicit password configuration via external secrets for production deployments.
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml (1)
22-28: Hardcoded OpenSearch and AWS credentials present security risks.Lines 23 and 25 use the same hardcoded OpenSearch password (
Secure@Pass#123!%^&*) flagged in prior reviews. While line 18 correctly delegates AWS credentials to MinIO or env, OpenSearch defaults should be handled similarly.Recommend requiring explicit credentials via external secrets or documenting mandatory overrides for production.
charts/plane-enterprise/values.yaml (2)
83-96: Hardcoded OpenSearch credentials in values pose security risk.The opensearch service block includes a hardcoded default password (
Secure@Pass#123!%^&*) and username. While appropriate for local development (local_setup: true), these are version-controlled and create risk if defaults are not overridden in production.Consider:
- Documenting that production deployments must override these credentials.
- Using a placeholder like
CHANGE_MEto signal mandatory configuration.- Leveraging external secrets (via
external_secrets.opensearch_existingSecret) for production.
478-496: PI_INTERNAL_SECRET hardcoded default requires production override documentation.Line 487 contains a hardcoded PI_INTERNAL_SECRET (
tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk), flagged by Gitleaks as a generic API key. While this mirrors the pattern for other secrets in the chart (e.g., line 427 secret_key), it should not be deployed to production without explicit override.Additionally, line 486 (
cohere_api_key) should also be treated as sensitive and documented as requiring override for any deployment.Consider:
- Adding comments marking these defaults as LOCAL-ONLY or CHANGE FOR PRODUCTION.
- Documenting in the chart README that all hard-coded secret defaults must be overridden before production deployment.
- Implementing validation (e.g., Helm hook or chart README) to prevent accidental production use of defaults.
charts/plane-enterprise/questions.yml (2)
903-906: PI_INTERNAL_SECRET hardcoded default must be flagged as local-only.This hardcoded default (
tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk) should not be deployed to production without explicit override.Referring to past review feedback: the default should be documented with a clear marker indicating it's for local development only.
1071-1129: Hardcoded OpenSearch password in UI requires production override guidance.Line 1110 sets
default: "Secure@Pass#123!%^&*"for the OpenSearch password field. This exposes a hardcoded credential in version control and requires explicit override for production.Past review feedback indicated this should be addressed. Consider:
- Changing default to
""(empty) to signal mandatory user input.- Adding a description indicating this must be a strong password for production.
- Documenting in chart README that this default is unsuitable for production use.
🧹 Nitpick comments (1)
charts/plane-enterprise/questions.yml (1)
815-818: Consider marking Cohere API key as password type.Line 815-818 defines
cohere_api_keywithtype: string. For consistency with other API key configurations (e.g., AI provider keys at lines 850, 860, etc.), this should usetype: passwordto mask input in the UI.- variable: env.pi_envs.cohere_api_key label: "Cohere API Key" - type: string + type: password default: ""
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
charts/plane-enterprise/questions.yml(5 hunks)charts/plane-enterprise/templates/config-secrets/app-env.yaml(3 hunks)charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml(1 hunks)charts/plane-enterprise/values.yaml(5 hunks)
🧰 Additional context used
🪛 Gitleaks (8.29.1)
charts/plane-enterprise/values.yaml
[high] 487-487: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (9)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (1)
91-106: Approve OpenSearch ConfigMap conditional logic.The three-way conditional branching is sound and correctly sets OPENSEARCH_ENABLED based on deployment context (local vs remote setup).
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml (2)
1-1:⚠️ YAMLlint reports syntax error on line 1.The YAMLlint hint reports: "syntax error: expected the node content, but found '-'". This is likely a false positive since the file starts with valid Helm template syntax (
{{- if ...). However, verify that your linting configuration accounts for Helm templates (YAMLlint may need--no-warningsor template-aware configuration).If this is a persistent issue, consider adding a YAML linting exception or wrapping the template check in a comment.
37-71: Approve PI ConfigMap structure and Celery configuration.The conditional OpenSearch URL/user configuration and Celery settings are well-structured. The ternary conversion of boolean flags to "1"/"0" strings for DEBUG (line 71) is correct for environment variable handling.
charts/plane-enterprise/values.yaml (2)
322-356: Approve PI service block structure and AI provider defaults.The pi service configuration follows the established pattern (replicas, resources, image, scheduling). The ai_providers are correctly defaulted to disabled (
enabled: false) with empty API keys, ensuring secure-by-default posture.
387-387: Approve external secrets entries for PI and OpenSearch.The new external secrets (opensearch_existingSecret, pi_api_env_existingSecret, pi_common_env_existingSecret) default to empty strings, correctly allowing users to override via Kubernetes external secret resources for production.
Also applies to: 392-393
charts/plane-enterprise/questions.yml (4)
747-907: Approve comprehensive PI service configuration questions.The PI service block is well-structured with proper nesting of image, resource limits, OAuth settings, and AI provider configuration. The use of
show_subquestion_if: trueand conditional visibility is consistent with existing patterns. All AI providers default to disabled (enabled: false) with empty keys, maintaining secure-by-default posture.
908-962: Approve PI Worker and Beat Worker configuration questions.Both PI worker variants are properly structured with resource and replica configuration following established patterns.
1050-1069: Approve conditional PostgreSQL PI database questions.The pg_pi_db_name and pg_pi_db_remote_url are correctly conditioned on
services.postgres.local_setupvalue, maintaining consistency with the existing Postgres setup pattern.
1340-1373: Approve external secrets entries for PI and OpenSearch.The new external secrets entries (opensearch_existingSecret, pi_api_env_existingSecret, pi_common_env_existingSecret) default to empty strings, correctly allowing users to optionally provide Kubernetes external secret resources without forcing dependency on external-secrets operator.
charts/plane-enterprise/templates/config-secrets/postgres-init.yaml
Outdated
Show resolved
Hide resolved
| FEATURE_FLAG_SERVER_BASE_URL: "http://{{ .Release.Name }}-monitor.{{ .Release.Namespace }}.svc.cluster.local:8080" | ||
| PI_BASE_PATH: "/pi" | ||
|
|
||
| {{- if .Values.env.pi_envs.cors_allowed_origins }} |
There was a problem hiding this comment.
CORS can be set by ingress domain
| init-dbs.sql: | | ||
| CREATE EXTENSION IF NOT EXISTS dblink; | ||
| SELECT 'CREATE DATABASE {{.Values.env.pgdb_name}}' |
There was a problem hiding this comment.
fix this - add double quote (") before and after db name {{.Values.env.pgdb_name}}
…n Helm chart - Updated OpenSearch Docker image version from 3 to 3.3.2 in questions.yml and values.yaml. - Renamed 'opensearch_url' to 'opensearch_remote_url' and added new fields for 'opensearch_remote_username' and 'opensearch_remote_password' in questions.yml and values.yaml to improve remote setup support. - Adjusted app-env.yaml and pi-common-env.yaml to use the new remote URL and credentials for OpenSearch. - Modified PostgreSQL initialization SQL to ensure database names are quoted correctly for compatibility. - Removed obsolete postgres-init.yaml template to streamline configuration.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml (1)
16-19: 🔴 CRITICAL: podScheduling include is in invalid YAML position.The
{{- include "plane.podScheduling"}}directive (line 18) is positioned after thecontainers:key, which creates invalid YAML structure. The include must appear beforecontainers:at the pod spec level, as a sibling to other pod-spec keys likeserviceAccountandrestartPolicy.This mirrors the structure already correctly implemented in
pi-api.deployment.yaml(line 44) and was flagged in prior reviews.Apply this diff:
spec: + {{- include "plane.podScheduling" .Values.services.pi }} containers: - {{- include "plane.podScheduling" .Values.services.pi }} - name: {{ .Release.Name }}-pi-api-migratecharts/plane-enterprise/questions.yml (1)
903-906: Based on my verification, I can confirm the security concern is legitimate. The hardcodedPI_INTERNAL_SECRETvalue appears in multiple critical locations (questions.yml, values.yaml, and two template files) with no documentation warning against production use. Additionally, I found that other secrets in app-env.yaml also have hardcoded defaults, but there's no documentation addressing this pattern. The inconsistency is notable: the Deepgram API Key usestype: passwordwith an empty default, while PI usestype: stringwith a hardcoded value.Hardcoded PI_INTERNAL_SECRET default poses a security risk and should be changed to empty with documentation.
The hardcoded default
tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubkappears in 4 files (questions.yml, values.yaml, pi-api-env.yaml, app-env.yaml) with no documentation indicating this is local-setup-only. Users deploying via the quick setup without customizing values will use this known secret in production. Additionally, the field type in questions.yml isstringrather thanpassword, which could display it in plain text in the UI.Recommend:
- default: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" + default: "" + description: "Generate a strong secret key for production deployment"This should also be applied to other hardcoded secrets in values.yaml and app-env.yaml.
charts/plane-enterprise/values.yaml (1)
83-96:⚠️ Hardcoded credentials lack production override guidance in values.yaml.The OpenSearch service block (line 90) and other local services contain hardcoded default credentials (
password: Secure@Pass#123!%^&*, line 488internal_secret: tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk) intended forlocal_setup: truedeployments. While anexternal_secretssection exists in the values file (lines 383-393) to support production secret management via AWS Secrets Manager or Vault, there are no comments or warnings in values.yaml itself linking the hardcoded defaults to the external-secrets override pattern.This creates a documentation gap: users may not realize these defaults must be overridden for production, and the connection between
local_setup, hardcoded values, andexternal_secretsis unclear.Recommendation: Add a comment block at the top of the OpenSearch service definition and
pi_envssection clarifying the local/production pattern:opensearch: + # ⚠️ local_setup: true uses hardcoded defaults for development only. + # For production, either: + # 1. Override password via: helm install ... --set services.opensearch.password="<secure-value>" + # 2. Use external-secrets (AWS/Vault): set opensearch_existingSecret in external_secrets section local_setup: true image: opensearchproject/opensearch:3.3.2 servicePort: 9200 volumeSize: 5Gi pullPolicy: IfNotPresent username: plane password: Secure@Pass#123!%^&*Also add a note in the
pi_envssection referencingexternal_secretsforinternal_secretand other sensitive values.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
charts/plane-enterprise/questions.yml(5 hunks)charts/plane-enterprise/templates/config-secrets/app-env.yaml(3 hunks)charts/plane-enterprise/templates/config-secrets/pgdb.yaml(2 hunks)charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-api.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml(1 hunks)charts/plane-enterprise/values.yaml(5 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-16T15:18:06.210Z
Learnt from: twtaylor
Repo: makeplane/helm-charts PR: 134
File: charts/plane-ce/templates/workloads/beat-worker.deployment.yaml:26-33
Timestamp: 2025-10-16T15:18:06.210Z
Learning: In the makeplane/helm-charts repository, prefer explicit indentation within conditional blocks in Helm templates over using nindent functions, as it improves readability and maintainability even if yamllint flags indentation warnings.
Applied to files:
charts/plane-enterprise/templates/workloads/pi-api.deployment.yamlcharts/plane-enterprise/templates/workloads/pi-migrator.job.yaml
🪛 Gitleaks (8.29.1)
charts/plane-enterprise/values.yaml
[high] 488-488: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-api.deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/config-secrets/pgdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (7)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (2)
12-12: ✓ PI_INTERNAL_SECRET correctly configured.The PI internal secret default value is appropriately set with proper quoting.
40-106: ✓ OpenSearch configuration properly handles local and remote setups.The three-way conditional logic (local OpenSearch, remote URL, or disabled) is consistently applied to both the Secret and ConfigMap, with correct password/credential sourcing and fallback to empty values. Naming corrections (opensearch_remote_password, opensearch_remote_username) from past feedback are properly implemented.
charts/plane-enterprise/templates/workloads/pi-api.deployment.yaml (1)
44-74: ✓ Correct YAML structure and environment configuration.The
{{- include "plane.podScheduling"}}is correctly positioned beforecontainers:at the pod spec level. Container environment sources (pi-api-vars ConfigMap, pi-api-secrets Secret, pi-common-vars ConfigMap, pi-common-secrets Secret) are properly configured with optional external secrets support. The readinessProbe thresholds are reasonable for service startup tolerance.charts/plane-enterprise/templates/config-secrets/pgdb.yaml (1)
27-35: ✓ SQL identifier quoting properly applied.Database names are now correctly wrapped in double quotes within SQL statements, preventing syntax errors from special characters in database names. The init-dbs.sql script properly creates both the main
planedatabase and the newplane_pidatabase with appropriate EXISTS checks. This aligns with the prior review feedback on SQL best practices.charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml (1)
21-53: ✓ Correct pod scheduling position and environment configuration.The
{{- include "plane.podScheduling"}}is correctly positioned beforecontainers:. Environment configuration consistently sources from the same ConfigMaps and Secrets as the pi-api deployment, ensuring synchronized configuration across PI workloads. Resource requests/limits come from dedicatedpi_beat_workervalues, maintaining proper separation from the pi-api component.charts/plane-enterprise/templates/config-secrets/pi-common-env.yaml (1)
10-70: ✓ Shared PI environment configuration properly structured.Secret and ConfigMap follow the established three-way conditional pattern for credentials (local setup, remote URL/value, or empty), consistent with app-env.yaml patterns. PostgreSQL follower URI, OpenSearch password, and AWS credentials all properly support both local and remote deployments. Celery synchronization intervals have sensible defaults, and all environment variables are appropriately sourced.
charts/plane-enterprise/questions.yml (1)
1071-1139: ✓ OpenSearch and PI worker question structure is sound.The OpenSearch setup questions (local_setup with conditional subquestions for local vs. remote) and PI worker/beat-worker configurations follow established patterns. Conditional visibility using
show_ifcorrectly isolates local and remote configuration options. Despite the hardcoded password default noted separately, the question structure and conditional logic are properly implemented.
- Added new configuration options for PI Docker Image in questions.yml. - Replaced boolean 'enabled' flags for PI and PI Beat Workers with resource specifications (replicas, memory limits, and CPU limits) in values.yaml. - Updated deployment templates for PI and PI Worker to reflect the new configuration structure.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (7)
charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml (2)
21-21: Add leading dash to Helm include to strip whitespace.The
includestatement is missing the leading dash ({{-vs{{), which preserves whitespace and causes YAML indentation issues. This pattern should be consistent with pi-beat.deployment.yaml (line 21) and other templates.- {{ include "plane.podScheduling" .Values.services.pi_worker }} + {{- include "plane.podScheduling" .Values.services.pi_worker }}
58-61: Remove excessive blank lines at end of file.Lines 58-61 contain 4 trailing blank lines; YAMLlint allows 0 blank lines at EOF.
serviceAccount: {{ .Release.Name }}-srv-account serviceAccountName: {{ .Release.Name }}-srv-account --- {{- end }} - - - -charts/plane-enterprise/questions.yml (2)
908-911: Remove hardcoded PI internal secret default from questions.The PI Internal Secret question exposes a hardcoded default (
tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk) in the deployment UI. This mirrors the critical security issue in values.yaml and must be changed to require explicit user input.Replace the hardcoded default with an empty string and mark as required:
- variable: env.pi_envs.internal_secret label: "PI Internal Secret" type: string - default: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" + default: "" + required: true + description: "REQUIRED for production. Generate a strong random secret and override this value."
1110-1114: Remove hardcoded OpenSearch password default from questions.The OpenSearch password question exposes a hardcoded default (
Secure@Pass#123!%^&*) whenservices.opensearch.local_setup=true. This must be changed to enforce explicit configuration.Replace the hardcoded default with an empty string and add guidance:
- variable: services.opensearch.password label: "Password" type: password - default: "Secure@Pass#123!%^&*" + default: "" + required: true show_if: "services.opensearch.local_setup=true" + description: "REQUIRED for local setup. Use a strong, unique password for production."charts/plane-enterprise/values.yaml (2)
83-96:⚠️ Hardcoded OpenSearch password in defaults poses security risk.The OpenSearch service configuration includes a hardcoded default password (
Secure@Pass#123!%^&*) that is version-controlled and visible to all repository users. While marked aslocal_setup, this value will be deployed unless explicitly overridden, risking exposure in production environments.Replace the hardcoded default with an empty string to force users to supply explicit values:
opensearch: local_setup: true image: opensearchproject/opensearch:3.3.2 servicePort: 9200 volumeSize: 5Gi pullPolicy: IfNotPresent username: plane - password: Secure@Pass#123!%^&* + password: "" assign_cluster_ip: falseAdd a note to the chart README documenting that all default credentials must be overridden in production deployments.
477-497: Remove hardcoded PI internal secret and address systemic hardcoded secret issue.Line 486 contains a hardcoded internal secret
tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubkthat must not be deployed without explicit override. However, verification reveals this is part of a larger security issue: five hardcoded secrets exist throughout the values file and are replicated in template defaults:
- Line 90:
password: Secure@Pass#123!%^&*(opensearch)- Line 426:
secret_key: "60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5"- Line 438:
live_server_secret_key: "htbqvBJAgpm9bzvf3r4urJer0ENReatceh"- Line 449:
aes_secret_key: 'dsOdt7YrvxsTIFJ37pOaEVvLxN8KGBCr'- Line 486:
internal_secret: 'tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk'These also appear as fallback defaults in template files (
charts/plane-enterprise/templates/config-secrets/), creating production deployment vulnerabilities if not explicitly overridden.Replace the hardcoded default with an empty string:
pi_envs: plane_oauth: client_id: '' client_secret: '' redirect_uri: '' state_expiry_seconds: 82800 plane_api_host: '' cors_allowed_origins: '' cohere_api_key: '' - internal_secret: 'tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk' + internal_secret: '' opensearch_ml_model_id: ''charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml (1)
44-46: Remove trailing blank lines at end of file.Lines 44-46 contain unnecessary trailing blank lines before the closing conditional. YAMLlint allows 0 blank lines at EOF.
restartPolicy: OnFailure serviceAccount: {{ .Release.Name }}-srv-account serviceAccountName: {{ .Release.Name }}-srv-account --- {{- end }} - -
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
charts/plane-enterprise/questions.yml(6 hunks)charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml(1 hunks)charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml(1 hunks)charts/plane-enterprise/values.yaml(5 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-16T15:18:06.210Z
Learnt from: twtaylor
Repo: makeplane/helm-charts PR: 134
File: charts/plane-ce/templates/workloads/beat-worker.deployment.yaml:26-33
Timestamp: 2025-10-16T15:18:06.210Z
Learning: In the makeplane/helm-charts repository, prefer explicit indentation within conditional blocks in Helm templates over using nindent functions, as it improves readability and maintainability even if yamllint flags indentation warnings.
Applied to files:
charts/plane-enterprise/templates/workloads/pi-migrator.job.yamlcharts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml
🪛 Gitleaks (8.29.1)
charts/plane-enterprise/values.yaml
[high] 486-486: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-migrator.job.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml
[warning] 61-61: too many blank lines (4 > 0)
(empty-lines)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (4)
charts/plane-enterprise/templates/workloads/pi-beat.deployment.yaml (1)
1-57: LGTM!The pi-beat deployment template is well-structured with proper Helm conditional gating, correct pod scheduling include positioning, and consistent environment configuration sourcing from configMaps and secrets aligned with the PI integration pattern.
charts/plane-enterprise/questions.yml (3)
752-912: Comprehensive PI setup configuration is well-structured.The PI setup section properly organizes all PI-related questions including OAuth configuration, AI provider settings, Celery scheduling, and internal secrets. The subquestion structure and conditional rendering (show_subquestion_if, show_if) align with existing chart patterns. Ensure that hardcoded defaults (lines 908-911) are addressed as flagged in the security review.
1074-1143: OpenSearch setup questions are comprehensive with proper conditional visibility.The OpenSearch configuration section properly handles both local and remote setup scenarios with appropriate conditional rendering (show_if). Remote configuration questions (lines 1120-1143) allow users to integrate external OpenSearch instances. Ensure hardcoded password defaults (line 1113) are addressed in the security fix.
1353-1387: PI and OpenSearch external secrets integration is properly exposed.Lines 1353-1387 properly surface external secret options for PI API environments, PI common environments, and OpenSearch. This allows users to override locally-managed secrets with pre-provisioned Kubernetes secrets, supporting secure production deployments.
| opensearch_index_prefix: '' | ||
|
|
||
| #API KEYS | ||
| secret_key: "60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5" |
There was a problem hiding this comment.
Multiple hardcoded secrets in chart defaults expose deployments to security risk.
Lines 426, 438, and 449 contain hardcoded secrets checked into version control:
secret_key:60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5(line 426)live_server_secret_key:htbqvBJAgpm9bzvf3r4urJer0ENReatceh(line 438)aes_secret_key:dsOdt7YrvxsTIFJ37pOaEVvLxN8KGBCr(line 449)
These are used as fallback defaults in Helm templates via | default "..." filters, ensuring they are deployed even if unset in values.yaml. The README acknowledges that SECRET_KEY "must be random" yet these public defaults remain available.
Replace hardcoded defaults with empty strings and require users to provide values explicitly:
- secret_key: "60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5"
+ secret_key: ""- live_server_secret_key: "htbqvBJAgpm9bzvf3r4urJer0ENReatceh"
+ live_server_secret_key: ""- aes_secret_key: 'dsOdt7YrvxsTIFJ37pOaEVvLxN8KGBCr'
+ aes_secret_key: ''Additionally, search all Helm templates for | default "..." filters on these secrets and remove them to enforce explicit configuration requirements.
Also applies to: 438-438, 449-449
🧰 Tools
🪛 Gitleaks (8.29.1)
[high] 426-426: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
charts/plane-enterprise/values.yaml around lines 426, 438 and 449: replace the
three hardcoded secret defaults (secret_key, live_server_secret_key,
aes_secret_key) with empty strings so values.yaml does not contain secrets, and
update any documentation comment to require users to provide these values; then
search all Helm templates for uses of these keys with a | default "..." filter
and remove the default fallback so the templates rely solely on the provided
values (or fail validation) thereby forcing explicit configuration.
- Consolidated resource specifications (memory limits, CPU limits, memory requests, and CPU requests) into subquestions for PI Worker and PI Beat Worker setups. - Improved organization of configuration options for better clarity and usability.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
charts/plane-enterprise/questions.yml (1)
68-72: Remove duplicate PI image definition.The PI Docker image is declared here and again in the
services.pi.enabledblock (lines 759–763). Consolidate both under theservices.pi.enabledconditional to avoid duplication and reduce maintenance burden.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
charts/plane-enterprise/questions.yml(6 hunks)
🔇 Additional comments (3)
charts/plane-enterprise/questions.yml (3)
913-956: PI worker configurations follow established patterns.Replica counts, memory, and CPU settings for
pi_workerandpi_beat_workerare consistent with existing worker service definitions. Structure is sound.
1044-1048: Postgres PI database configuration is well-structured.Conditional visibility (local vs. remote) and safe defaults. Follows existing Postgres configuration patterns.
Also applies to: 1059-1063
1344-1348: External secrets configuration is well-structured.The new
opensearch_existingSecret,pi_api_env_existingSecret, andpi_common_env_existingSecretentries correctly support external secret managers (Sealed Secrets, HashiCorp Vault, AWS Secrets Manager). Follows established patterns and provides a secure path for production deployments once hardcoded defaults are remediated.Also applies to: 1369-1377
| - variable: services.pi.enabled | ||
| label: "Enable Plane AI (PI) Service" | ||
| type: boolean | ||
| default: false | ||
| group: "Plane AI Setup" | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.image | ||
| label: "PI Docker Image" | ||
| type: string | ||
| required: true | ||
| default: "artifacts.plane.so/makeplane/plane-pi-commercial" | ||
| - variable: services.pi.pullPolicy | ||
| label: "PI Pull Policy" | ||
| type: enum | ||
| options: | ||
| - "Always" | ||
| - "IfNotPresent" | ||
| - "Never" | ||
| default: "Always" | ||
| - variable: services.pi.replicas | ||
| label: "Default Replica Count" | ||
| type: int | ||
| default: 1 | ||
| - variable: services.pi.memoryLimit | ||
| label: "Memory Limit" | ||
| type: string | ||
| default: 1000Mi | ||
| - variable: services.pi.cpuLimit | ||
| label: "CPU Limit" | ||
| type: string | ||
| default: 500m | ||
| - variable: services.pi.memoryRequest | ||
| label: "Memory Request" | ||
| type: string | ||
| default: 50Mi | ||
| - variable: services.pi.cpuRequest | ||
| label: "CPU Request" | ||
| type: string | ||
| default: 50m | ||
| - variable: services.pi.assign_cluster_ip | ||
| label: "Assign Cluster IP" | ||
| type: boolean | ||
| default: false | ||
| - variable: env.pi_envs.plane_oauth.client_id | ||
| label: "Plane OAuth Client ID" | ||
| type: string | ||
| default: "" | ||
| - variable: env.pi_envs.plane_oauth.client_secret | ||
| label: "Plane OAuth Client Secret" | ||
| type: password | ||
| default: "" | ||
| - variable: env.pi_envs.plane_oauth.redirect_uri | ||
| label: "Plane OAuth Redirect URI" | ||
| type: string | ||
| default: "" | ||
| - variable: env.pi_envs.plane_oauth.state_expiry_seconds | ||
| label: "Plane OAuth State Expiry Seconds" | ||
| type: int | ||
| default: 82800 | ||
| - variable: env.pi_envs.plane_api_host | ||
| label: "Plane API Host" | ||
| type: string | ||
| default: "" | ||
| - variable: env.pi_envs.cors_allowed_origins | ||
| label: "CORS Allowed Origins" | ||
| type: string | ||
| default: "" | ||
| - variable: env.pi_envs.cohere_api_key | ||
| label: "Cohere API Key" | ||
| type: string | ||
| default: "" | ||
| - variable: env.pi_envs.celery.vector_sync_enabled | ||
| label: "Vector Sync Enabled" | ||
| type: boolean | ||
| default: false | ||
| - variable: env.pi_envs.celery.vector_sync_interval | ||
| label: "Vector Sync Interval" | ||
| type: int | ||
| default: 3 | ||
| - variable: env.pi_envs.celery.workspace_plan_sync_enabled | ||
| label: "Workspace Plan Sync Enabled" | ||
| type: boolean | ||
| default: false | ||
| - variable: env.pi_envs.celery.workspace_plan_sync_interval | ||
| label: "Workspace Plan Sync Interval" | ||
| type: int | ||
| default: 86400 | ||
| - variable: env.pi_envs.celery.docs_sync_enabled | ||
| label: "Docs Sync Enabled" | ||
| type: boolean | ||
| default: false | ||
| - variable: env.pi_envs.celery.docs_sync_interval | ||
| label: "Docs Sync Interval" | ||
| type: int | ||
| default: 86400 | ||
| - variable: services.pi.ai_providers.openai.enabled | ||
| label: "Enable OpenAI Provider" | ||
| type: boolean | ||
| default: false | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.ai_providers.openai.api_key | ||
| label: "OpenAI API Key" | ||
| type: password | ||
| default: "" | ||
| - variable: services.pi.ai_providers.claude.enabled | ||
| label: "Enable Claude Provider" | ||
| type: boolean | ||
| default: false | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.ai_providers.claude.api_key | ||
| label: "Claude API Key" | ||
| type: password | ||
| default: "" | ||
| - variable: services.pi.ai_providers.mistral.enabled | ||
| label: "Enable Mistral Provider" | ||
| type: boolean | ||
| default: false | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.ai_providers.mistral.api_key | ||
| label: "Mistral API Key" | ||
| type: password | ||
| default: "" | ||
| - variable: services.pi.ai_providers.groq.enabled | ||
| label: "Enable Groq Provider" | ||
| type: boolean | ||
| default: false | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.ai_providers.groq.api_key | ||
| label: "Groq API Key" | ||
| type: password | ||
| default: "" | ||
| - variable: services.pi.ai_providers.assemblyai.enabled | ||
| label: "Enable AssemblyAI Provider" | ||
| type: boolean | ||
| default: false | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.ai_providers.assemblyai.api_key | ||
| label: "AssemblyAI API Key" | ||
| type: password | ||
| default: "" | ||
| - variable: services.pi.ai_providers.deepgram.enabled | ||
| label: "Enable Deepgram Provider" | ||
| type: boolean | ||
| default: false | ||
| show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.pi.ai_providers.deepgram.api_key | ||
| label: "Deepgram API Key" | ||
| type: password | ||
| default: "" | ||
| - variable: env.pi_envs.internal_secret | ||
| label: "PI Internal Secret" | ||
| type: string | ||
| default: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the exact content at lines 752-911 of the questions.yml file
echo "=== Content at lines 752-911 ==="
sed -n '752,911p' charts/plane-enterprise/questions.yml | tail -20
echo ""
echo "=== Searching for the hardcoded secret string across codebase ==="
rg -n "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" --type yaml
echo ""
echo "=== Searching for internal_secret references ==="
rg -n "internal_secret" --type yaml -C 2Repository: makeplane/helm-charts
Length of output: 3417
🏁 Script executed:
#!/bin/bash
echo "=== All hardcoded secrets with default filters in templates ==="
rg -n "default \"[a-zA-Z0-9]+\"" charts/plane-enterprise/templates/config-secrets/ --type yaml
echo ""
echo "=== Check values.yaml for other hardcoded secrets ==="
rg -n "secret.*:" charts/plane-enterprise/values.yaml -A 1 | head -40
echo ""
echo "=== Check for any warnings or comments about hardcoded values ==="
rg -n "hardcoded|development|production|CHANGE|MUST|SECRET|WARNING" charts/plane-enterprise/values.yaml -i | head -20Repository: makeplane/helm-charts
Length of output: 6225
CRITICAL: Hardcoded PI_INTERNAL_SECRET with systemic security issue—multiple unresolved hardcoded secrets across codebase.
Verification confirms the hardcoded default PI_INTERNAL_SECRET at line 908–911 in questions.yml is correct and critical. However, the scope is significantly broader than the original comment indicates:
Confirmed hardcoded secrets in plaintext across multiple files:
- questions.yml (line 911):
internal_secret: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" - values.yaml (lines 426, 438, 449, 486):
secret_key,live_server_secret_key,aes_secret_key,internal_secretall hardcoded - templates/config-secrets/app-env.yaml (lines 9–12): SECRET_KEY, AES_SECRET_KEY, LIVE_SERVER_SECRET_KEY, PI_INTERNAL_SECRET with
| default "HARDCODED"filters - templates/config-secrets/pgdb.yaml (line 12): POSTGRES_PASSWORD defaults to
"plane" - templates/config-secrets/doc-store.yaml (line 14): MINIO_ROOT_PASSWORD defaults to
"password" - templates/config-secrets/live-env.yaml, silo.yaml, pi-api-env.yaml: Additional hardcoded secret defaults
The hidden fallback pattern is the critical vulnerability: Template defaults using | default "HARDCODED_VALUE" silently activate hardcoded secrets even when users think they're providing custom values. This is checked into VCS with no warnings or production-safety guards.
Required fixes:
- Replace all hardcoded secrets in values.yaml with empty strings or
# CHANGE_MEplaceholders - Remove all hardcoded
| default "SECRET"filters from templates; userequiredvalidation or explicit error messages instead - Mark all secret fields as
required: truein questions.yml - Add documentation/warnings that this chart is unsafe for production without proper secret configuration
- Add pre-deployment validation to fail if secrets remain at defaults
🤖 Prompt for AI Agents
In charts/plane-enterprise/questions.yml around lines 752–911, a hardcoded PI
internal secret is present and many secret fields lack required validation;
remove the hardcoded default value for env.pi_envs.internal_secret (set to empty
or a CHANGE_ME placeholder) and mark all secret variables in this file as
required: true (no plaintext defaults); then audit related Helm chart files to
remove inline hardcoded defaults (e.g., templates/* and values.yaml) and replace
them with empty placeholders or comments, add templating validation to error
when required secrets are unset, and include a brief README warning that secrets
must be provided before deployment.
| - variable: services.opensearch.password | ||
| label: "Password" | ||
| type: password | ||
| default: "Secure@Pass#123!%^&*" | ||
| show_if: "services.opensearch.local_setup=true" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Step 1: Verify the hardcoded password at lines 1101-1105 in questions.yml
sed -n '1101,1105p' charts/plane-enterprise/questions.ymlRepository: makeplane/helm-charts
Length of output: 236
🏁 Script executed:
#!/bin/bash
# Step 2: Search for this hardcoded password pattern across the codebase
rg -n "Secure@Pass#123" --type yamlRepository: makeplane/helm-charts
Length of output: 1083
🏁 Script executed:
#!/bin/bash
# Step 3: Look for opensearchdb template file mentioned in the review
find . -name "*opensearchdb*" -type fRepository: makeplane/helm-charts
Length of output: 133
🏁 Script executed:
#!/bin/bash
# Step 4: Search for OpenSearch password configurations in values.yaml files
rg -n "opensearch.*password" -i --type yaml | head -30Repository: makeplane/helm-charts
Length of output: 1959
🏁 Script executed:
#!/bin/bash
# Step 5: Examine the opensearchdb.yaml template in detail
cat -n charts/plane-enterprise/templates/config-secrets/opensearchdb.yamlRepository: makeplane/helm-charts
Length of output: 2810
🏁 Script executed:
#!/bin/bash
# Step 6: Check the values.yaml for the opensearch password configuration
sed -n '85,95p' charts/plane-enterprise/values.yamlRepository: makeplane/helm-charts
Length of output: 338
The hardcoded password "Secure@Pass#123!%^&*" is embedded across the entire chart in at least 6 locations with multiple fallback layers:
Confirmed locations:
questions.ymlline 1104: UI form defaultvalues.yamlline 90: Helm values defaulttemplates/config-secrets/opensearchdb.yamllines 10–11: Kubernetes Secret with default filterstemplates/config-secrets/opensearchdb.yamlline 30: Shell script environment variable fallbacktemplates/config-secrets/pi-common-env.yamlline 23: Additional default filtertemplates/config-secrets/app-env.yamlline 41: Additional default filter
Critical impact: Even if a user omits the password configuration, all three layers (| default filters in templates, shell script ${VAR:-} pattern, and Secret creation) silently default to this known credential. The Kubernetes Secret stores it in plaintext.
Required fixes:
- Remove all hardcoded defaults; replace with empty string or required field markers
- Add
required: truetoservices.opensearch.passwordin questions.yml whenlocal_setup=true - Add security warning description: "SECURITY: Generate a strong random password. This is used locally for development only; must be changed before production deployment."
- Remove all
| default "Secure@Pass#123!%^&*"filters from templates; fail loudly if password is unset - Update shell script fallback to fail rather than silently use default
- Removed obsolete configuration options for PI Docker Image and Pull Policy. - Added new configuration option for Cohere API Key. - Introduced conditional display logic for various environment variables related to Celery and OpenAI provider.
- Removed obsolete 'show_if' conditions for workspace plan and docs sync options in questions.yml. - Added new configuration options for 'PI Internal Secret' and 'ML Model ID' in questions.yml. - Updated PLANE_API_HOST and PLANE_OAUTH_REDIRECT_URI logic in pi-api-env.yaml to use license domain for better flexibility.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml (2)
79-83: **** CORS_ALLOWED_ORIGINS format inconsistency between user-provided and default values (already flagged in past review).
74-74: **** Hardcoded PI_INTERNAL_SECRET default is a systemic security issue (already flagged in past review as critical).charts/plane-enterprise/questions.yml (2)
835-838: **** Hardcoded PI_INTERNAL_SECRET default is a systemic security issue (already flagged in past review as critical).
1057-1125: **** Hardcoded OpenSearch password (line 1096) is a systemic security issue (already flagged in past review as critical).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
charts/plane-enterprise/questions.yml(6 hunks)charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (8)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml (2)
1-1: **** YAMLLint's syntax error is a false positive for valid Helm conditional syntax.
45-49: **** Cohere API key naming is consistent with values.yaml and company branding.charts/plane-enterprise/questions.yml (6)
68-72: LGTM. PI Docker image follows the established pattern for service image configuration. Properly marked as required.
752-833: LGTM. PI service configuration section is well-structured with proper conditional subquestions, resource specifications, and environment variables. Follows established patterns.
845-904: LGTM. AI provider configuration follows a consistent, secure pattern. API keys are properly marked as password fields with empty defaults, matching established patterns for connectors.
905-948: LGTM. PI Worker and Beat Worker configurations follow the established worker pattern with appropriate resource specifications.
1036-1055: LGTM. Postgres PI database configuration follows the dual-setup pattern (local/remote) with clear naming and appropriate conditional visibility.
1336-1370: LGTM. External Secrets configuration for OpenSearch and PI follows established patterns. Proper alignment with corresponding Helm templates and secrets.
| {{- if .Values.services.postgres.local_setup }} | ||
| PLANE_PI_DATABASE_URL: "postgresql://{{ .Values.env.pgdb_username }}:{{ .Values.env.pgdb_password }}@{{ .Release.Name }}-pgdb.{{ .Release.Namespace }}.svc.cluster.local/{{ .Values.env.pg_pi_db_name }}" | ||
| {{- else if .Values.env.pg_pi_db_remote_url }} | ||
| PLANE_PI_DATABASE_URL: {{ .Values.env.pg_pi_db_remote_url}} |
There was a problem hiding this comment.
Add quote filter to remote database URL for safe YAML rendering.
Line 32 omits the | quote filter used elsewhere (e.g., line 40). Without it, URLs with special characters may break YAML syntax.
- PLANE_PI_DATABASE_URL: {{ .Values.env.pg_pi_db_remote_url}}
+ PLANE_PI_DATABASE_URL: {{ .Values.env.pg_pi_db_remote_url | quote }}🤖 Prompt for AI Agents
In charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml around line
32, the PLANE_PI_DATABASE_URL value is rendered without the | quote filter which
can break YAML if the remote DB URL contains special characters; update the
template to apply the | quote filter to .Values.env.pg_pi_db_remote_url so the
value is safely quoted in the generated YAML, matching the pattern used
elsewhere (e.g., line 40).
- Reorganized AI provider settings under a new group "Plane AI Providers" for better clarity. - Restored and updated configuration options for OpenAI, Claude, Mistral, Groq, AssemblyAI, and Deepgram providers, including enabling flags and API key subquestions. - Removed redundant entries and ensured consistent formatting across all provider configurations.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
charts/plane-enterprise/questions.yml (2)
1063-1131: 🔴 CRITICAL: OpenSearch password hardcoded default must be removed.Line 1102 contains a plaintext hardcoded password
"Secure@Pass#123!%^&*"that will be checked into version control. This is a known security vulnerability flagged in previous reviews and persists in this iteration.Required fixes:
- Replace the hardcoded default with an empty string
- Mark the field as
required: truewhenservices.opensearch.local_setup=true- Add a security warning in the description field
- Add validation in the chart to fail deployment if the password remains at the default value
Suggested fix:
- variable: services.opensearch.password label: "Password" type: password - default: "Secure@Pass#123!%^&*" + default: "" + required: true + description: "SECURITY: Generate a strong random password. Development defaults are insecure and must be changed before production deployment." show_if: "services.opensearch.local_setup=true"Additionally, verify that all hardcoded secret defaults in
values.yamlandtemplates/config-secrets/*.yaml(e.g.,POSTGRES_PASSWORD,MINIO_ROOT_PASSWORD) are also addressed as part of this PR or a related security hardening effort.
752-843: 🔴 CRITICAL: PI_INTERNAL_SECRET hardcoded default must be removed or marked as development-only.Line 842 contains a plaintext hardcoded secret
"tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk"that will be visible in version control and accessible to anyone with chart read access. This persists from a previous review and represents a security vulnerability.Required fixes:
- Replace the hardcoded default with an empty string or a
# CHANGE_MEplaceholder- Mark the field as
required: trueto prevent accidental deployment without a custom secret- Add a prominent security warning in the field description:
"SECURITY: Provide a strong random value. Development default is insecure; must be changed before production deployment."- Add validation elsewhere in the chart (e.g., Helm hooks or values schema) to reject defaults that match known development values
Suggested fix for this field:
- variable: env.pi_envs.internal_secret label: "PI Internal Secret" type: string - default: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" + default: "" + required: true + description: "SECURITY: Generate a strong random secret. This must be changed from the development default before production deployment."
🧹 Nitpick comments (2)
charts/plane-enterprise/questions.yml (2)
839-843: Consider adding explicit documentation for Cohere and OpenSearch ML model configuration.The
cohere_api_keyandopensearch_ml_model_idfields lack descriptions. For users unfamiliar with the PI service integration, brief guidance on these fields would improve usability.Example enhancement:
- variable: env.pi_envs.cohere_api_key label: "Cohere API Key" type: string default: "" + description: "Optional: API key for Cohere-powered AI features. Leave blank to disable Cohere integration."
889-954: PI AI Providers configuration is well-structured but lacks user guidance.Six provider toggles (OpenAI, Claude, Mistral, Groq, AssemblyAI, Deepgram) are cleanly separated into distinct question groups. However, each provider lacks a description explaining:
- When to enable it
- What the API key field accepts
- Whether multiple providers can be enabled simultaneously
- Which provider is recommended or default
Consider adding descriptions to each provider's
enabledfield:- variable: services.pi.ai_providers.openai.enabled label: "Enable OpenAI Provider" type: boolean default: false group: "Plane AI Providers" + description: "Enable to use OpenAI models (GPT-4, GPT-3.5, etc.) for AI features." show_subquestion_if: true
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
charts/plane-enterprise/questions.yml(6 hunks)
🔇 Additional comments (4)
charts/plane-enterprise/questions.yml (4)
68-72: PI Docker image added to planeVersion subquestions. ✓This follows the established pattern for service images. However, ensure the image
artifacts.plane.so/makeplane/plane-pi-commercialis available in your registry at the specified version tag.
844-887: PI Worker and PI Beat Worker configurations follow established patterns. ✓Resource specifications are consistent with other worker services (replicas, memory/CPU limits and requests). No issues identified.
1042-1061: Postgres PI database configuration is correctly conditional.The PI DB name and remote URL fields are properly gated by
services.postgres.local_setupto show only when relevant (local vs. remote). Naming convention (pg_pi_db_name,pg_pi_db_remote_url) is consistent and clear.
1342-1376: External Secrets configuration follows established patterns. ✓The addition of
external_secrets.opensearch_existingSecret,external_secrets.pi_api_env_existingSecret, andexternal_secrets.pi_common_env_existingSecretis consistent with existing external secrets entries. No structural issues identified.
| - variable: env.opensearch_index_prefix | ||
| label: "Index Prefix" | ||
| type: string | ||
| default: "" | ||
| - variable: env.pi_envs.opensearch_ml_model_id | ||
| label: "ML Model ID" | ||
| type: string | ||
| default: "" |
There was a problem hiding this comment.
Duplicate ML Model ID field in OpenSearch Setup section.
Line 1128-1131 defines env.pi_envs.opensearch_ml_model_id here, but this field was already defined at line 835-838 within the main PI Service configuration. This creates a duplicate reference to the same variable in two different places.
Action: Remove the duplicate definition at lines 1128–1131. The field is already under the main PI Service configuration and should be referenced there, not repeated here.
- variable: env.opensearch_index_prefix
label: "Index Prefix"
type: string
default: ""
- - variable: env.pi_envs.opensearch_ml_model_id
- label: "ML Model ID"
- type: string
- default: ""📝 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.
| - variable: env.opensearch_index_prefix | |
| label: "Index Prefix" | |
| type: string | |
| default: "" | |
| - variable: env.pi_envs.opensearch_ml_model_id | |
| label: "ML Model ID" | |
| type: string | |
| default: "" | |
| - variable: env.opensearch_index_prefix | |
| label: "Index Prefix" | |
| type: string | |
| default: "" |
🤖 Prompt for AI Agents
In charts/plane-enterprise/questions.yml around lines 1124 to 1131, there is a
duplicate variable declaration env.pi_envs.opensearch_ml_model_id (ML Model ID)
in the OpenSearch Setup section that already exists at lines ~835–838 under the
main PI Service configuration; remove the duplicate block at lines 1128–1131 so
the variable is only defined once (keep the original definition in the main PI
Service section and update any references to use that single variable).
…o add-plane-ai-services
- Removed obsolete configurations for Mistral, AssemblyAI, and Deepgram providers in questions.yml and values.yaml. - Added new configuration options for Cohere provider, including base URL and API key. - Updated app-env.yaml and pi-api-env.yaml to include new environment variables for OpenAI, Claude, Cohere, and Groq base URLs. - Improved organization and clarity of AI provider settings under "Plane AI Providers".
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (7)
charts/plane-enterprise/questions.yml (3)
1115-1122: Remove duplicate ML Model ID field definition.The
env.pi_envs.opensearch_ml_model_idfield is defined twice:
- First at lines 831-834 (within Plane AI Setup group under PI service config)
- Again at lines 1119-1122 (within OpenSearch Setup group)
This duplication creates confusion about where to configure the value and increases maintenance burden.
Remove the duplicate definition at lines 1119–1122; users should configure ML Model ID in the main Plane AI Setup section.
- variable: env.opensearch_index_prefix label: "Index Prefix" type: string default: "" - - variable: env.pi_envs.opensearch_ml_model_id - label: "ML Model ID" - type: string - default: ""
1090-1094:⚠️ Hardcoded OpenSearch password default in questions.yml—systemic security risk.The default
"Secure@Pass#123!%^&*"is a known credential checked into version control. This value appears in multiple locations (questions.yml, values.yaml, templates) and will be silently deployed if not overridden.Replace with empty default and add security warning:
- variable: services.opensearch.password label: "Password" type: password - default: "Secure@Pass#123!%^&*" + default: "" + description: "SECURITY: Generate a strong random password. Required for local OpenSearch setup. This is for development only; must be changed before production." show_if: "services.opensearch.local_setup=true"Also update values.yaml line 90 and ensure templates do not have fallback defaults.
835-839:⚠️ Hardcoded PI_INTERNAL_SECRET in questions.yml checked into version control.The default value
"tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk"is a known public default that will be presented to users and persisted in their values. Users may inadvertently deploy this to production.Replace with an empty placeholder and add documentation:
- variable: env.pi_envs.internal_secret label: "PI Internal Secret" type: string - default: "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" + default: "" + description: "SECURITY: Generate a strong random secret. This value should not be the default placeholder."Also update the corresponding entry in values.yaml (line 483).
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml (2)
23-23: Add quote filter to remote PI database URL to prevent YAML parsing errors.Line 23 omits the
| quotefilter used elsewhere (e.g., line 40 for RabbitMQ). URLs with special characters (:,@,#, etc.) can break YAML syntax if unquoted.Apply this diff:
- PLANE_PI_DATABASE_URL: {{ .Values.env.pg_pi_db_remote_url}} + PLANE_PI_DATABASE_URL: {{ .Values.env.pg_pi_db_remote_url | quote }}
70-74: CORS_ALLOWED_ORIGINS format inconsistency—emits array instead of comma-separated string.The pi-api template outputs different formats depending on whether a user value is provided:
- User-provided value (line 71):
"value"(string via| quote)- Default (line 73):
["http://...", "https://..."](JSON array literal, not quoted)This diverges from all other services (app-env.yaml, silo.yaml), which consistently emit comma-separated strings. The PI API cannot reliably parse both formats.
Align pi-api CORS to match other services using comma-separated strings:
- {{- if .Values.env.pi_envs.cors_allowed_origins }} - CORS_ALLOWED_ORIGINS: {{ .Values.env.pi_envs.cors_allowed_origins | quote }} + {{- if eq .Values.env.pi_envs.cors_allowed_origins "*" }} + CORS_ALLOWED_ORIGINS: "*" + {{- else if .Values.env.pi_envs.cors_allowed_origins }} + CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }},{{ .Values.env.pi_envs.cors_allowed_origins }}" {{- else }} - CORS_ALLOWED_ORIGINS: ["http://{{ .Values.license.licenseDomain }}", "https://{{ .Values.license.licenseDomain }}"] + CORS_ALLOWED_ORIGINS: "http://{{ .Values.license.licenseDomain }},https://{{ .Values.license.licenseDomain }}" {{- end }}This ensures consistent string format across all services.
charts/plane-enterprise/values.yaml (2)
475-484:⚠️ Hardcoded PI_INTERNAL_SECRET default in values.yaml—production deployment risk.Line 483 contains a known public default value that will be version-controlled and used as a fallback in Helm templates. Users may unknowingly deploy this to production.
Replace with empty placeholder and enforce explicit configuration:
pi_envs: plane_oauth: client_id: '' client_secret: '' redirect_uri: '' state_expiry_seconds: 82800 plane_api_host: '' cors_allowed_origins: '' - internal_secret: 'tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk' + internal_secret: '' opensearch_ml_model_id: ''This must be paired with template changes to enforce
requiredvalidation instead of| default "..."fallbacks.
83-96: OpenSearch service block correctly structured, but hardcoded password poses security risk.The service configuration follows the established pattern for redis, postgres, and rabbitmq. However, line 90 contains a hardcoded default password that will be version-controlled and deployed if not overridden.
Replace the hardcoded default with an empty placeholder:
opensearch: local_setup: true image: opensearchproject/opensearch:3.3.2 servicePort: 9200 volumeSize: 5Gi pullPolicy: IfNotPresent username: plane - password: Secure@Pass#123!%^&* + password: "" assign_cluster_ip: falseAlso update the corresponding question in questions.yml (line 1093) and ensure Helm templates do not have
| default "Secure@Pass#123!%^&*"fallbacks.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
charts/plane-enterprise/questions.yml(6 hunks)charts/plane-enterprise/templates/config-secrets/app-env.yaml(4 hunks)charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml(1 hunks)charts/plane-enterprise/values.yaml(5 hunks)
🧰 Additional context used
🪛 Gitleaks (8.30.0)
charts/plane-enterprise/values.yaml
[high] 483-483: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 YAMLlint (1.37.1)
charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (11)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (3)
40-46: OpenSearch password handling follows correct conditional pattern but retains hardcoded defaults.The password selection logic (local vs. remote vs. disabled) is sound. However, the underlying defaults in
values.yamlandquestions.ymlremain hardcoded known values, creating a systemic security issue. This requires upstream fixes in the values file.Consider pairing template changes with a security review of all service passwords across values.yaml, questions.yml, and templates.
79-80: PI configuration routes correctly appended to ConfigMap.The PI_BASE_URL and PI_BASE_PATH additions align with the PI API service deployment pattern and are consistent with similar entries (e.g., LIVE_BASE_URL).
94-109: OpenSearch configuration block properly scaffolds local and remote modes.The conditional logic correctly handles three scenarios (local enabled, remote provided, neither). Configuration keys and fallback values follow the established pattern. Layout and formatting are correct.
charts/plane-enterprise/questions.yml (2)
1333-1337: External Secrets definitions for OpenSearch added correctly.The new
opensearch_existingSecretentry (lines 1333–1337) follows the established pattern and integrates cleanly with other external secret definitions.
1358-1367: External Secrets definitions for PI environments added correctly.The new entries for
pi_api_env_existingSecretandpi_common_env_existingSecret(lines 1358–1367) follow established conventions and support the new PI service workloads.charts/plane-enterprise/values.yaml (6)
322-354: PI service configuration block well-structured with AI provider toggles.The services.pi block correctly includes all necessary fields (replicas, resource limits, image, pullPolicy, cluster IP assignment, and nested AI provider configs). Structure aligns with other service definitions and supports the PI API, worker, and beat-worker deployments.
355-377: PI worker and PI beat-worker configuration blocks follow established patterns.Both blocks define replicas and resource constraints (memory/CPU limits and requests) consistent with other worker configurations (worker, beatworker). Node selectors, tolerations, affinity, labels, and annotations are correctly placeholders.
401-403: PI database configuration parameters added correctly.The new
pg_pi_db_name(line 401) andpg_pi_db_remote_url(line 403) follow the naming convention and structure of their non-PI counterparts (pgdb_name, pgdb_remote_url), supporting both local and remote PI database scenarios.
417-421: OpenSearch remote configuration parameters correctly structured.The three new env keys (opensearch_remote_url, opensearch_remote_username, opensearch_remote_password) and opensearch_index_prefix provide proper support for external OpenSearch integration. Defaults (empty strings) are safe and require explicit user configuration.
475-492: PI environment configuration with Celery settings correctly scaffolded.The pi_envs block includes:
- OAuth config (client_id, client_secret, redirect_uri, state_expiry_seconds)
- API host, CORS origins, internal secret, OpenSearch ML Model ID
- Celery sync toggles and intervals for vector, workspace plan, and docs syncing
Except for the hardcoded
internal_secretdefault (line 483, flagged separately), the structure is sound and aligns with the PI service requirements.
383-389: External Secrets entries for OpenSearch and PI environments added correctly.The new entries follow established naming conventions and integrate cleanly without introducing conflicts or redundancy.
| SECRET_KEY: {{ .Values.env.secret_key | default "60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5" | quote }} | ||
| AES_SECRET_KEY: {{ .Values.env.silo_envs.aes_secret_key | default "dsOdt7YrvxsTIFJ37pOaEVvLxN8KGBCr" | quote }} | ||
| LIVE_SERVER_SECRET_KEY: {{ .Values.env.live_server_secret_key | default "htbqvBJAgpm9bzvf3r4urJer0ENReatceh" | quote }} | ||
| PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | default "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" | quote }} |
There was a problem hiding this comment.
This secret is checked into the repository with a known default value. Even though users can override it, the fallback default via | default "..." ensures this value is deployed if not explicitly provided.
Apply this diff to remove the hardcoded default and require explicit configuration:
- PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | default "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" | quote }}
+ PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | required "PI_INTERNAL_SECRET must be configured" | quote }}Consider also: documenting in the chart README which secrets are non-optional for production.
📝 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.
| PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | default "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" | quote }} | |
| PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | required "PI_INTERNAL_SECRET must be configured" | quote }} |
🤖 Prompt for AI Agents
charts/plane-enterprise/templates/config-secrets/app-env.yaml lines 12: the
PI_INTERNAL_SECRET currently uses a hardcoded fallback value which risks leaking
a known secret into production; remove the hardcoded default and make the value
required by replacing the default pipeline with a Helm required() check (e.g.
required("PI_INTERNAL_SECRET must be set", .Values.env.pi_envs.internal_secret))
so Helm will fail unless explicitly provided, and update the chart README to
document that PI_INTERNAL_SECRET is mandatory for production deployments.
| PLANE_API_HOST: "http://{{ .Values.license.licenseDomain }}" | ||
| {{- end }} | ||
|
|
||
| PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | default "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" | quote }} |
There was a problem hiding this comment.
Like in app-env.yaml, this secret receives a known hardcoded default that will be deployed if not overridden. Coupled with the template default, users may unknowingly use a public secret value in production.
Apply this diff to enforce explicit configuration:
- PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | default "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" | quote }}
+ PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | required "PI_INTERNAL_SECRET must be configured" | quote }}🤖 Prompt for AI Agents
In charts/plane-enterprise/templates/config-secrets/pi-api-env.yaml at line 65,
the PI_INTERNAL_SECRET is using a hardcoded default which risks leaking a public
secret into production; replace the default with a required check so Helm
rendering fails unless the value is explicitly provided (e.g. use Helm's
required function on .Values.env.pi_envs.internal_secret and then quote it),
removing the hardcoded literal entirely.
…al SSL settings - Modified the PI_BASE_URL to use HTTPS if the SSL issuer is created, otherwise defaults to HTTP. - Enhanced flexibility in environment variable configurations for the PI service based on license domain.
- Adjusted the indentation for the conditional statement checking .Values.ssl.create_issuer to ensure proper YAML formatting. - This change enhances readability and maintains consistency in the configuration file.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (1)
12-12: Critical issue from previous review remains unaddressed: hardcoded PI_INTERNAL_SECRET default.The past review flagged this as a production risk, and you marked it as "done," but the hardcoded default value is still present in the code. This secret will be deployed with a known fallback value unless explicitly overridden, creating a significant security vulnerability.
Apply the suggested fix from the previous review:
- PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | default "tyfvfqvBJAgpm9bzvf3r4urJer0Ehfdubk" | quote }} + PI_INTERNAL_SECRET: {{ .Values.env.pi_envs.internal_secret | required "PI_INTERNAL_SECRET must be configured" | quote }}
🧹 Nitpick comments (1)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (1)
9-11: Consider whether hardcoded secret defaults pose broader risk.While not new to this PR, lines 9–11 follow the same pattern as the flagged PI_INTERNAL_SECRET: hardcoded fallback values for SECRET_KEY, AES_SECRET_KEY, and LIVE_SERVER_SECRET_KEY. If production deployments can accidentally use these defaults, consider requiring all non-optional secrets (including these) to avoid the same risk.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
charts/plane-enterprise/templates/config-secrets/app-env.yaml(4 hunks)
🔇 Additional comments (3)
charts/plane-enterprise/templates/config-secrets/app-env.yaml (3)
40-46: OpenSearch password conditional logic looks correct.The branching logic properly handles local setup, remote URL, and disabled scenarios. The use of
opensearch_remote_passwordaligns with the past review feedback.
78-83: PI_BASE_URL scheme correctly conditioned on SSL issuer.Properly uses
https://whenssl.create_issueris enabled, falling back tohttp://otherwise. This provides sensible defaults based on the deployment's SSL configuration.
97-112: OpenSearch ConfigMap entries properly structured with comprehensive conditionals.Three-branch logic (local setup → enabled; remote URL → enabled; else → disabled) is well-designed. Defaults are reasonable: local username defaults to "plane", remote username defaults to empty string (appropriate for optional remote auth).
…o add-plane-ai-services
- Introduced AES_SECRET_KEY in the configuration to improve encryption handling. - Default value provided for backward compatibility while allowing customization through .Values.env.silo_envs.aes_secret_key.
Description
This pull request introduces significant enhancements to the Helm chart for Plane Enterprise, focusing on adding support for the new Plane AI (PI) service and its related components, as well as integrating OpenSearch as a service.
Type of Change
Summary by CodeRabbit
New Features
Refactor
✏️ Tip: You can customize this high-level summary in your review settings.