Uploaded image for project: 'Container / Cluster Management (XCM) Strategy'
  1. Container / Cluster Management (XCM) Strategy
  2. XCMSTRAT-534

Create ARO HCP Clusters in Cluster Service

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Done
    • Icon: Critical Critical
    • CY24M07
    • None
    • ARO HyperShift
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • XCMSTRAT-491ARO HCP (P1) - Integrated Development (Renamed from Internal MVP)
    • 0% To Do, 0% In Progress, 100% Done
    • No
    • 0

      Unknowns

      • How are the OCP MI(s) passed to CS?
      • Are we going to use 1 or more MSI MIs?
      • Confirm that we are going to be passed the Managed Resource Group name always from the RP, and how will the RP deal with it too before: will it always receive from the user or will it be optional from the ARM Azure API point of view and the RP will generate some name for it?
      • What will be the `name` value that we will set for an OCM cluster? we cannot use the `azure resource name` value because they have different set of accepted characters and name length. Will the RP autogenerate some name? ensure no collisions. This ends up affecting name of cloud resources and such created from CS/hypershift, as well as k8s resources in management clusters and so on
      • Do we need to store all creation time attributes or only some of them? if so, which ones?
      • How will the networking part be configured during creation?
      • Are we missing attributes when comparing with the ARM REST API definition?
      • How will ARO Classic clusters be dealt with when the `azure` map exists?
      • What set of regions are we going to support?
      • What set of instance types are we going to support? are they going to be at ARO-HCP global level, or different per region?
      • Does CS currently support instance types per cloud provider? and per region?
      • Are we going to enable only one region per each CS regional deployment, or will all desired regions be enabled in all CS regional deployments and we will trust that the RP uses CS correctly? if we want to have separate per CS regional deployment how would that be done? DB migrations are shared
      • Are we going to enable specific instance types per region? or will all regions have the same supported instance types? if we want to have them separate per CS regional deployment how would that be done? migrations are shared right now
      • Are we going to share DB migrations between regional CS deployments? and between ARO-HCP and non-ARO HCP offering? right now it is shared unless changes are made
      • How are we going to deal with encryption related attributes? (disk level needed? etcd level needed?)
      • Are we going to allow enable/disable etcd encryption at will? or are we always going to have it as enabled? currently in ROSA HCP it is always enabled. We should clarify this and adjust the Azure API correspondingly
      • How will the database schema organization look like? some of the unknowns will alter this
      • How long will DDR discussion, review and approval process take?

      Estimation: 13 weeks

      Feature Overview (aka. Goal Summary)  

      An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

       

      Goals (aka. expected user outcomes)

      The observable functionality that the user now has as a result of receiving this feature. Complete during New status.

       

      Requirements (aka. Acceptance Criteria):

      A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

       

      Use Cases (Optional):

      Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

       

      Questions to Answer (Optional):

      Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

       

      Out of Scope

      High-level list of items that are out of scope.  Initial completion during Refinement status.

       

      Background

      Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

       

      Customer Considerations

      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

       

      Documentation Considerations

      Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

       

      Interoperability Considerations

      Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

            msorianod Miguel Soriano
            zgalor Zohar Galor
            Mike Gahagan Mike Gahagan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 13 weeks
                13w
                Remaining:
                Remaining Estimate - 13 weeks
                13w
                Logged:
                Time Spent - Not Specified
                Not Specified