[
https://issues.apache.org/jira/browse/AMBARI-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Maurya updated AMBARI-26666:
-------------------------------------
Status: Patch Available (was: Open)
> 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
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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]
