Uploaded image for project: 'Service Binding'
  1. Service Binding
  2. APPSVC-1264

Register Primaza Clusters

    XMLWordPrintable

Details

    • Epic
    • Resolution: Unresolved
    • Undefined
    • Primaza 0.1
    • Primaza 0.1
    • Service Binding
    • None
    • Register Primaza Clusters
    • False
    • None
    • False
    • Not Selected
    • To Do
    • QE Needed, Docs Needed, TE Needed, Customer Facing, PX Needed
    • 90
    • 90% 90%

    Description

      Problem:

      We are implementing the Primaza Project. There is a need to register Clusters that can be used to discover services and manage claims for those services. See Primaza Architecture for details on cluster registration.

      Goal:

      To create a secured environment where Services running in different clusters can be consumed by applications running in different clusters. Primaza will serve as the orchestration platform to perform that. The scope of this epic is for Primaza MVP (v0.1)

      Why is it important?

      This will enable application clusters managed by developers to be abstracted away from the details about how services are provisioned and managed. They will only have visibility to claimable service catalog and to manage claims for those services. Security is important here. Primaza is acting as an orchestrator and will only be able to do what clusters administrators allow Primaza to do on those registered clusters.

      Use cases

      • As a Primaza Administrator, I would like to register a cluster environment so that I can automatically discover services running in target cluster's service-namespaces
      • As a Primaza Administrator, I would like to register a cluster environment so that I can claim registered services targeting a specific workload in one of the target cluster's application-namespaces
      • As a Primaza administrator, I would like to know when my Primaza clusters are healthy, so that I can be proactive debugging issues with discovery and claims.
      • As a Primaza administrator, I would like to have clear documentation about the different Primaza access control recommendations so that I can show my business leadership team Primaza has no need for super admin access.

      Demo requirements

      A good demo will show at least three clusters environments one application only, one service only and one that is both. The one that serve as both application and service could be the clusters where primaza is running.

      UI requirements

      The UI for Primaza will be used for demo and marketing purposes only during MVP. For GA the UI will depend on what OpenShift or StoneSoup tools we integrate with.

      Acceptance criteria

      • Development:
        Can register clusters environments and corresponding namespaces
        Can track status of a cluster (health and logs)
        Can update cluster environments
        Can delete clusters environments
        Can setup agents in clusters environments namespaces to improve scalability
        Can Track cluster environment metrics for the OpenShift Fleet
      • QE:
        Github flow set up to execute behave test harness
        Cluster Environment Registration Tests are implemented and run on PR updates
      • Documentation:
        All Registration Options are documented in our primaza github project
      • UI:
        There is a UI that can facilitate the lifecycle of register cluster resources

      Dependencies (External/Internal)

      TBD

      Design Artifacts

      Primaza Architecture

      Exploration

      Note

      Attachments

        Activity

          People

            Unassigned Unassigned
            dperaza@redhat.com David Peraza
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: