-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
ACM 2.13.0
-
None
-
Product / Portfolio Work
-
False
-
-
False
-
Not Selected
Feature Overview
ACM is based on hub-spoke architecture with one ACM instance managing multiple clusters. With the increasing capacity of the hardware resources where ACM is deployed, various components of ACM can be pushed to manage more spoke clusters.
The challenging part in this case is ACM being a single point of failure with some customers not being able to backup the active ACM instance due to the lack of funds to invest in an external S3 compatible storage.y One of the workarounds used in the Telco Management Clusters is to deploy two different clusters with one of them hosting the primary active ACM and the other hosting a secondary - dormant - ACM. The secondary dormant cluster will expose its S3 storage backed by ODF - Open Data Foundations - and shall a disaster occurs within the primary cluster the secondary ACM will start a restore process based on the locally hosted latest backup dumped by the primary ACM.
This is also suboptimal as it requires a hefty investment securing nodes for a secondary cluster sitting there just to backup the primary ACM.
With the current Klusterlet design, if a managed/spoke cluster is imported to a secondary ACM there will be a conflict as the first klusterlet object pushed by the primary ACM has cluster-wide visibility and also runs in the same default namespaces.
The suggestion here is to provide support to connect a spoke cluster to an active and standby ACMs by following the same idea already implemented with MCE when importing MCE cluster managing a set of clusters to another remote ACM instance [1]. This could be done by switching klusterlet to be namespaced with the option for the administrator to choose the namespace to deploy each klusterlet.
Goals
This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature
- …
Requirements
This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.
| Requirement | Notes | isMvp? |
|---|---|---|
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. |
YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. |
YES |
(Optional) Use Cases
This Section:
- Main success scenarios - high-level user stories
- Alternate flow/scenarios - high-level user stories
- ...
Questions to answer
- ...
Out of Scope
- …
Background, and strategic fit
This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?
Assumptions
- ...
Customer Considerations
- ...
Documentation Considerations
Questions to be addressed:
- What educational or reference material (docs) is required to support this
product feature? For users/admins? Other functions (security officers, etc)? - Does this feature have a doc impact?
- New Content, Updates to existing content, Release Note, or No Doc Impact
- If unsure and no Technical Writer is available, please contact Content
Strategy. - What concepts do customers need to understand to be successful in
[action]? - How do we expect customers will use the feature? For what purpose(s)?
- What reference material might a customer want/need to complete [action]?
- Is there source material that can be used as reference for the Technical
Writer in writing the content? If yes, please link if available. - What is the doc impact (New Content, Updates to existing content, or
Release Note)?