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.

Organization as Root

At the top of the hierarchy, the Organization serves as the root container for all resources. Every resource in OpenChoreo ultimately belongs to an organization, establishing the fundamental tenant boundary in multi-tenant deployments. Organizations own platform resources like DataPlanes and Environments, application resources like Projects and Components, and runtime resources generated by the platform.

This ownership model ensures complete isolation between different organizations. Resources from one organization cannot reference or interact with resources from another organization. This isolation extends to the runtime level, where different organizations' workloads run in separate namespaces with distinct security boundaries.

Project Ownership

Within an organization, Projects form the next level of ownership for application resources. Projects own Components, establishing team boundaries and application domains. This ownership relationship means that components cannot exist without a parent project, and deleting a project removes all its components.

The project ownership boundary also defines the scope for internal communication. Components within the same project can reference each other directly and communicate without crossing security boundaries. 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, or job) 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 ComponentDeployment 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.

ComponentDeployment and Release

When a component deploys to an environment, it creates ComponentDeployment resources that can override parameters from the ComponentType on a per-environment basis. These deployments generate Releases that contain the final Kubernetes manifests rendered from ComponentType templates combined with component parameters, trait configurations, and environment overrides.

This relationship chain from Component → ComponentType → ComponentDeployment → Release ensures complete governance while enabling environment-specific customization. The Release combines all these layers into concrete Kubernetes resources that are applied to the target DataPlane.

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.

Connection Dependencies

Connections create explicit relationships between components and their dependencies. When a component declares a connection to another service, it establishes a formal dependency that the platform can track, secure, and monitor.

Connection relationships make dependencies between components explicit. This relationship model helps teams understand their application architecture and service dependencies.

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 approval requirements and testing gates. 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, regenerating their deployments and releases with the new template. These relationships ensure that changes are consistently applied throughout the system.

Deletion Cascades

Resource relationships define deletion behavior. When a project is deleted, all its components are removed. When a component is deleted, its WorkflowRuns, ComponentDeployments, and Releases are cleaned up. These cascading relationships ensure that resources are properly cleaned up without leaving orphaned objects.