-
Feature
-
Resolution: Done
-
Normal
-
None
-
BU Product Work
-
False
-
-
False
-
0% To Do, 0% In Progress, 100% Done
-
M
-
0
-
Program Call
-
-
-
Marked for TE as CEE may need to be aware of this capability (but little probably needs to be shown / shared about it).
-
-
-
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>
- blocks
-
OCPSTRAT-319 [internal] Explore options for hitless automatic defrag of etcd
- In Progress
- depends on
-
ETCD-514 Enhancement for selectable database size limits
- Closed
- is depended on by
-
OCPSTRAT-1283 [GA] Selectable etcd database size
- Backlog
- is incorporated by
-
ETCD-513 [TechPreview] Selectable etcd database size
- Closed
- links to