Uploaded image for project: 'Hybrid Cloud Console'
  1. Hybrid Cloud Console
  2. RHCLOUD-40208

Cross-Cluster Dependency Resolution in Clowder

XMLWordPrintable

    • Cross-Cluster Dependency Resolution in Clowder
    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • 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)

              mknop-console-dot Matt Knop
              rhn-engineering-jharting Jozef Hartinger
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: