[
https://issues.apache.org/jira/browse/AMBARI-26648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandeep Kumar updated AMBARI-26648:
-----------------------------------
Description:
*All config properties render as read-only regardless of permissions*
Steps to reproduce:
1. Log in as a user with SERVICE.MODIFY_CONFIGS authorization (e.g. admin).
2. Navigate to any service's Configs tab (e.g. ZooKeeper → Configs).
3. Observe every property's input field is disabled/read-only, even though the
user has permission to edit.
Expected: Properties should be editable when the user has
SERVICE.MODIFY_CONFIGS and no other restriction (read-only stack attribute,
editable-only-at-install, non-default version selected) applies.
Actual: Every property is read-only unconditionally.
*JVM/command-line config values wrongly rendered as multi-line*
Application Master java opts [yarn.app.mapreduce.am.command-opts] configuration
is passed in improper format to the mapred-site.xml, causing MR job failures.
This is observed if number of java opts passed is more than two.
Same issue might be observed with map and reduce java opts.
[mapreduce.map.java.opts, mapreduce.reduce.java.opts].
Steps to reproduce:
1. Open a service's Configs tab where a property value looks like command-line
arguments, e.g. mapreduce.admin.map.child.java.opts = -server -XX:NewRatio=8
-Djava.net.preferIPv4Stack=true -Dhdp.version=${hdp.version}.
2. Observe the value is displayed as a multi-line textarea, split roughly one
argument per line, even though the stored value is a single line and the
backend did not declare a multi-line display type for it.
Expected: A property should only be rendered as multi-line when the backend
explicitly says so (displayType === "multiLine"), or, absent that, when the
value itself genuinely contains a newline (real or escaped) — matching the
reference Ember UI's behavior.
Actual: Any value that tokenized into more than one whitespace-separated
argument, where every token looked like a JVM flag (-X, -D, -XX:, -server,
-client, --add-opens=, --add-exports=), was treated as multi-line purely by
guessing from content shape — not because the value or its metadata called for
it.
was:
*All config properties render as read-only regardless of permissions*
Steps to reproduce:
1. Log in as a user with SERVICE.MODIFY_CONFIGS authorization (e.g. admin).
2. Navigate to any service's Configs tab (e.g. ZooKeeper → Configs).
3. Observe every property's input field is disabled/read-only, even though the
user has permission to edit.
Expected: Properties should be editable when the user has
SERVICE.MODIFY_CONFIGS and no other restriction (read-only stack attribute,
editable-only-at-install, non-default version selected) applies.
Actual: Every property is read-only unconditionally.
*JVM/command-line config values wrongly rendered as multi-line*
Steps to reproduce:
1. Open a service's Configs tab where a property value looks like command-line
arguments, e.g. mapreduce.admin.map.child.java.opts = -server -XX:NewRatio=8
-Djava.net.preferIPv4Stack=true -Dhdp.version=${hdp.version}.
2. Observe the value is displayed as a multi-line textarea, split roughly one
argument per line, even though the stored value is a single line and the
backend did not declare a multi-line display type for it.
Expected: A property should only be rendered as multi-line when the backend
explicitly says so (displayType === "multiLine"), or, absent that, when the
value itself genuinely contains a newline (real or escaped) — matching the
reference Ember UI's behavior.
Actual: Any value that tokenized into more than one whitespace-separated
argument, where every token looked like a JVM flag (-X, -D, -XX:, -server,
-client, --add-opens=, --add-exports=), was treated as multi-line purely by
guessing from content shape — not because the value or its metadata called for
it.
> Service Configs Bug: all properties render read-only, and JVM/command-line
> values incorrectly split into multi-line display
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: AMBARI-26648
> URL: https://issues.apache.org/jira/browse/AMBARI-26648
> Project: Ambari
> Issue Type: Story
> Reporter: Sandeep Kumar
> Assignee: Sandeep Kumar
> Priority: Major
>
> *All config properties render as read-only regardless of permissions*
> Steps to reproduce:
> 1. Log in as a user with SERVICE.MODIFY_CONFIGS authorization (e.g. admin).
> 2. Navigate to any service's Configs tab (e.g. ZooKeeper → Configs).
> 3. Observe every property's input field is disabled/read-only, even though
> the user has permission to edit.
> Expected: Properties should be editable when the user has
> SERVICE.MODIFY_CONFIGS and no other restriction (read-only stack attribute,
> editable-only-at-install, non-default version selected) applies.
> Actual: Every property is read-only unconditionally.
> *JVM/command-line config values wrongly rendered as multi-line*
> Application Master java opts [yarn.app.mapreduce.am.command-opts]
> configuration is passed in improper format to the mapred-site.xml, causing MR
> job failures. This is observed if number of java opts passed is more than two.
> Same issue might be observed with map and reduce java opts.
> [mapreduce.map.java.opts, mapreduce.reduce.java.opts].
> Steps to reproduce:
> 1. Open a service's Configs tab where a property value looks like
> command-line arguments, e.g. mapreduce.admin.map.child.java.opts = -server
> -XX:NewRatio=8 -Djava.net.preferIPv4Stack=true -Dhdp.version=${hdp.version}.
> 2. Observe the value is displayed as a multi-line textarea, split roughly one
> argument per line, even though the stored value is a single line and the
> backend did not declare a multi-line display type for it.
>
> Expected: A property should only be rendered as multi-line when the backend
> explicitly says so (displayType === "multiLine"), or, absent that, when the
> value itself genuinely contains a newline (real or escaped) — matching the
> reference Ember UI's behavior.
> Actual: Any value that tokenized into more than one whitespace-separated
> argument, where every token looked like a JVM flag (-X, -D, -XX:, -server,
> -client, --add-opens=, --add-exports=), was treated as multi-line purely by
> guessing from content shape — not because the value or its metadata called
> for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
