[
https://issues.apache.org/jira/browse/AMBARI-26647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Maurya updated AMBARI-26647:
-------------------------------------
Description:
h2. Summary
The {{capacity-scheduler.xml}} properties on the YARN Advanced Configs tab were
rendered as one input field per property, which does not match the classic
Ember UI's dedicated combined-textarea editor and made bulk edits
(adding/removing queues, editing multiple properties at once) awkward and
error-prone. Saving a {{capacity-scheduler.xml}} change also silently skipped
the "Refresh YARN Queues" prompt that the classic UI shows, so the new
configuration was not actually applied to the running ResourceManager until a
manual refresh.
h2. Changes
* {{capacity-scheduler.xml}} properties are now edited as a single combined
{{{}key=value{}}}-per-line textarea, folded into the existing
"CapacityScheduler" section (displayed as "Scheduler") instead of being
rendered as their own separate accordion item with one field per property. This
matches the classic Ember UI's {{App.CapacitySceduler}} widget.
* Editing the textarea parses each {{key=value}} line back into the individual
property map: existing properties are updated in place, new lines add new
properties (cloned from an existing property's metadata), and removed lines
delete the corresponding property.
* After successfully saving configs, if any of the saved changes touched
{{{}capacity-scheduler.xml{}}}, a confirmation popup now prompts the user to
"Refresh YARN Queues." Accepting submits a YARN {{REFRESHQUEUES}} action
against all hosts running the ResourceManager component, matching the classic
UI's {{ComponentActionsByConfigs#showPopup}} behavior.
h2. Impact
Capacity Scheduler queue configuration can now be edited in bulk via a single
textarea (matching the classic UI's editing experience), and saved changes are
properly propagated to the running ResourceManager via the Refresh YARN Queues
prompt instead of requiring a manual follow-up action.
was:
h2. Summary
Opening a Host Summary page by clicking a component count on the Hosts List
page (or a service's component-count link, or a stack version's host-count
link) could leave the Host Summary page stuck without its host components
listed, or with a stale/unfiltered view. Root cause: these links used URL-param
routes ({{{}/main/hosts/component/:componentName{}}},
{{{}/main/hosts/version/:versionName/:versionStatus{}}}) that remounted the
Hosts List component on every navigation, discarding in-flight state and racing
the data fetch against the route change. Several related bugs stemmed from the
same remount and stale-closure issues.
h2. Changes
* Replaced the URL-param-based filter routes with a new
{{useHostsFilterNavigation}} hook that sets the Hosts List filter via the
shared filter context and navigates to the plain {{/main/hosts}} route (no
route params, no remount). All component-count and stack-version-count links
across the service summary views and the Stack Versions page now use this hook
instead of building a {{/main/hosts/component/...}} or
{{/main/hosts/version/...}} URL.
* Removed the now-unused {{hosts/component/:componentName}} and
{{hosts/version/:versionName/:versionStatus}} routes.
* Fixed a stale-closure bug in {{{}useHostConfigUpdater{}}}: WebSocket-driven
host/component/decommission updates read host models from a snapshot ref that
could be one render behind, occasionally overwriting fresh data with stale
data. Updates are now applied via functional {{setState}} so they always merge
into the latest committed state.
* Fixed the Host Summary page's loading spinner staying stuck: it was gated on
the cluster-wide component poll (which can lag on a large cluster) instead of
on the host's own loaded data.
* Fixed the Hosts List filter search bar silently wiping filters that were set
by another page: it was echoing its local filter state back into the shared
setter on every render, which could stomp a filter that had just been seeded by
a deep link.
* Fixed the Hosts List query no longer sending an unfiltered request on first
render when filters were already restored from a previous page.
h2. Impact
Component-count and version-count links from service summaries and the Stack
Versions page now reliably open a correctly filtered, fully-populated Hosts
List / Host Summary page, with no stale data or missed component listings
caused by the previous remount-based navigation.
> Ambari Web React: Fix Capacity Scheduler config editing format and add
> Refresh YARN Queues prompt
> -------------------------------------------------------------------------------------------------
>
> Key: AMBARI-26647
> URL: https://issues.apache.org/jira/browse/AMBARI-26647
> Project: Ambari
> Issue Type: Story
> Reporter: Himanshu Maurya
> Assignee: Himanshu Maurya
> Priority: Major
> Fix For: 3.1.0
>
>
> h2. Summary
> The {{capacity-scheduler.xml}} properties on the YARN Advanced Configs tab
> were rendered as one input field per property, which does not match the
> classic Ember UI's dedicated combined-textarea editor and made bulk edits
> (adding/removing queues, editing multiple properties at once) awkward and
> error-prone. Saving a {{capacity-scheduler.xml}} change also silently skipped
> the "Refresh YARN Queues" prompt that the classic UI shows, so the new
> configuration was not actually applied to the running ResourceManager until a
> manual refresh.
> h2. Changes
> * {{capacity-scheduler.xml}} properties are now edited as a single combined
> {{{}key=value{}}}-per-line textarea, folded into the existing
> "CapacityScheduler" section (displayed as "Scheduler") instead of being
> rendered as their own separate accordion item with one field per property.
> This matches the classic Ember UI's {{App.CapacitySceduler}} widget.
> * Editing the textarea parses each {{key=value}} line back into the
> individual property map: existing properties are updated in place, new lines
> add new properties (cloned from an existing property's metadata), and removed
> lines delete the corresponding property.
> * After successfully saving configs, if any of the saved changes touched
> {{{}capacity-scheduler.xml{}}}, a confirmation popup now prompts the user to
> "Refresh YARN Queues." Accepting submits a YARN {{REFRESHQUEUES}} action
> against all hosts running the ResourceManager component, matching the classic
> UI's {{ComponentActionsByConfigs#showPopup}} behavior.
> h2. Impact
> Capacity Scheduler queue configuration can now be edited in bulk via a single
> textarea (matching the classic UI's editing experience), and saved changes
> are properly propagated to the running ResourceManager via the Refresh YARN
> Queues prompt instead of requiring a manual follow-up action.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
