[
https://issues.apache.org/jira/browse/AMBARI-26634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialiang Cai updated AMBARI-26634:
----------------------------------
Description:
<!---
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
h2. Suggested Summary
Advance React parity for the remaining HA, Views, authorization, Service
Theme, and audit modules
h2. Problem
The React frontend does not yet have an accepted parity result for the final
five functional modules in the Classic Ember baseline. The remaining work is
tightly coupled: ResourceManager and Ranger Admin HA, Federation and HAWQ,
Views, global authorization, and Service Theme configuration layouts share
route guards, upgrade and wizard exclusions, configuration identity, persisted
workflow ownership, long-running request recovery, and application-shell
behavior. Reviewing or landing these areas independently can leave
contradictory permissions, recovery semantics, or matrix evidence.
This issue covers Modules 10 through 16 as one coherent non-Metrics delivery.
It includes the 581 stable feature IDs in Modules 10 through 14, generation and
validation of the canonical 1,154-ID React parity matrix, and the final
five-pass reverse audit. A matching route, component name, or REST endpoint is
not sufficient evidence of parity.
h2. Scope
* Complete ResourceManager HA and Ranger Admin HA entry guards, topology and
host validation, Stack Advisor integration, KDC boundaries, generated
configuration, ordered stop/install/save/start/test operations, persisted
request checkpoints, Retry behavior, refresh recovery, and workflow-owner
cleanup, while explicitly recording the pre-request-ID unknown-outcome
boundary that requires server reconciliation or idempotency support.
* Complete NameNode Federation, Router-based Federation, and historical HAWQ
Standby Add/Remove/Activate workflows, including stack metadata and topology
gates, secure-cluster branches, exact configuration transformations, custom
commands, ordered operations, failure handling, and durable recovery.
* Complete ordinary and View-only Views shell behavior, two-phase View
discovery, server-authorized instance filtering, regular and short routes,
encoded paths and query strings, iframe loading and recovery, browser
navigation, and Admin View version/proxy-root redirection.
* Align global permission expressions, upgrade exceptions, wizard-owner
mutation exclusions, read-versus-mutate checks, Admin routes, User Settings,
Experimental settings, restart-required operations, support flags, stack
metadata, service/component topology, Windows gates, and transition-state
locks with the executable Classic rules.
* Implement the Service Theme extension contract across Service Configs, Host
Configs, configuration comparison, and installation/Add Service Step 7,
including layout-qualified identity, ordered geometry, Widgets, conditions,
canonical saves, read-only modes, secret-safe diagnostics, fallback, Retry,
stale-response rejection, and custom stack/service Theme fixtures.
* Resolve every remaining static gap or record an explicit, reviewable
compatibility decision. Known gaps must not be hidden by a general parity
claim.
* Generate JSON, CSV, and Markdown representations of the canonical React
parity matrix from all 14 module comparison documents. Preserve all 1,154
stable IDs, source evidence, issue references, review metadata, and the
reproducible reviewed-source digest.
* Perform five independent reverse-audit passes over routes and entry points;
mutations, payloads, and request ordering; permissions, flags, topology,
upgrades, and wizard ownership; asynchronous failure, Retry, persistence,
refresh, and cleanup; and tests, exclusions, and evidence consistency.
* Add focused tests for normal, denied, failed, retried, refreshed, and
cross-owner paths, and retain explicit real-cluster scenarios for behavior
that static tests cannot prove.
h2. Classic UI Baseline
The acceptance baseline is the executable Classic Ember source together with
these reviewed documents:
* {{docs/frontend-refactor/ember-baseline/10-rm-ranger-ha.md}}: 107 feature IDs.
* {{docs/frontend-refactor/ember-baseline/11-federation-hawq.md}}: 194 feature
IDs.
* {{docs/frontend-refactor/ember-baseline/12-views.md}}: 92 feature IDs.
* {{docs/frontend-refactor/ember-baseline/13-permissions-flags.md}}: 36 feature
IDs.
* {{docs/frontend-refactor/ember-baseline/14-service-theme-layout.md}}: 152
feature IDs.
* {{docs/frontend-refactor/ember-baseline/15-react-gap-matrix.md}}: matrix
schema,
status rules, evidence requirements, and review gates.
* {{docs/frontend-refactor/ember-baseline/16-five-pass-audit.md}}: independent
reverse-audit method and frozen baseline conclusions.
The corresponding React comparison documents under
{{docs/frontend-refactor/react-current}} must remain synchronized with the code.
When a baseline statement conflicts with Classic source or verified runtime
behavior, the baseline must be corrected with source evidence instead of
changing React to match an unsupported statement.
h2. Acceptance Criteria
* All 581 Module 10 through 14 feature IDs appear exactly once in their final
React comparison tables with a supported status and concrete evidence.
* ResourceManager and Ranger Admin HA enforce menu and direct-route conditions,
generate the documented configuration, serialize every mutation, retain
recoverable request state, stop after a failed prerequisite, and avoid
replay after local or server-confirmed failures. The issue must not claim
exactly-once recovery when a mutation response is lost before its request ID
is persisted.
* NameNode Federation executes its complete ordered workflow; Router Federation
creates or updates its configuration and manages Router components safely;
HAWQ Add, Remove, and Activate retain their distinct stack, topology,
permission, and custom-command contracts.
* Every HA workflow persists the owner, step, inputs, operation state, returned
request IDs, and terminal results before advancing. Refresh resumes completed
work or active work with a saved request ID, another user cannot take
ownership, and cleanup failures remain visible and retryable. A recovered
{{QUEUED}} mutation without an ID remains {{PARTIAL}} until a server protocol
can
reconcile whether the earlier request was accepted.
* Views discovery preserves the two-request contract and distinguishes empty,
hidden, system, unauthorized, malformed, and failed responses. Regular and
short routes preserve encoded application paths and query strings without
treating client visibility as authorization.
* View-only initialization avoids cluster-only operations while preserving the
documented shell and session lifecycle. Admin View navigation uses the
server-reported version contract and configured proxy root and provides a
deterministic failure path.
* Permission expressions preserve comma-separated OR semantics and the
whole-expression upgrade exceptions. Visibility checks remain distinct from
owner-aware mutation checks, and direct routes repeat the applicable action
gates.
* Support flags and runtime gates have an executable consumer, an explicit
{{MISSING}} or {{PARTIAL}} result, or a documented {{NOT_APPLICABLE}}
compatibility
decision. No flag is considered migrated only because it is loaded.
* Service Theme preserves full config paths and parent-qualified layout
identity, declaration order, every supported Widget round trip, layered
conditions and attributes, canonical save exclusion for UI-only properties,
password secrecy, read-only consumers, fallback, Retry, and stale-response
isolation across all four consumers.
* Reverse API review accounts for every reachable mutation, including HTTP
method, URL, predicates, fields, headers, body shape, operation level,
ordering, response branches, polling or realtime behavior, and error
recovery.
* The generated matrix contains exactly the canonical 1,154 stable IDs and its
JSON, CSV, and Markdown representations are synchronized. The 581 IDs above
are only this issue's functional-module subset. Metrics exclusions and legacy
placeholders remain in the full generated outputs without entering the
completion denominator.
* Source statuses {{COVERED}}, {{MATCH}}, {{PASS}}, and {{STATIC_COMPLETE}}
that are
supported only by static evidence normalize to {{NEEDS_RUNTIME_VALIDATION}}.
Explicit gap and decision statuses remain unchanged. Final {{COVERED}} is used
only after an acceptance review records independent normal-path and
failure/recovery runtime evidence.
* Every {{MISSING}}, {{PARTIAL}}, {{BLOCKED}}, {{BEHAVIOR_DIFF}}, and
{{NOT_APPLICABLE}} row has this issue, a follow-up issue, or an explicit
maintainer decision with a reason.
* The baseline validator, parity-matrix tests and validator, complete Feature
ID reverse checks, focused Vitest suites, TypeScript build, production build,
applicable lint checks, and {{git diff --check}} pass, or unrelated
pre-existing
failures are reported precisely.
* A second reviewer independently checks all eventual {{COVERED}} and
{{NOT_APPLICABLE}} rows and confirms that the five audit passes found no
unassociated non-Metrics route, action, mutation, permission, flag, recovery
path, or test boundary.
h2. Required Runtime Validation
Static source review, mocks, and unit/component tests cannot close the
following acceptance boundary:
| Area | Minimum real-environment scenarios |
| --- | --- |
| ResourceManager HA | Secure and non-secure clusters; valid and invalid
RM/ZooKeeper/host topology; Stack Advisor changes; optional HAWQ/HDFS
configuration; KDC cancellation/failure; failed requests; refresh and
cross-user recovery |
| Ranger Admin HA | Eligible and ineligible topology; {{http}}, {{https}}, and
{{ftp}} load-balancer values; Kerberos providers; configuration save and
service-check failure; interrupted requests; external load-balancer
verification |
| NameNode Federation | Secure and non-secure clusters; optional Ranger,
Accumulo, and Infra Solr branches; all ordered operations; format/bootstrap
failure; Retry; reload and non-owner access |
| Router Federation | Stack metadata with and without DFSRouter support;
existing and new {{hdfs-rbf-site}}; zero and multiple topology inputs;
install/start/maintenance failure; Retry and reload |
| HAWQ Standby | A compatible historical stack; Add, Remove, and Activate; each
permission combination and custom-command gate; request failure, retry,
refresh, and owner recovery |
| Views | Cluster user, View-only user, Ambari administrator, and unauthorized
user; hidden/system/multiple-version instances; short URLs and proxy roots;
cold and warm valid, invalid, deleted, and malformed-percent-encoded deep
links; path/query preservation; iframe load, resize, host scrolling, activity,
popup, download, and fullscreen behavior; interval cleanup; partial
initialization; session expiry; logout failure; keep-alive start, duplicate
prevention, and stop; Admin View redirect failure |
| KDC and credentials | Manual, MIT, Active Directory, and IPA modes; temporary
and persisted credentials; cancellation, expiry, lookup and save failure,
Retry, and resulting principal/keytab ownership across each applicable HA or
Federation workflow |
| Global gates | Read-only, service operator, cluster administrator, Ambari
administrator, and View-only roles while idle, during supported and blocking
upgrades, and with the same or another wizard owner |
| Service Theme | Real shipped and custom service Themes; duplicate local
names; malformed metadata; every Widget and condition; Service, Host,
comparison, Install, and Add Service consumers; read-only roles; secret-bearing
failures; Retry, service switching, refresh, save/reload, and stale responses |
| Fault injection | Network loss and server errors before and after every
irreversible mutation, failed persistence, stale polling responses, browser
refresh, tab close, and a second session attempting the active workflow |
Runtime outcomes must be recorded per matrix row or linked scenario. A single
happy-path demonstration does not establish operational parity for a long HA
workflow.
h2. Out of Scope
* Ambari Metrics pages, charts, widgets, Heatmaps, Horizon Charts, Metrics data
APIs, and Metrics-specific realtime destinations.
* Business functionality implemented inside separately deployed View
applications. This issue covers only the Ambari shell's discovery, routing,
hosting, authorization boundary, and browser navigation.
* Reimplementation of the AngularJS Admin Console CRUD pages. Only discovery
and navigation into the existing Admin View are included.
* Backend authorization or service-command implementation changes unless a
verified frontend contract defect requires a separately reviewed fix.
* Classic placeholder, unreachable, or verified broken behavior that has an
explicit compatibility decision, including unsupported HA disable or
rollback paths.
* Metrics-related permissions and support flags. Operational CPU, memory, disk,
topology, formatted-state, and request-progress fields remain in scope when
they are direct inputs to a non-Metrics workflow.
h2. Compatibility Decisions
React may deliberately improve verified unsafe or broken Classic behavior by
failing closed on incomplete data, waiting for prerequisite requests, guarding
direct routes, avoiding replay after confirmed failures, escaping untrusted
output, and retaining recoverable workflow state. Each difference must identify
the
Classic behavior, React behavior, user impact, and maintainer decision in the
module document and parity matrix. Reliability improvements are not evidence
that unrelated Classic branches can be omitted.
h2. Verification Boundary
The code portion of this issue can be considered ready after the focused tests,
TypeScript and production builds, validators, matrix generation, reverse
checks, and five-pass audit succeed. Operational parity remains
{{NEEDS_RUNTIME_VALIDATION}} until the required real-cluster matrix has been run
and independently reviewed. The pull request must report static test results
and pending runtime scenarios separately and must not claim that unexecuted
cluster, KDC, historical-stack, proxy, iframe, role, upgrade, or fault-injection
scenarios passed.
h2. Implemented in PR 4180
PR: [apache/ambari#4180|https://github.com/apache/ambari/pull/4180]
The branch contains twelve topic-specific commits intended to keep review
boundaries clear:
* {{b8e34c97df}} stabilizes Host detail initialization.
* {{02b869e936}} fixes Add Host cancellation navigation and cleanup recovery.
* {{e35a4d6b4d}} installs Ranger plugins only when enabled.
* {{cc33dd4774}} packages the credential shell configuration dependency.
* {{2e7470dfd2}} fixes Service Theme layout and metadata diagnostics.
* {{6a2070f046}} migrates the HDFS Files View to React.
* {{2f343f1798}} migrates the YARN Capacity Scheduler View to React.
* {{f24fd0c4bf}} records hosted View React parity evidence.
* {{10ab42455d}} packages supported contrib Views in default builds.
* {{cb050006f8}} removes the obsolete Pig View.
* {{0a8032c1e5}} removes the unsupported Oozie Workflow Manager View.
* {{edb11bb400}} keeps Admin View and hosted View navigation in React.
The final navigation change removes accidental fallbacks to Classic from Admin
View instance, short URL, Dashboard, installer, Stack Versions, authentication,
logout, and inactivity-timeout flows. Dynamic View route segments are encoded,
reverse-proxy application prefixes are retained, and the explicit Switch to
classic UI command remains available. The Files and Capacity Scheduler Views
also retain proxy prefixes for API and download URLs.
h3. Verification recorded by the pull request
* The main React frontend passed 188 test files and 991 tests and completed its
production build.
* The Files View passed 3 test files and 12 tests and completed its production
build.
* The Capacity Scheduler View passed 3 test files and 16 tests and completed
its production build.
* The Admin navigation helper passed 3 focused tests and the Admin
TypeScript/Vite production build completed.
* Updated Admin, Files, and Capacity Scheduler assets were deployed to the
local three-node cluster and manually verified by the maintainer.
* The full Admin run completed 121 existing tests before 10 suites hit the
pre-existing {{history}} dependency-manifest mismatch.
* Admin lint remains blocked by the pre-existing ESLint flat-config/package
mismatch; this is reported in the PR and is not presented as passing.
was:
<!---
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
h2. Suggested Summary
Advance React parity for the remaining HA, Views, authorization, Service
Theme, and audit modules
h2. Problem
The React frontend does not yet have an accepted parity result for the final
five functional modules in the Classic Ember baseline. The remaining work is
tightly coupled: ResourceManager and Ranger Admin HA, Federation and HAWQ,
Views, global authorization, and Service Theme configuration layouts share
route guards, upgrade and wizard exclusions, configuration identity, persisted
workflow ownership, long-running request recovery, and application-shell
behavior. Reviewing or landing these areas independently can leave
contradictory permissions, recovery semantics, or matrix evidence.
This issue covers Modules 10 through 16 as one coherent non-Metrics delivery.
It includes the 581 stable feature IDs in Modules 10 through 14, generation and
validation of the canonical 1,154-ID React parity matrix, and the final
five-pass reverse audit. A matching route, component name, or REST endpoint is
not sufficient evidence of parity.
h2. Scope
* Complete ResourceManager HA and Ranger Admin HA entry guards, topology and
host validation, Stack Advisor integration, KDC boundaries, generated
configuration, ordered stop/install/save/start/test operations, persisted
request checkpoints, Retry behavior, refresh recovery, and workflow-owner
cleanup, while explicitly recording the pre-request-ID unknown-outcome
boundary that requires server reconciliation or idempotency support.
* Complete NameNode Federation, Router-based Federation, and historical HAWQ
Standby Add/Remove/Activate workflows, including stack metadata and topology
gates, secure-cluster branches, exact configuration transformations, custom
commands, ordered operations, failure handling, and durable recovery.
* Complete ordinary and View-only Views shell behavior, two-phase View
discovery, server-authorized instance filtering, regular and short routes,
encoded paths and query strings, iframe loading and recovery, browser
navigation, and Admin View version/proxy-root redirection.
* Align global permission expressions, upgrade exceptions, wizard-owner
mutation exclusions, read-versus-mutate checks, Admin routes, User Settings,
Experimental settings, restart-required operations, support flags, stack
metadata, service/component topology, Windows gates, and transition-state
locks with the executable Classic rules.
* Implement the Service Theme extension contract across Service Configs, Host
Configs, configuration comparison, and installation/Add Service Step 7,
including layout-qualified identity, ordered geometry, Widgets, conditions,
canonical saves, read-only modes, secret-safe diagnostics, fallback, Retry,
stale-response rejection, and custom stack/service Theme fixtures.
* Resolve every remaining static gap or record an explicit, reviewable
compatibility decision. Known gaps must not be hidden by a general parity
claim.
* Generate JSON, CSV, and Markdown representations of the canonical React
parity matrix from all 14 module comparison documents. Preserve all 1,154
stable IDs, source evidence, issue references, review metadata, and the
reproducible reviewed-source digest.
* Perform five independent reverse-audit passes over routes and entry points;
mutations, payloads, and request ordering; permissions, flags, topology,
upgrades, and wizard ownership; asynchronous failure, Retry, persistence,
refresh, and cleanup; and tests, exclusions, and evidence consistency.
* Add focused tests for normal, denied, failed, retried, refreshed, and
cross-owner paths, and retain explicit real-cluster scenarios for behavior
that static tests cannot prove.
h2. Classic UI Baseline
The acceptance baseline is the executable Classic Ember source together with
these reviewed documents:
* {{docs/frontend-refactor/ember-baseline/10-rm-ranger-ha.md}}: 107 feature IDs.
* {{docs/frontend-refactor/ember-baseline/11-federation-hawq.md}}: 194 feature
IDs.
* {{docs/frontend-refactor/ember-baseline/12-views.md}}: 92 feature IDs.
* {{docs/frontend-refactor/ember-baseline/13-permissions-flags.md}}: 36 feature
IDs.
* {{docs/frontend-refactor/ember-baseline/14-service-theme-layout.md}}: 152
feature IDs.
* {{docs/frontend-refactor/ember-baseline/15-react-gap-matrix.md}}: matrix
schema,
status rules, evidence requirements, and review gates.
* {{docs/frontend-refactor/ember-baseline/16-five-pass-audit.md}}: independent
reverse-audit method and frozen baseline conclusions.
The corresponding React comparison documents under
{{docs/frontend-refactor/react-current}} must remain synchronized with the code.
When a baseline statement conflicts with Classic source or verified runtime
behavior, the baseline must be corrected with source evidence instead of
changing React to match an unsupported statement.
h2. Acceptance Criteria
* All 581 Module 10 through 14 feature IDs appear exactly once in their final
React comparison tables with a supported status and concrete evidence.
* ResourceManager and Ranger Admin HA enforce menu and direct-route conditions,
generate the documented configuration, serialize every mutation, retain
recoverable request state, stop after a failed prerequisite, and avoid
replay after local or server-confirmed failures. The issue must not claim
exactly-once recovery when a mutation response is lost before its request ID
is persisted.
* NameNode Federation executes its complete ordered workflow; Router Federation
creates or updates its configuration and manages Router components safely;
HAWQ Add, Remove, and Activate retain their distinct stack, topology,
permission, and custom-command contracts.
* Every HA workflow persists the owner, step, inputs, operation state, returned
request IDs, and terminal results before advancing. Refresh resumes completed
work or active work with a saved request ID, another user cannot take
ownership, and cleanup failures remain visible and retryable. A recovered
{{QUEUED}} mutation without an ID remains {{PARTIAL}} until a server protocol
can
reconcile whether the earlier request was accepted.
* Views discovery preserves the two-request contract and distinguishes empty,
hidden, system, unauthorized, malformed, and failed responses. Regular and
short routes preserve encoded application paths and query strings without
treating client visibility as authorization.
* View-only initialization avoids cluster-only operations while preserving the
documented shell and session lifecycle. Admin View navigation uses the
server-reported version contract and configured proxy root and provides a
deterministic failure path.
* Permission expressions preserve comma-separated OR semantics and the
whole-expression upgrade exceptions. Visibility checks remain distinct from
owner-aware mutation checks, and direct routes repeat the applicable action
gates.
* Support flags and runtime gates have an executable consumer, an explicit
{{MISSING}} or {{PARTIAL}} result, or a documented {{NOT_APPLICABLE}}
compatibility
decision. No flag is considered migrated only because it is loaded.
* Service Theme preserves full config paths and parent-qualified layout
identity, declaration order, every supported Widget round trip, layered
conditions and attributes, canonical save exclusion for UI-only properties,
password secrecy, read-only consumers, fallback, Retry, and stale-response
isolation across all four consumers.
* Reverse API review accounts for every reachable mutation, including HTTP
method, URL, predicates, fields, headers, body shape, operation level,
ordering, response branches, polling or realtime behavior, and error
recovery.
* The generated matrix contains exactly the canonical 1,154 stable IDs and its
JSON, CSV, and Markdown representations are synchronized. The 581 IDs above
are only this issue's functional-module subset. Metrics exclusions and legacy
placeholders remain in the full generated outputs without entering the
completion denominator.
* Source statuses {{COVERED}}, {{MATCH}}, {{PASS}}, and {{STATIC_COMPLETE}}
that are
supported only by static evidence normalize to {{NEEDS_RUNTIME_VALIDATION}}.
Explicit gap and decision statuses remain unchanged. Final {{COVERED}} is used
only after an acceptance review records independent normal-path and
failure/recovery runtime evidence.
* Every {{MISSING}}, {{PARTIAL}}, {{BLOCKED}}, {{BEHAVIOR_DIFF}}, and
{{NOT_APPLICABLE}} row has this issue, a follow-up issue, or an explicit
maintainer decision with a reason.
* The baseline validator, parity-matrix tests and validator, complete Feature
ID reverse checks, focused Vitest suites, TypeScript build, production build,
applicable lint checks, and {{git diff --check}} pass, or unrelated
pre-existing
failures are reported precisely.
* A second reviewer independently checks all eventual {{COVERED}} and
{{NOT_APPLICABLE}} rows and confirms that the five audit passes found no
unassociated non-Metrics route, action, mutation, permission, flag, recovery
path, or test boundary.
h2. Required Runtime Validation
Static source review, mocks, and unit/component tests cannot close the
following acceptance boundary:
| Area | Minimum real-environment scenarios |
| --- | --- |
| ResourceManager HA | Secure and non-secure clusters; valid and invalid
RM/ZooKeeper/host topology; Stack Advisor changes; optional HAWQ/HDFS
configuration; KDC cancellation/failure; failed requests; refresh and
cross-user recovery |
| Ranger Admin HA | Eligible and ineligible topology; {{http}}, {{https}}, and
{{ftp}} load-balancer values; Kerberos providers; configuration save and
service-check failure; interrupted requests; external load-balancer
verification |
| NameNode Federation | Secure and non-secure clusters; optional Ranger,
Accumulo, and Infra Solr branches; all ordered operations; format/bootstrap
failure; Retry; reload and non-owner access |
| Router Federation | Stack metadata with and without DFSRouter support;
existing and new {{hdfs-rbf-site}}; zero and multiple topology inputs;
install/start/maintenance failure; Retry and reload |
| HAWQ Standby | A compatible historical stack; Add, Remove, and Activate; each
permission combination and custom-command gate; request failure, retry,
refresh, and owner recovery |
| Views | Cluster user, View-only user, Ambari administrator, and unauthorized
user; hidden/system/multiple-version instances; short URLs and proxy roots;
cold and warm valid, invalid, deleted, and malformed-percent-encoded deep
links; path/query preservation; iframe load, resize, host scrolling, activity,
popup, download, and fullscreen behavior; interval cleanup; partial
initialization; session expiry; logout failure; keep-alive start, duplicate
prevention, and stop; Admin View redirect failure |
| KDC and credentials | Manual, MIT, Active Directory, and IPA modes; temporary
and persisted credentials; cancellation, expiry, lookup and save failure,
Retry, and resulting principal/keytab ownership across each applicable HA or
Federation workflow |
| Global gates | Read-only, service operator, cluster administrator, Ambari
administrator, and View-only roles while idle, during supported and blocking
upgrades, and with the same or another wizard owner |
| Service Theme | Real shipped and custom service Themes; duplicate local
names; malformed metadata; every Widget and condition; Service, Host,
comparison, Install, and Add Service consumers; read-only roles; secret-bearing
failures; Retry, service switching, refresh, save/reload, and stale responses |
| Fault injection | Network loss and server errors before and after every
irreversible mutation, failed persistence, stale polling responses, browser
refresh, tab close, and a second session attempting the active workflow |
Runtime outcomes must be recorded per matrix row or linked scenario. A single
happy-path demonstration does not establish operational parity for a long HA
workflow.
h2. Out of Scope
* Ambari Metrics pages, charts, widgets, Heatmaps, Horizon Charts, Metrics data
APIs, and Metrics-specific realtime destinations.
* Business functionality implemented inside separately deployed View
applications. This issue covers only the Ambari shell's discovery, routing,
hosting, authorization boundary, and browser navigation.
* Reimplementation of the AngularJS Admin Console CRUD pages. Only discovery
and navigation into the existing Admin View are included.
* Backend authorization or service-command implementation changes unless a
verified frontend contract defect requires a separately reviewed fix.
* Classic placeholder, unreachable, or verified broken behavior that has an
explicit compatibility decision, including unsupported HA disable or
rollback paths.
* Metrics-related permissions and support flags. Operational CPU, memory, disk,
topology, formatted-state, and request-progress fields remain in scope when
they are direct inputs to a non-Metrics workflow.
h2. Compatibility Decisions
React may deliberately improve verified unsafe or broken Classic behavior by
failing closed on incomplete data, waiting for prerequisite requests, guarding
direct routes, avoiding replay after confirmed failures, escaping untrusted
output, and retaining recoverable workflow state. Each difference must identify
the
Classic behavior, React behavior, user impact, and maintainer decision in the
module document and parity matrix. Reliability improvements are not evidence
that unrelated Classic branches can be omitted.
h2. Verification Boundary
The code portion of this issue can be considered ready after the focused tests,
TypeScript and production builds, validators, matrix generation, reverse
checks, and five-pass audit succeed. Operational parity remains
{{NEEDS_RUNTIME_VALIDATION}} until the required real-cluster matrix has been run
and independently reviewed. The pull request must report static test results
and pending runtime scenarios separately and must not claim that unexecuted
cluster, KDC, historical-stack, proxy, iframe, role, upgrade, or fault-injection
scenarios passed.
> Advance React parity for remaining frontend refactor modules
> ------------------------------------------------------------
>
> Key: AMBARI-26634
> URL: https://issues.apache.org/jira/browse/AMBARI-26634
> Project: Ambari
> Issue Type: Improvement
> Reporter: Jialiang Cai
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> <!---
> Licensed to the Apache Software Foundation (ASF) under one or more
> contributor license agreements. See the NOTICE file distributed with
> this work for additional information regarding copyright ownership.
> The ASF licenses this file to You under the Apache License, Version 2.0
> (the "License"); you may not use this file except in compliance with
> the License. You may obtain a copy of the License at
> http://www.apache.org/licenses/LICENSE-2.0
> Unless required by applicable law or agreed to in writing, software
> distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> See the License for the specific language governing permissions and
> limitations under the License.
> -->
> h2. Suggested Summary
> Advance React parity for the remaining HA, Views, authorization, Service
> Theme, and audit modules
> h2. Problem
> The React frontend does not yet have an accepted parity result for the final
> five functional modules in the Classic Ember baseline. The remaining work is
> tightly coupled: ResourceManager and Ranger Admin HA, Federation and HAWQ,
> Views, global authorization, and Service Theme configuration layouts share
> route guards, upgrade and wizard exclusions, configuration identity, persisted
> workflow ownership, long-running request recovery, and application-shell
> behavior. Reviewing or landing these areas independently can leave
> contradictory permissions, recovery semantics, or matrix evidence.
> This issue covers Modules 10 through 16 as one coherent non-Metrics delivery.
> It includes the 581 stable feature IDs in Modules 10 through 14, generation
> and
> validation of the canonical 1,154-ID React parity matrix, and the final
> five-pass reverse audit. A matching route, component name, or REST endpoint is
> not sufficient evidence of parity.
> h2. Scope
> * Complete ResourceManager HA and Ranger Admin HA entry guards, topology and
> host validation, Stack Advisor integration, KDC boundaries, generated
> configuration, ordered stop/install/save/start/test operations, persisted
> request checkpoints, Retry behavior, refresh recovery, and workflow-owner
> cleanup, while explicitly recording the pre-request-ID unknown-outcome
> boundary that requires server reconciliation or idempotency support.
> * Complete NameNode Federation, Router-based Federation, and historical HAWQ
> Standby Add/Remove/Activate workflows, including stack metadata and topology
> gates, secure-cluster branches, exact configuration transformations, custom
> commands, ordered operations, failure handling, and durable recovery.
> * Complete ordinary and View-only Views shell behavior, two-phase View
> discovery, server-authorized instance filtering, regular and short routes,
> encoded paths and query strings, iframe loading and recovery, browser
> navigation, and Admin View version/proxy-root redirection.
> * Align global permission expressions, upgrade exceptions, wizard-owner
> mutation exclusions, read-versus-mutate checks, Admin routes, User Settings,
> Experimental settings, restart-required operations, support flags, stack
> metadata, service/component topology, Windows gates, and transition-state
> locks with the executable Classic rules.
> * Implement the Service Theme extension contract across Service Configs, Host
> Configs, configuration comparison, and installation/Add Service Step 7,
> including layout-qualified identity, ordered geometry, Widgets, conditions,
> canonical saves, read-only modes, secret-safe diagnostics, fallback, Retry,
> stale-response rejection, and custom stack/service Theme fixtures.
> * Resolve every remaining static gap or record an explicit, reviewable
> compatibility decision. Known gaps must not be hidden by a general parity
> claim.
> * Generate JSON, CSV, and Markdown representations of the canonical React
> parity matrix from all 14 module comparison documents. Preserve all 1,154
> stable IDs, source evidence, issue references, review metadata, and the
> reproducible reviewed-source digest.
> * Perform five independent reverse-audit passes over routes and entry points;
> mutations, payloads, and request ordering; permissions, flags, topology,
> upgrades, and wizard ownership; asynchronous failure, Retry, persistence,
> refresh, and cleanup; and tests, exclusions, and evidence consistency.
> * Add focused tests for normal, denied, failed, retried, refreshed, and
> cross-owner paths, and retain explicit real-cluster scenarios for behavior
> that static tests cannot prove.
> h2. Classic UI Baseline
> The acceptance baseline is the executable Classic Ember source together with
> these reviewed documents:
> * {{docs/frontend-refactor/ember-baseline/10-rm-ranger-ha.md}}: 107 feature
> IDs.
> * {{docs/frontend-refactor/ember-baseline/11-federation-hawq.md}}: 194
> feature IDs.
> * {{docs/frontend-refactor/ember-baseline/12-views.md}}: 92 feature IDs.
> * {{docs/frontend-refactor/ember-baseline/13-permissions-flags.md}}: 36
> feature IDs.
> * {{docs/frontend-refactor/ember-baseline/14-service-theme-layout.md}}: 152
> feature IDs.
> * {{docs/frontend-refactor/ember-baseline/15-react-gap-matrix.md}}: matrix
> schema,
> status rules, evidence requirements, and review gates.
> * {{docs/frontend-refactor/ember-baseline/16-five-pass-audit.md}}: independent
> reverse-audit method and frozen baseline conclusions.
> The corresponding React comparison documents under
> {{docs/frontend-refactor/react-current}} must remain synchronized with the
> code.
> When a baseline statement conflicts with Classic source or verified runtime
> behavior, the baseline must be corrected with source evidence instead of
> changing React to match an unsupported statement.
> h2. Acceptance Criteria
> * All 581 Module 10 through 14 feature IDs appear exactly once in their final
> React comparison tables with a supported status and concrete evidence.
> * ResourceManager and Ranger Admin HA enforce menu and direct-route
> conditions,
> generate the documented configuration, serialize every mutation, retain
> recoverable request state, stop after a failed prerequisite, and avoid
> replay after local or server-confirmed failures. The issue must not claim
> exactly-once recovery when a mutation response is lost before its request ID
> is persisted.
> * NameNode Federation executes its complete ordered workflow; Router
> Federation
> creates or updates its configuration and manages Router components safely;
> HAWQ Add, Remove, and Activate retain their distinct stack, topology,
> permission, and custom-command contracts.
> * Every HA workflow persists the owner, step, inputs, operation state,
> returned
> request IDs, and terminal results before advancing. Refresh resumes
> completed
> work or active work with a saved request ID, another user cannot take
> ownership, and cleanup failures remain visible and retryable. A recovered
> {{QUEUED}} mutation without an ID remains {{PARTIAL}} until a server
> protocol can
> reconcile whether the earlier request was accepted.
> * Views discovery preserves the two-request contract and distinguishes empty,
> hidden, system, unauthorized, malformed, and failed responses. Regular and
> short routes preserve encoded application paths and query strings without
> treating client visibility as authorization.
> * View-only initialization avoids cluster-only operations while preserving the
> documented shell and session lifecycle. Admin View navigation uses the
> server-reported version contract and configured proxy root and provides a
> deterministic failure path.
> * Permission expressions preserve comma-separated OR semantics and the
> whole-expression upgrade exceptions. Visibility checks remain distinct from
> owner-aware mutation checks, and direct routes repeat the applicable action
> gates.
> * Support flags and runtime gates have an executable consumer, an explicit
> {{MISSING}} or {{PARTIAL}} result, or a documented {{NOT_APPLICABLE}}
> compatibility
> decision. No flag is considered migrated only because it is loaded.
> * Service Theme preserves full config paths and parent-qualified layout
> identity, declaration order, every supported Widget round trip, layered
> conditions and attributes, canonical save exclusion for UI-only properties,
> password secrecy, read-only consumers, fallback, Retry, and stale-response
> isolation across all four consumers.
> * Reverse API review accounts for every reachable mutation, including HTTP
> method, URL, predicates, fields, headers, body shape, operation level,
> ordering, response branches, polling or realtime behavior, and error
> recovery.
> * The generated matrix contains exactly the canonical 1,154 stable IDs and its
> JSON, CSV, and Markdown representations are synchronized. The 581 IDs above
> are only this issue's functional-module subset. Metrics exclusions and
> legacy
> placeholders remain in the full generated outputs without entering the
> completion denominator.
> * Source statuses {{COVERED}}, {{MATCH}}, {{PASS}}, and {{STATIC_COMPLETE}}
> that are
> supported only by static evidence normalize to {{NEEDS_RUNTIME_VALIDATION}}.
> Explicit gap and decision statuses remain unchanged. Final {{COVERED}} is
> used
> only after an acceptance review records independent normal-path and
> failure/recovery runtime evidence.
> * Every {{MISSING}}, {{PARTIAL}}, {{BLOCKED}}, {{BEHAVIOR_DIFF}}, and
> {{NOT_APPLICABLE}} row has this issue, a follow-up issue, or an explicit
> maintainer decision with a reason.
> * The baseline validator, parity-matrix tests and validator, complete Feature
> ID reverse checks, focused Vitest suites, TypeScript build, production
> build,
> applicable lint checks, and {{git diff --check}} pass, or unrelated
> pre-existing
> failures are reported precisely.
> * A second reviewer independently checks all eventual {{COVERED}} and
> {{NOT_APPLICABLE}} rows and confirms that the five audit passes found no
> unassociated non-Metrics route, action, mutation, permission, flag, recovery
> path, or test boundary.
> h2. Required Runtime Validation
> Static source review, mocks, and unit/component tests cannot close the
> following acceptance boundary:
> | Area | Minimum real-environment scenarios |
> | --- | --- |
> | ResourceManager HA | Secure and non-secure clusters; valid and invalid
> RM/ZooKeeper/host topology; Stack Advisor changes; optional HAWQ/HDFS
> configuration; KDC cancellation/failure; failed requests; refresh and
> cross-user recovery |
> | Ranger Admin HA | Eligible and ineligible topology; {{http}}, {{https}},
> and {{ftp}} load-balancer values; Kerberos providers; configuration save and
> service-check failure; interrupted requests; external load-balancer
> verification |
> | NameNode Federation | Secure and non-secure clusters; optional Ranger,
> Accumulo, and Infra Solr branches; all ordered operations; format/bootstrap
> failure; Retry; reload and non-owner access |
> | Router Federation | Stack metadata with and without DFSRouter support;
> existing and new {{hdfs-rbf-site}}; zero and multiple topology inputs;
> install/start/maintenance failure; Retry and reload |
> | HAWQ Standby | A compatible historical stack; Add, Remove, and Activate;
> each permission combination and custom-command gate; request failure, retry,
> refresh, and owner recovery |
> | Views | Cluster user, View-only user, Ambari administrator, and
> unauthorized user; hidden/system/multiple-version instances; short URLs and
> proxy roots; cold and warm valid, invalid, deleted, and
> malformed-percent-encoded deep links; path/query preservation; iframe load,
> resize, host scrolling, activity, popup, download, and fullscreen behavior;
> interval cleanup; partial initialization; session expiry; logout failure;
> keep-alive start, duplicate prevention, and stop; Admin View redirect failure
> |
> | KDC and credentials | Manual, MIT, Active Directory, and IPA modes;
> temporary and persisted credentials; cancellation, expiry, lookup and save
> failure, Retry, and resulting principal/keytab ownership across each
> applicable HA or Federation workflow |
> | Global gates | Read-only, service operator, cluster administrator, Ambari
> administrator, and View-only roles while idle, during supported and blocking
> upgrades, and with the same or another wizard owner |
> | Service Theme | Real shipped and custom service Themes; duplicate local
> names; malformed metadata; every Widget and condition; Service, Host,
> comparison, Install, and Add Service consumers; read-only roles;
> secret-bearing failures; Retry, service switching, refresh, save/reload, and
> stale responses |
> | Fault injection | Network loss and server errors before and after every
> irreversible mutation, failed persistence, stale polling responses, browser
> refresh, tab close, and a second session attempting the active workflow |
> Runtime outcomes must be recorded per matrix row or linked scenario. A single
> happy-path demonstration does not establish operational parity for a long HA
> workflow.
> h2. Out of Scope
> * Ambari Metrics pages, charts, widgets, Heatmaps, Horizon Charts, Metrics
> data
> APIs, and Metrics-specific realtime destinations.
> * Business functionality implemented inside separately deployed View
> applications. This issue covers only the Ambari shell's discovery, routing,
> hosting, authorization boundary, and browser navigation.
> * Reimplementation of the AngularJS Admin Console CRUD pages. Only discovery
> and navigation into the existing Admin View are included.
> * Backend authorization or service-command implementation changes unless a
> verified frontend contract defect requires a separately reviewed fix.
> * Classic placeholder, unreachable, or verified broken behavior that has an
> explicit compatibility decision, including unsupported HA disable or
> rollback paths.
> * Metrics-related permissions and support flags. Operational CPU, memory,
> disk,
> topology, formatted-state, and request-progress fields remain in scope when
> they are direct inputs to a non-Metrics workflow.
> h2. Compatibility Decisions
> React may deliberately improve verified unsafe or broken Classic behavior by
> failing closed on incomplete data, waiting for prerequisite requests, guarding
> direct routes, avoiding replay after confirmed failures, escaping untrusted
> output, and retaining recoverable workflow state. Each difference must
> identify the
> Classic behavior, React behavior, user impact, and maintainer decision in the
> module document and parity matrix. Reliability improvements are not evidence
> that unrelated Classic branches can be omitted.
> h2. Verification Boundary
> The code portion of this issue can be considered ready after the focused
> tests,
> TypeScript and production builds, validators, matrix generation, reverse
> checks, and five-pass audit succeed. Operational parity remains
> {{NEEDS_RUNTIME_VALIDATION}} until the required real-cluster matrix has been
> run
> and independently reviewed. The pull request must report static test results
> and pending runtime scenarios separately and must not claim that unexecuted
> cluster, KDC, historical-stack, proxy, iframe, role, upgrade, or
> fault-injection
> scenarios passed.
> h2. Implemented in PR 4180
> PR: [apache/ambari#4180|https://github.com/apache/ambari/pull/4180]
> The branch contains twelve topic-specific commits intended to keep review
> boundaries clear:
> * {{b8e34c97df}} stabilizes Host detail initialization.
> * {{02b869e936}} fixes Add Host cancellation navigation and cleanup recovery.
> * {{e35a4d6b4d}} installs Ranger plugins only when enabled.
> * {{cc33dd4774}} packages the credential shell configuration dependency.
> * {{2e7470dfd2}} fixes Service Theme layout and metadata diagnostics.
> * {{6a2070f046}} migrates the HDFS Files View to React.
> * {{2f343f1798}} migrates the YARN Capacity Scheduler View to React.
> * {{f24fd0c4bf}} records hosted View React parity evidence.
> * {{10ab42455d}} packages supported contrib Views in default builds.
> * {{cb050006f8}} removes the obsolete Pig View.
> * {{0a8032c1e5}} removes the unsupported Oozie Workflow Manager View.
> * {{edb11bb400}} keeps Admin View and hosted View navigation in React.
> The final navigation change removes accidental fallbacks to Classic from Admin
> View instance, short URL, Dashboard, installer, Stack Versions,
> authentication,
> logout, and inactivity-timeout flows. Dynamic View route segments are encoded,
> reverse-proxy application prefixes are retained, and the explicit Switch to
> classic UI command remains available. The Files and Capacity Scheduler Views
> also retain proxy prefixes for API and download URLs.
> h3. Verification recorded by the pull request
> * The main React frontend passed 188 test files and 991 tests and completed
> its production build.
> * The Files View passed 3 test files and 12 tests and completed its
> production build.
> * The Capacity Scheduler View passed 3 test files and 16 tests and completed
> its production build.
> * The Admin navigation helper passed 3 focused tests and the Admin
> TypeScript/Vite production build completed.
> * Updated Admin, Files, and Capacity Scheduler assets were deployed to the
> local three-node cluster and manually verified by the maintainer.
> * The full Admin run completed 121 existing tests before 10 suites hit the
> pre-existing {{history}} dependency-manifest mismatch.
> * Admin lint remains blocked by the pre-existing ESLint flat-config/package
> mismatch; this is reported in the PR and is not presented as passing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
