[
https://issues.apache.org/jira/browse/AMBARI-26634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialiang Cai reassigned AMBARI-26634:
-------------------------------------
Assignee: Jialiang Cai
> 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
> Assignee: Jialiang Cai
> Priority: Major
> Time Spent: 1h
> 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]
