-
Feature
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
Future Sustainability
-
8
-
False
-
-
False
-
Not Selected
-
100% To Do, 0% In Progress, 0% Done
Feature Overview
Implement tunnel/proxy feature(what cluster-proxy-addon does currently) in the ocm core repo.
Goals
This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature
The proxy feature will be part of the core feature controlled by feature gate. It will be called “ocm proxy” in the following content. The cluster-proxy addon will be deprecated. The ANP dependency will be removed.
Phase 0 (ACM 2.15): https://issues.redhat.com/browse/ACM-22437
- Research & Prototype: Investigate design options and build an initial prototype of “ocm proxy.”
- Limitations: Prototype may omit high-availability setups, end-to-end tests, and full unit-test coverage.
Phase 1 (ACM 2.16 & ocm.io 1.2)
- Add this feature in the upstream community behind a feature gate. It will be used by ClusterInventory and MultiQueue.
- Mark the upstream cluster-proxy repository as archived.
- Write a release note and a feature-description document.
- No new features will be released downstream in this phase.
Phase 2 (ACM 2.17)
- Enable ocm proxy by default in ACM.
- Update the related configuration and manifests.
- Ensure the proxy’s agent and server can establish a tunnel connection.
Phase 3 (ACM 2.18)
- Based on feedback from phases 2.16 and 2.17, fix any issues MultiQueue and ClusterInventory have when using ocm proxy.
- Add new tests and performance tests to improve reliability and stability. We expect that by the start of 2.18, data and real-world use cases will show that ocm proxy is stable.
- Replace the old cluster-proxy with ocm proxy in a fully API-compatible way. The three components that use cluster-proxy today (multicloud-foundation, search/console, and virt) should see no change after the upgrade.
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)?