-
Epic
-
Resolution: Done
-
Normal
-
None
-
Cross-Cluster Dependency Resolution in Clowder
-
Product / Portfolio Work
-
False
-
-
False
-
Unset
-
Done
-
0% To Do, 0% In Progress, 100% Done
-
-
Goal
Enhance Clowder's capability by enabling it to resolve application dependencies available outside of the given cluster / ClowdEnvironment. This will allow Clowder to ingest and utilize information about external services in its service registry, facilitating transparent dependency wiring and simplifying service migration between clusters.
Non goals
- Performing any changes to network configuration, etc. to arrange connectivity with the remote service
- Providing security credentials for service to service authentication with the remote services
- Automatic synchronization of Clowder service registries across clusters/ClowdEnvironments. However, this epic will provide the mechanism upon which this advanced functionality could be built in the future
Acceptance criteria
- As an application developer, I use the same way of defining dependencies within the ClowdApp manifest for both in-cluster and outside-of-cluster dependencies.
- As an application, connection information for both in-cluster and remote services is provided to me from Clowder's service registry for the given ClowdEnvironment.
- As an application, the way the dependency information is provided to me remains the same (endpoints in cdappconfig.json) regardless of whether it is an in-cluster and outside-of-cluster dependency.
- As a ClowderEnvironment administrator, I have a mechanism to feed connection information for "remote" services into Clowder's service registry for the given environment. This mechanism could be a new CRD (e.g. ClowdAppReference) or reuse of the existing ClowdApp CRD in a way that does not deploy a new application but only provides the necessary connection information. The mechanism will be compatible with gitops, i.e. it will be possible to define these remote references via app-interface
- Compatibility with existing ClowdApp CRD usage for in-cluster application definitions is maintained.
- The dependency graph is validated regardless of whether services are in-cluster or remote.
Open questions
- What is the preferred mechanism for ingesting information about remote services (e.g., a new CRD, or an extension of the existing ClowdApp CRD)