Skip to main content

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.

Component and Runtime Resources​

Components own the runtime resources that result from their deployment. When a component deploys, it generates Builds and produces Releases. These resources maintain a clear ownership chain back to the component, enabling lifecycle management and garbage collection.

This ownership relationship ensures that runtime resources are properly cleaned up when components are removed. It also provides clear attribution for resource usage, cost allocation, and audit trails. Platform operators can trace any running workload back to its originating component and project.

Class and Binding Relationships​

OpenChoreo implements the Kubernetes Class pattern that enables platform standardization while allowing application-specific customization. This system separates platform governance from developer flexibility through multiple layers of configuration.

Platform Classes​

Classes define platform-level abstractions that establish organizational standards. ServiceClass, WebApplicationClass, and ScheduledTaskClass provide platform capabilities for different workload types. These classes are created by platform engineers and encode organizational policies, security requirements, and operational best practices.

Classes serve as the platform's contract for how applications should be deployed. They define standard resource limits, security policies, network configurations, and operational parameters. By centralizing these definitions in classes, platform teams ensure consistency across all applications while maintaining a single point of control for platform-wide changes.

Binding Instantiation​

Bindings create concrete instances of classes for specific environments. A ServiceBinding references a ServiceClass but can override certain parameters for its target environment. This relationship allows the same class to be used across different environments with appropriate customization.

The binding relationship is not just a simple override mechanism. Bindings can only modify parameters that the class explicitly allows, ensuring that security policies and governance rules cannot be circumvented. This controlled flexibility enables environment-specific optimization while maintaining platform standards.

Component to Build​

Components define build specifications that result in Build resources. This relationship captures how source code should be transformed into container images. The component maintains the build configuration while builds represent individual execution instances.

Each build maintains a relationship back to its originating component and the specific commit or tag that triggered it. This relationship provides complete traceability from running containers back to source code, essential for debugging and compliance.

Workload and Binding Creation​

When developers create a Service, WebApplication, or ScheduledTask (the claim), along with a Workload specification, the platform creates the appropriate Binding. The Binding combines:

  • The claim (Service/WebApplication/ScheduledTask) that references a Class
  • The Workload that defines the runtime requirements
  • The Environment where it should be deployed

This relationship ensures that the platform standards from the Class are applied while respecting the application's runtime requirements from the Workload.

Binding to Release​

Bindings generate Releases that contain the actual Kubernetes resources to be deployed. The Release combines the Class configuration, Workload specifications, and environment-specific settings into concrete Kubernetes manifests that are applied to the target DataPlane.

This relationship chain from Component → Build → Claim+Workload → Binding → Release ensures complete traceability and proper lifecycle management throughout the application delivery process.

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 class triggers reconciliation of all bindings that reference it. 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 builds and deployments are cleaned up. These cascading relationships ensure that resources are properly cleaned up without leaving orphaned objects.