-
Notifications
You must be signed in to change notification settings - Fork 69
Open
Open
Enhancement
Copy link
Labels
area/program-resourceRelated to Program resourceRelated to Program resourcekind/enhancementImprovements or new featuresImprovements or new features
Description
Hello!
- Vote on this issue by adding a 👍 reaction
- If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)
Issue details
Problem Statement
The current Program CRD (pulumi.com/v1) only supports inline YAML programs embedded in the .program field. This has several limitations:
- Language restriction: Only YAML programs are supported
- Single-file limitation: Cannot easily express multi-file programs
- Schema maintenance burden: Operator must track Pulumi YAML schema evolution (Deal with pulumi-yaml deprecation of
configuration(in favour ofconfig) #404, Support full YAML resource option schema onProgramcustom resource #527)
Proposed Solution
Enable Stacks to reference ConfigMaps containing complete Pulumi programs. Users would create programs using:
kubectl create configmap my-python-program --from-file=./program-dir/Then reference it in a Stack:
apiVersion: pulumi.com/v1
kind: Stack
metadata:
name: my-stack
spec:
configMapSource:
name: my-python-program
stack: dev
# ... rest of stack configurationBenefits
- Multi-language support: Python, Go, TypeScript, .NET, Java, YAML - any Pulumi language
- Multi-file programs: Natural support for complex program structures
- Cleaner lifecycle: ConfigMaps are independent resources, avoiding deletion issues
- Better GitOps: ConfigMaps can be generated from Git sources, kustomize, etc.
- Program reuse: Multiple Stacks can reference the same ConfigMap
- Simpler maintenance: Operator doesn't need to track language-specific schemas
Implementation Approach
The implementation would follow a similar pattern to existing source types (GitSource, FluxSource, ProgramRef):
- Add
ConfigMapSourcefield to Stack spec alongside existing source options - In WorkspaceReconciler, detect ConfigMapSource and mount the ConfigMap as a volume
- Agent init container mounts ConfigMap contents as workspace directory
- Runtime detection happens automatically based on program files (Pulumi.yaml, package.json, go.mod, etc.)
This would be similar to how FluxSource currently works, but using ConfigMaps instead of HTTP artifact retrieval.
Related Issues
This feature would help address:
- Support full YAML resource option schema on
Programcustom resource #527 - Missing YAML schema options (reduces need for inline YAML) - Deal with pulumi-yaml deprecation of
configuration(in favour ofconfig) #404 - YAML deprecation maintenance burden
Use Cases
Python program with dependencies:
# Directory structure:
# my-program/
# Pulumi.yaml
# __main__.py
# requirements.txt
kubectl create configmap my-python-program --from-file=./my-program/TypeScript program:
# Directory structure:
# my-program/
# Pulumi.yaml
# index.ts
# package.json
# tsconfig.json
kubectl create configmap my-ts-program --from-file=./my-program/Go program:
# Directory structure:
# my-program/
# Pulumi.yaml
# main.go
# go.mod
# go.sum
kubectl create configmap my-go-program --from-file=./my-program/Affected area/feature
Pulumi Kubernetes Operator - Stack source resolution and Workspace initialization
Alternative Solutions
- Image Volumes - not yet practical
Metadata
Metadata
Assignees
Labels
area/program-resourceRelated to Program resourceRelated to Program resourcekind/enhancementImprovements or new featuresImprovements or new features