Uploaded image for project: 'OpenShift Builds'
  1. OpenShift Builds
  2. BUILD-571

Necessary cluster storage operator change to deploy shared resource operator on hypershift guest cluster

XMLWordPrintable

      Story (Required)

      1. As a developer, I want to consume shared Secrets and ConfigMaps in my workloads so that I can have access to shared credentials and configuration from a GA OCP install even on hypershift
      2. As a cluster admin, I want the Insights operator to automatically create a SharedSecret for my cluster's simple content access certificate from a GA OCP install even on hypershift
      3. As a cluster admin/SRE, I want OpenShift to use SharedConfigMaps to distribute cluster certificate authorities so that data is not duplicated in ConfigMaps across my cluster from a GA OCP install even on hypershift

      <Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer’s experience?>

      Background (Required)

      https://github.com/openshift/csi-driver-shared-resource-operator/pull/71

      https://github.com/openshift/cluster-storage-operator/pull/342

      https://github.com/openshift/origin/pull/27730

      https://github.com/openshift/release/pull/36433

      https://github.com/openshift/cluster-storage-operator/pull/343

      https://github.com/openshift/openshift-controller-manager/pull/251

      https://redhat-internal.slack.com/archives/C01C8502FMM/p1676472369732279

      Currently, looks like we need to merge the driver changes first (they have proven to be benign in non-hypershift) so that we can complete testing in the cluster-storage-operator PR

      <Describes the context or background related to this story>

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      <Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

      Acceptance Criteria (Mandatory)

      <Describe edge cases to consider when implementing the story and defining tests>

      <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

              gmontero@redhat.com Gabe Montero
              gmontero@redhat.com Gabe Montero
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: