XMLWordPrintable

    • BU Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • 0% To Do, 0% In Progress, 100% Done
    • M
    • 0
    • Program Call

      Feature Overview (aka. Goal Summary)  

      Due to historical reasons, the etcd operator uses a static definition of an 8GB limit. Nowadays, customers with dense cluster configurations regularly reach the limit. OpenShift should provide a mechanism for increasing the database size while maintaining a validated configuration.

      Goals (aka. expected user outcomes)

      This feature aims to provide validated selectable sizes for the etcd database, allowing cluster admins to opt-in for larger sizes.

       

      Requirements (aka. Acceptance Criteria):

      Since using larger etcd database sizes may impact the defragmentation process, causing more noticeable transaction "pauses", this should be an opt-in configuration.

       

      Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both Yes
      Classic (standalone cluster) Yes
      Hosted control planes No
      Multi node, Compact (three node), or Single node (SNO), or all Yes
      Connected / Restricted Network Yes
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) Yes
      Operator compatibility N/A
      Backport needed (list applicable versions) N/A
      UI need (e.g. OpenShift Console, dynamic plugin, OCM) No
      Other (please specify) N/A

      Use Cases (Optional):

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

      <your text here>

      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.

      <your text here>

      Out of Scope

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

      <your text here>

      Background

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

      <your text here>

      Customer Considerations

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

      <your text here>

      Documentation Considerations

      Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

      <your text here>

      Interoperability Considerations

      Which other projects, including ROSA/OSD/ARO, 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.

      <your text here>

              wcabanba@redhat.com William Caban
              wcabanba@redhat.com William Caban
              Dean West, Haseeb Tariq
              Mustafa Elbehery Mustafa Elbehery
              Wei Sun Wei Sun
              Matthew Werner Matthew Werner
              Maciej Szulik Maciej Szulik (Inactive)
              William Caban William Caban
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: