Resource Relationships
OpenChoreo's resources form a carefully designed hierarchy that balances flexibility with governance. Understanding how these resources relate to each other is essential for designing applications, troubleshooting issues, and managing the platform effectively. These relationships define ownership, inheritance, and dependencies throughout the system.
Ownership Hierarchy​
The ownership model in OpenChoreo follows a strict hierarchical structure where each resource has a clear parent and defined scope. This hierarchy provides namespace isolation, access control boundaries, and lifecycle management.
Namespace-Scoped Resources​
OpenChoreo organizes most resources within Namespaces, which serve as containers for related platform and application resources. Namespace-scoped resources include DataPlanes, Environments, Projects, Components, and runtime resources generated by the platform. These resources are isolated within their namespace boundaries, leveraging Kubernetes RBAC and network policies to maintain security and access control.
OpenChoreo also supports cluster-scoped resources that exist at the cluster level. This hybrid model enables both namespace-level isolation for team-specific resources and cluster-wide sharing of common platform infrastructure.
Project Ownership​
Within a namespace, Projects form the next level of ownership for application resources. Projects own both Components and Resources, establishing team boundaries and application domains. This ownership relationship means that components and resources cannot exist without a parent project, and deleting a project removes all its components and resources.
The project ownership boundary also defines the scope for internal communication and resource sharing. Components within the same project can reference each other's endpoints directly and consume the project's Resources through Workload dependencies. This locality enables teams to work efficiently within their domain while maintaining isolation from other projects.
ComponentType​
ComponentTypes define platform-level templates that govern how components are deployed. Each ComponentType specifies a workload type (deployment, statefulset, cronjob, job, or proxy) and provides a schema for configurable parameters. Platform engineers create ComponentTypes that encode organizational policies, resource templates, and operational best practices.
ComponentTypes serve as the platform's contract for component deployment. They define what developers can configure through parameter schemas, what resources will be created through resource templates, and which workflows are allowed for building components. By centralizing these definitions in ComponentTypes, platform teams ensure consistency across all applications while maintaining control over infrastructure patterns.
Component to ComponentType​
Components reference a ComponentType using the format {workloadType}/{componentTypeName}. This relationship
establishes which template governs the component's deployment. The component provides parameter values that conform to
the schema defined in the ComponentType, and these parameters are validated automatically.
The component-to-ComponentType relationship is fundamental to OpenChoreo's governance model. Components cannot be created without referencing a valid ComponentType, ensuring all deployments follow platform standards. This relationship also determines which resource templates will be used to generate the actual Kubernetes resources.
Trait Composition​
Traits attach additional capabilities to components through composition. Each component can instantiate multiple traits, such as persistent storage, caching, or monitoring. Traits use the same schema-driven approach as ComponentTypes, with parameters that can be overridden per environment through ReleaseBinding resources.
Traits maintain an independent lifecycle from components but are applied together during deployment. This separation enables platform engineers to define reusable capabilities that can be composed into different component types. The trait relationship provides flexibility while maintaining governance through schema validation.
Workflow Integration​
Workflows define build and automation templates that components can reference through their workflow configuration. ComponentTypes can restrict which workflows are allowed, ensuring components use appropriate build strategies. This relationship between components, ComponentTypes, and Workflows enables platform teams to enforce build standards and security policies.
When a component references a Workflow, it provides schema values that configure the workflow execution. The Workflow template uses these values along with platform-controlled parameters to generate the actual CI/CD pipeline. This separation enables developers to trigger builds with simple configuration while platform engineers maintain control over build infrastructure and security.
Component to WorkflowRun​
Components trigger WorkflowRuns through their workflow configuration to build container images. Each WorkflowRun represents an execution instance of a Workflow template with specific parameter values. WorkflowRuns maintain a relationship back to their originating component and the specific commit that triggered them.
This relationship provides complete traceability from running containers back to source code. Platform operators can trace any container image to the WorkflowRun that built it, which links to the component and ultimately to the source repository and commit. This traceability is essential for debugging, compliance, and security auditing.
ComponentRelease and ReleaseBinding​
A ComponentRelease is an immutable snapshot of a component at a specific point in time. It captures the Component, its Workload configuration, the selected ComponentType, and any attached Traits into a single versioned resource. This snapshot works like a lock file—preserving the exact state so that the release remains stable and repeatable, even if the original resources are later updated.
To deploy a ComponentRelease to an environment, you create a ReleaseBinding. This resource binds the release to a specific environment and provides environment-specific overrides for ComponentType and Trait parameters. The ReleaseBinding controller renders the final Kubernetes manifests and produces a RenderedRelease resource that is applied to the target plane.
This relationship chain—Component → ComponentRelease → ReleaseBinding → RenderedRelease—ensures complete governance while enabling environment-specific customization. Because ComponentRelease is immutable, the same release can be promoted across environments (dev → staging → prod) without drift.
Resource and ResourceType​
ResourceTypes define platform-level templates for managed infrastructure—databases, caches, queues, object stores. Each ResourceType declares a parameter schema, the Kubernetes manifests the provisioner emits on the data plane, the named outputs that consumers bind to, and a default retention policy. The cluster-scoped variant ClusterResourceType is available across all namespaces.
Resources reference a ResourceType (or ClusterResourceType) by name. The Resource provides parameter values that conform to the referenced template's schema; validation failures surface on the Resource itself. The reference is fixed at create time, so a Resource cannot be retargeted to a different template after it is created.
The Resource-to-ResourceType relationship mirrors Component-to-ComponentType. Resources cannot be created without a valid ResourceType reference, ensuring every Resource is governed by a template the platform team has approved.
ResourceRelease and ResourceReleaseBinding​
A ResourceRelease is an immutable snapshot of a Resource and its referenced ResourceType at a specific point in time. When either input changes, a new ResourceRelease is cut; existing releases remain unchanged so the same snapshot can be promoted to multiple environments without re-rendering. This mirrors how ComponentRelease works for components.
To deploy a ResourceRelease to an environment, a platform engineer or GitOps process creates a ResourceReleaseBinding. The binding pins a specific ResourceRelease, targets an Environment, and provides per-environment configuration overrides. The captured ResourceType template is rendered with the combined configuration, producing a RenderedRelease that is applied to the target data plane, and the declared outputs are resolved so consuming workloads can read them.
The chain—Resource → ResourceRelease → ResourceReleaseBinding → RenderedRelease—is the resource-side parallel of the Component chain. The Resource controller never authors bindings on its own; promoting a release into an environment is always an explicit action by a platform engineer or GitOps tooling. This isolation keeps developer-facing Resource spec edits from triggering automatic redeploys against stateful infrastructure.
Network Relationships​
Network relationships in OpenChoreo define how components communicate and expose functionality. These relationships translate into concrete network policies, routing rules, and security configurations.
Endpoint Exposure​
Endpoints establish relationships between components and their network interfaces. A component can expose multiple endpoints with different visibility scopes and protocols. These relationships define how the component can be accessed and by whom.
The endpoint relationship includes more than just network configuration. It establishes contracts about protocols, expected behavior, and API compatibility. Other components can depend on these contracts, with the platform ensuring that communication follows the declared patterns.
Dependencies​
Dependencies create explicit relationships from a Component to the things it consumes. A Workload declares two kinds of dependency:
Endpoint dependencies (dependencies.endpoints[]) target endpoints exposed by other components. The platform
resolves the target address, injects it into the consuming container through environment variables, and configures
network policies for the resulting traffic.
Resource dependencies (dependencies.resources[]) target a Resource in the same project. The named outputs
declared by the referenced ResourceType—hostnames, ports, credentials, connection URLs—are bound to environment
variables or file mounts on the consuming container. Sensitive outputs are delivered through Kubernetes Secret
references; the underlying values never transit the control plane.
Both forms of dependency make the consuming relationships explicit. The platform uses them for service discovery, network policy generation, resource readiness gating, and to track which components depend on which endpoints and Resources.
Environment Progression​
Environment relationships define how applications move through the delivery pipeline from development to production. These relationships ensure consistent progression while maintaining appropriate governance.
Pipeline Definition​
DeploymentPipelines establish relationships between environments, defining allowed transitions and promotion rules. These relationships create a directed graph of environment progression, potentially with multiple paths for different scenarios.
Pipeline relationships include more than just ordering. They define testing gates and promotion rules. These relationships ensure that applications follow organizational processes while enabling automation where appropriate.
Lifecycle Dependencies​
Resource relationships in OpenChoreo include lifecycle dependencies that ensure proper initialization, updates, and cleanup.
Creation Order​
Some resources must be created before others can exist. DataPlanes must be registered before environments can target them. Projects must exist before components can be created within them. These relationships ensure that the platform maintains consistency during resource creation.
Update Propagation​
When resources are updated, changes propagate through relationships to dependent resources. Updating a ComponentType triggers reconciliation of all components that reference it, creating new ComponentReleases that capture the updated template. Since ComponentReleases are immutable snapshots, existing deployments are not affected until a new release is deployed.
Deletion Cascades​
Resource relationships define deletion behavior. When a project is deleted, all its components and Resources are removed. When a Component is deleted, its WorkflowRuns, ComponentReleases, ReleaseBindings, and RenderedReleases are cleaned up. When a Resource is deleted, deletion is blocked while any ResourceReleaseBinding still references it; once all bindings are gone, the owned ResourceReleases are removed. These cascading relationships ensure that resources are properly cleaned up without leaving orphaned objects.
The retention of the underlying data-plane state on a binding deletion is governed by the binding's retention policy. Production environments can preserve volumes and databases on deletion while dev and staging dispose of them, the same shape as Kubernetes PersistentVolume reclaim policy applied per binding.