[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 |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR introduces Plane AI (PI) integration to the Helm chart, adding services (pi, pi_worker, pi_beat_worker), workload deployments, environment configurations, and ingress routing. It also refactors pod scheduling includes across workload templates. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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".
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
charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml
Outdated
Show resolved
Hide resolved
charts/plane-enterprise/templates/workloads/pi-worker.deployment.yaml
Outdated
Show resolved
Hide resolved
- 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).
- 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: 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.
…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.
…o add-plane-ai-services
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
charts/plane-enterprise/values.yaml (1)
423-437:⚠️ Potential issue | 🟠 MajorDuplicate
opensearch_*env keys will cause unpredictable behavior.Lines 423–427 and 433–437 both define
opensearch_remote_url,opensearch_remote_username,opensearch_remote_password, andopensearch_index_prefixunderenv. In YAML, duplicate keys at the same level result in the last occurrence silently winning — the first block (emptyopensearch_index_prefix: '') is overridden by the second (opensearch_index_prefix: 'plane_'). This is a copy-paste error.Remove one of the two blocks and keep the intended defaults.
🐛 Proposed fix — remove the duplicate block
- `#OPENSEARCH` ENVS - opensearch_remote_url: '' - opensearch_remote_username: '' - opensearch_remote_password: '' - opensearch_index_prefix: '' - - `#API` KEYS secret_key: "60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5" api_key_rate_limit: "60/minute"
🤖 Fix all issues with AI agents
In `@charts/plane-enterprise/questions.yml`:
- Around line 1064-1132: There are two definitions of
services.opensearch.local_setup causing conflicting defaults; remove the
earlier/top duplicate block (the one with default: true) and keep the later
block (the one matching values.yaml default: false), then migrate the
env.pi_envs.opensearch_ml_model_id subquestion from the removed block into the
retained block so that services.opensearch.local_setup has a single definition
(default false) and all needed subquestions (including
env.pi_envs.opensearch_ml_model_id) live under that one definition.
🧹 Nitpick comments (2)
charts/plane-enterprise/templates/workloads/migrator.job.yaml (1)
18-36: Pre-existing: container lacks asecurityContext.Static analysis (Trivy KSV014/KSV118) flags that the container has no explicit
securityContext— e.g.,readOnlyRootFilesystem: true,runAsNonRoot: true, dropping capabilities. This is a pre-existing concern, not introduced by this PR, but worth addressing across workload templates as a hardening pass.charts/plane-enterprise/templates/workloads/beat-worker.deployment.yaml (1)
19-60: Consider adding asecurityContextto restrict container privileges.Trivy flags that this deployment uses the default security context, which allows root privileges (KSV118). While this is pre-existing and not introduced by this PR, it's worth addressing in a follow-up — e.g., setting
runAsNonRoot: trueand dropping capabilities.
| - variable: services.opensearch.local_setup | ||
| label: "Install OpenSearch" | ||
| type: boolean | ||
| default: true | ||
| group: "OpenSearch Setup" | ||
| # show_subquestion_if: true | ||
| subquestions: | ||
| - variable: services.opensearch.image | ||
| label: "Docker Image" | ||
| type: string | ||
| default: "opensearchproject/opensearch:3.3.2" | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: services.opensearch.pullPolicy | ||
| label: "OpenSearch Pull Policy" | ||
| type: enum | ||
| options: | ||
| - "Always" | ||
| - "IfNotPresent" | ||
| - "Never" | ||
| default: "IfNotPresent" | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: services.opensearch.servicePort | ||
| label: Service Port | ||
| type: int | ||
| default: 9200 | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: services.opensearch.volumeSize | ||
| label: "Volume Size" | ||
| type: string | ||
| default: "5Gi" | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: services.opensearch.username | ||
| label: "Username" | ||
| type: string | ||
| default: "plane" | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: services.opensearch.password | ||
| label: "Password" | ||
| type: password | ||
| default: "Secure@Pass#123!%^&*" | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: services.opensearch.assign_cluster_ip | ||
| label: "Assign Cluster IP" | ||
| type: boolean | ||
| default: false | ||
| show_if: "services.opensearch.local_setup=true" | ||
| - variable: env.opensearch_remote_url | ||
| label: "OpenSearch Remote URL" | ||
| type: string | ||
| default: "" | ||
| show_if: "services.opensearch.local_setup=false" | ||
| - variable: env.opensearch_remote_username | ||
| label: "OpenSearch Remote Username" | ||
| type: string | ||
| default: "" | ||
| show_if: "services.opensearch.local_setup=false" | ||
| - variable: env.opensearch_remote_password | ||
| label: "OpenSearch Remote Password" | ||
| type: password | ||
| default: "" | ||
| show_if: "services.opensearch.local_setup=false" | ||
| - 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.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find all occurrences of services.opensearch.local_setup in questions.yml
echo "=== All occurrences of services.opensearch.local_setup ==="
rg -n "services.opensearch.local_setup" charts/plane-enterprise/questions.yml
echo ""
echo "=== Context around first occurrence (lines 1060-1135) ==="
sed -n '1060,1135p' charts/plane-enterprise/questions.yml | cat -n
echo ""
echo "=== Context around second occurrence (lines 1185-1275) ==="
sed -n '1185,1275p' charts/plane-enterprise/questions.yml | cat -nRepository: makeplane/helm-charts
Length of output: 7953
🏁 Script executed:
#!/bin/bash
# Check values.yaml for opensearch local_setup setting around line 86
echo "=== values.yaml around line 86 ==="
sed -n '80,95p' charts/plane-enterprise/values.yaml | cat -n
echo ""
echo "=== All opensearch-related local_setup entries in values.yaml ==="
rg -n "local_setup" charts/plane-enterprise/values.yamlRepository: makeplane/helm-charts
Length of output: 750
Remove duplicate services.opensearch.local_setup block — conflicting defaults cause undefined rendering behavior.
Two top-level entries for services.opensearch.local_setup exist in this file:
- Block 1 (lines 1064–1132):
default: true - Block 2 (lines 1188–1274):
default: false
This creates a critical rendering conflict. Rancher UI (or any similar tool consuming questions.yml) exhibits undefined behavior when the same top-level variable is defined twice; typically the last definition wins, but subquestions from both blocks may render unpredictably.
Additionally, Block 1's default (true) contradicts values.yaml line 86 where local_setup: false is the intended default.
Keep Block 2 (it matches values.yaml and includes complete resource limit configurations). Remove Block 1, but first migrate the env.pi_envs.opensearch_ml_model_id field (lines 1129–1132) from Block 1 to Block 2 if this field is required.
🤖 Prompt for AI Agents
In `@charts/plane-enterprise/questions.yml` around lines 1064 - 1132, There are
two definitions of services.opensearch.local_setup causing conflicting defaults;
remove the earlier/top duplicate block (the one with default: true) and keep the
later block (the one matching values.yaml default: false), then migrate the
env.pi_envs.opensearch_ml_model_id subquestion from the removed block into the
retained block so that services.opensearch.local_setup has a single definition
(default false) and all needed subquestions (including
env.pi_envs.opensearch_ml_model_id) live under that one definition.
…o add-plane-ai-services
… setup, and simplify Plane OAuth client details.
…pi-common-env.yaml
…figurations for PI deployment
…ing provider and AWS region fields
…uration in silo.yaml
…s in questions.yml, README.md, and values.yaml
…ane AI (PI) deployment
3 participants
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
Release Notes
New Features
/pi/Chores