[
https://issues.apache.org/jira/browse/AMBARI-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Maurya updated AMBARI-26666:
-------------------------------------
Description:
h2. Problem
In the React UI ({{{}ambari-web/latest{}}}), Recover Host can only be run from
a single host's Host Details page (Host Actions > Recover Host). To recover
many hosts, for example after re-imaging a rack or after a failed bulk install,
an operator has to open each host and run Recover Host one at a time. Each run
creates a separate request schedule and, on Kerberos clusters, a separate
keytab regeneration.
The legacy Ember UI has the same limitation: its Hosts List bulk Actions menu
has no recover option.
h2. Proposed Change
Add a *Recover Hosts* action to the Hosts submenu of the Hosts List bulk
Actions menu. Like the other bulk host actions, it can target Selected,
Filtered, or All hosts.
* *Eligibility:* The existing single-host rule is reused unchanged. A host can
be recovered only when every component on it is INSTALLED (Stopped),
INSTALL_FAILED, or INIT.
* *Skipped hosts:* Hosts that have components in any other state, or that have
no components, are skipped. The confirmation dialog lists each skipped host
with an expandable reason that names the blocking components.
* *Nothing to recover:* If none of the targeted hosts can be recovered, a
message is shown and no request is submitted.
* *Confirmation:* The dialog lists the hosts that will be recovered and warns
that all of their components will be re-installed. The confirm button can be
submitted only once.
* *Request:* All eligible hosts are submitted as one request schedule
({{{}POST /clusters/\{cluster}/request_schedules{}}}) with a task failure
tolerance of 0. The steps run in this order:
## Set all host components to INIT, one step per host.
## Set all host components to INSTALLED, one step per host.
## On Kerberos clusters only, regenerate keytabs once for all recovered hosts.
For a single host, this request is identical to the one that single-host
Recover Host submits today.
* *Kerberos:* The KDC session is validated before submission, as it is for
single-host Recover Host. If the KDC session is not confirmed, nothing is
submitted.
* *Progress:* On success, Background Operations opens. The batch API returns a
request schedule ID rather than a request ID, so Background Operations opens at
the request list, as it does for single-host Recover Host.
* *Failure:* If submission fails, an error dialog is shown and Background
Operations does not open.
No server or REST API changes are needed. The feature uses only existing
endpoints: the hosts bulk query, request schedules, and Kerberos keytab
regeneration.
was:
h2. Summary
The HDFS service summary in the React "Modern UI" had two related display bugs:
# In the non-federated (single-nameservice) HA view, each NameNode tile always
showed the literal HA state string concatenated with {{NAMENODE}} (e.g.
{{{}active NAMENODE{}}}, {{{}standby NAMENODE{}}}) instead of a properly cased
label, and never accounted for the {{observer}} HA state introduced by
consistent-read observer NameNodes — it fell through to the same raw string.
The ZKFC tile for each NameNode's host was also rendered as a separate block
below all NameNode tiles instead of being grouped next to its NameNode, unlike
the classic Ember UI's {{getGroupedMasterComponents}} layout.
# HDFS federation detection ({{{}useHDFSConfigUpdater{}}}) derived its
namespace groups from the {{dfs.nameservices}} config property rather than from
the NameNodes actually installed and reporting HA state. A nameservice declared
in {{hdfs-site.xml}} but not yet populated with a running NameNode (e.g.
mid-rollout, or an observer-only nameservice) was still counted as a distinct
namespace, incorrectly flipping the summary into the federated topology view
and causing component counts (including DataNode) to be computed against the
wrong grouping.
h2. Changes
* {{{}screens/Services/ServiceComponents.tsx{}}}:
** Added a {{getNameNodeLabel(haStatus)}} helper (mirrors Ember's
{{{}display_name_advanced{}}}) mapping
{{{}active{}}}/{{{}standby{}}}/{{{}observer{}}} HA states to proper display
labels, falling back to the generic "NameNode" label for unknown/empty states.
** Merged the ZKFC tile into the NameNode tile loop so each ZKFC renders
immediately after the NameNode on the same host, removing the separate,
disconnected ZKFC {{.map()}} block.
* {{{}screens/messages.ts{}}}, {{{}locales/en/translation.json{}}},
{{{}locales/zh/translation.json{}}}:
** Added the {{services.service.summary.nameNode.observer}} translation key
(English "Observer NameNode" / Chinese "观察者 NameNode") in all three places the
app's i18n layer reads from — {{translate()}} resolves through i18next's loaded
{{translation.json}} resources first, so the key needed adding there, not just
in the {{messages.ts}} fallback map.
* {{{}hooks/useHDFSConfigUpdater.ts{}}}:
** Added a {{buildNameNodeGroups(nameNodes, nameSpacePath)}} helper that
groups NameNodes into namespace groups using the {{haNameSpace}} tag already
resolved onto each NameNode host component, rather than deriving groups
directly from the {{dfs.nameservices}} property list.
** Applied this helper in both {{inferNamespace()}} (the config-driven pass)
and the poll-driven {{federationNamespaces}} recomputation, so the two paths
stay consistent — the poll path previously used the raw {{dfs.nameservices}}
parsing on every poll, which would have reintroduced a discarded/unpopulated
nameservice as soon as the next poll ran.
* {{{}screens/Services/ServiceComponents.test.tsx{}}}:
** Added coverage for the HDFS summary path (previously untested): NameNode
HA-state label resolution paired with its host's ZKFC, and a regression test
confirming a declared-but-unpopulated namespace no longer flips the view into
the federated layout.
h2. Impact
HDFS summary tiles now show the correct Active/Standby/Observer NameNode label
(translated correctly in both bundled locales) and group the ZKFC status with
its NameNode, and HDFS federation topology detection reflects only nameservices
with actually installed/reporting NameNodes — a declared-but-unpopulated
nameservice no longer causes the UI to incorrectly render the federated layout
or miscompute component counts.
> Support bulk Recover Hosts action from the Hosts List page in Ambari Web
> (React)
> --------------------------------------------------------------------------------
>
> Key: AMBARI-26666
> URL: https://issues.apache.org/jira/browse/AMBARI-26666
> Project: Ambari
> Issue Type: Story
> Reporter: Himanshu Maurya
> Assignee: Himanshu Maurya
> Priority: Major
> Fix For: 3.1.0
>
>
> h2. Problem
> In the React UI ({{{}ambari-web/latest{}}}), Recover Host can only be run
> from a single host's Host Details page (Host Actions > Recover Host). To
> recover many hosts, for example after re-imaging a rack or after a failed
> bulk install, an operator has to open each host and run Recover Host one at a
> time. Each run creates a separate request schedule and, on Kerberos clusters,
> a separate keytab regeneration.
> The legacy Ember UI has the same limitation: its Hosts List bulk Actions menu
> has no recover option.
> h2. Proposed Change
> Add a *Recover Hosts* action to the Hosts submenu of the Hosts List bulk
> Actions menu. Like the other bulk host actions, it can target Selected,
> Filtered, or All hosts.
> * *Eligibility:* The existing single-host rule is reused unchanged. A host
> can be recovered only when every component on it is INSTALLED (Stopped),
> INSTALL_FAILED, or INIT.
> * *Skipped hosts:* Hosts that have components in any other state, or that
> have no components, are skipped. The confirmation dialog lists each skipped
> host with an expandable reason that names the blocking components.
> * *Nothing to recover:* If none of the targeted hosts can be recovered, a
> message is shown and no request is submitted.
> * *Confirmation:* The dialog lists the hosts that will be recovered and
> warns that all of their components will be re-installed. The confirm button
> can be submitted only once.
> * *Request:* All eligible hosts are submitted as one request schedule
> ({{{}POST /clusters/\{cluster}/request_schedules{}}}) with a task failure
> tolerance of 0. The steps run in this order:
> ## Set all host components to INIT, one step per host.
> ## Set all host components to INSTALLED, one step per host.
> ## On Kerberos clusters only, regenerate keytabs once for all recovered
> hosts.
> For a single host, this request is identical to the one that single-host
> Recover Host submits today.
> * *Kerberos:* The KDC session is validated before submission, as it is for
> single-host Recover Host. If the KDC session is not confirmed, nothing is
> submitted.
> * *Progress:* On success, Background Operations opens. The batch API returns
> a request schedule ID rather than a request ID, so Background Operations
> opens at the request list, as it does for single-host Recover Host.
> * *Failure:* If submission fails, an error dialog is shown and Background
> Operations does not open.
> No server or REST API changes are needed. The feature uses only existing
> endpoints: the hosts bulk query, request schedules, and Kerberos keytab
> regeneration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
