[jira] [Updated] (AMBARI-21123) Part Two: Specify the script directly in alert target for script-based alert dispatchers
[ https://issues.apache.org/jira/browse/AMBARI-21123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yao Lei updated AMBARI-21123: - Description: *Web Codes Part* This patch amis to support creating alert target that inclueds property *ambari.dispatch-property.script.filename* on web UI was: Web Codes Part This patch amis to support creating alert target that inclueds property *ambari.dispatch-property.script.filename* on web UI > Part Two: Specify the script directly in alert target for script-based alert > dispatchers > > > Key: AMBARI-21123 > URL: https://issues.apache.org/jira/browse/AMBARI-21123 > Project: Ambari > Issue Type: Technical task > Components: alerts, ambari-web >Affects Versions: trunk >Reporter: Yao Lei >Assignee: Yao Lei > Fix For: 3.0.0 > > Attachments: AMBARI-21123.patch, script_alert_notification_1.png, > script_alert_notification_2.png > > > *Web Codes Part* > This patch amis to support creating alert target that inclueds property > *ambari.dispatch-property.script.filename* on web UI -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21122) Part One: Specify the script directly in alert target for script-based alert dispatchers
[
https://issues.apache.org/jira/browse/AMBARI-21122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yao Lei updated AMBARI-21122:
-
Attachment: AMBARI-21122.2.patch
> Part One: Specify the script directly in alert target for script-based alert
> dispatchers
> -
>
> Key: AMBARI-21122
> URL: https://issues.apache.org/jira/browse/AMBARI-21122
> Project: Ambari
> Issue Type: Technical task
>Affects Versions: trunk
>Reporter: Yao Lei
>Assignee: Yao Lei
> Fix For: 3.0.0
>
> Attachments: AMBARI-21122.1.patch, AMBARI-21122.2.patch
>
>
> *Jave Codes Part*
> This patch will support using property
> *ambari.dispatch-property.script.filename* in alert target to tell
> AlertScriptDispatcher to lookup script by filename,default in
> /var/lib/ambari-server/resources/scripts directory. We can also change this
> directory in ambari.properties by
> *notification.dispatch.alert.script.directory* property.
> Execute a command manually like following to create an alert target that
> includes this property:
> {code}
> POST api/v1/alert_targets
> {
> "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": false,
> "groups":[1,3]
> "alert_states":["WARNING","CRITICAL","UNKNOWN"],
> "properties": {
>"ambari.dispatch-property.script.filename": "foo.py"
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-21122) Part One: Specify the script directly in alert target for script-based alert dispatchers
[
https://issues.apache.org/jira/browse/AMBARI-21122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yao Lei updated AMBARI-21122:
-
Attachment: (was: AMBARI-21122.2.patch)
> Part One: Specify the script directly in alert target for script-based alert
> dispatchers
> -
>
> Key: AMBARI-21122
> URL: https://issues.apache.org/jira/browse/AMBARI-21122
> Project: Ambari
> Issue Type: Technical task
>Affects Versions: trunk
>Reporter: Yao Lei
>Assignee: Yao Lei
> Fix For: 3.0.0
>
> Attachments: AMBARI-21122.1.patch, AMBARI-21122.2.patch
>
>
> *Jave Codes Part*
> This patch will support using property
> *ambari.dispatch-property.script.filename* in alert target to tell
> AlertScriptDispatcher to lookup script by filename,default in
> /var/lib/ambari-server/resources/scripts directory. We can also change this
> directory in ambari.properties by
> *notification.dispatch.alert.script.directory* property.
> Execute a command manually like following to create an alert target that
> includes this property:
> {code}
> POST api/v1/alert_targets
> {
> "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": false,
> "groups":[1,3]
> "alert_states":["WARNING","CRITICAL","UNKNOWN"],
> "properties": {
>"ambari.dispatch-property.script.filename": "foo.py"
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-21122) Part One: Specify the script directly in alert target for script-based alert dispatchers
[
https://issues.apache.org/jira/browse/AMBARI-21122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yao Lei updated AMBARI-21122:
-
Attachment: AMBARI-21122.2.patch
> Part One: Specify the script directly in alert target for script-based alert
> dispatchers
> -
>
> Key: AMBARI-21122
> URL: https://issues.apache.org/jira/browse/AMBARI-21122
> Project: Ambari
> Issue Type: Technical task
>Affects Versions: trunk
>Reporter: Yao Lei
>Assignee: Yao Lei
> Fix For: 3.0.0
>
> Attachments: AMBARI-21122.1.patch, AMBARI-21122.2.patch
>
>
> *Jave Codes Part*
> This patch will support using property
> *ambari.dispatch-property.script.filename* in alert target to tell
> AlertScriptDispatcher to lookup script by filename,default in
> /var/lib/ambari-server/resources/scripts directory. We can also change this
> directory in ambari.properties by
> *notification.dispatch.alert.script.directory* property.
> Execute a command manually like following to create an alert target that
> includes this property:
> {code}
> POST api/v1/alert_targets
> {
> "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": false,
> "groups":[1,3]
> "alert_states":["WARNING","CRITICAL","UNKNOWN"],
> "properties": {
>"ambari.dispatch-property.script.filename": "foo.py"
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (AMBARI-21152) Config Management in Multi Everything Architecture
[ https://issues.apache.org/jira/browse/AMBARI-21152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya reassigned AMBARI-21152: -- Assignee: Jayush Luniya Affects Version/s: 3.0.0 Fix Version/s: 3.0.0 Component/s: stacks ambari-server ambari-agent Issue Type: Epic (was: Bug) > Config Management in Multi Everything Architecture > -- > > Key: AMBARI-21152 > URL: https://issues.apache.org/jira/browse/AMBARI-21152 > Project: Ambari > Issue Type: Epic > Components: ambari-agent, ambari-server, stacks >Affects Versions: 3.0.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-21152) Config Management in Multi Everything Architecture
Jayush Luniya created AMBARI-21152: -- Summary: Config Management in Multi Everything Architecture Key: AMBARI-21152 URL: https://issues.apache.org/jira/browse/AMBARI-21152 Project: Ambari Issue Type: Bug Reporter: Jayush Luniya -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21151) Hiveserver2 authentication mode NOSASL not available in drop down list but appearing in tooltip description
[ https://issues.apache.org/jira/browse/AMBARI-21151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-21151: --- Status: Patch Available (was: Open) > Hiveserver2 authentication mode NOSASL not available in drop down list but > appearing in tooltip description > --- > > Key: AMBARI-21151 > URL: https://issues.apache.org/jira/browse/AMBARI-21151 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.5.1 >Reporter: Aswathy Chellammal Sreekumar >Assignee: Sumit Mohanty > Fix For: 2.5.2 > > Attachments: AMBARI-21151.patch > > > When we try to set hive.server2.authentication as NOSASL ambari displays a > warning that says "NOSASL is not available in the list of valid values" and > is not present in the drop down menu as well. But the tooltip description has > the same in the list of options. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21151) Hiveserver2 authentication mode NOSASL not available in drop down list but appearing in tooltip description
[ https://issues.apache.org/jira/browse/AMBARI-21151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumit Mohanty updated AMBARI-21151: --- Attachment: AMBARI-21151.patch > Hiveserver2 authentication mode NOSASL not available in drop down list but > appearing in tooltip description > --- > > Key: AMBARI-21151 > URL: https://issues.apache.org/jira/browse/AMBARI-21151 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.5.1 >Reporter: Aswathy Chellammal Sreekumar >Assignee: Sumit Mohanty > Fix For: 2.5.2 > > Attachments: AMBARI-21151.patch > > > When we try to set hive.server2.authentication as NOSASL ambari displays a > warning that says "NOSASL is not available in the list of valid values" and > is not present in the drop down menu as well. But the tooltip description has > the same in the list of options. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-21151) Hiveserver2 authentication mode NOSASL not available in drop down list but appearing in tooltip description
Sumit Mohanty created AMBARI-21151: -- Summary: Hiveserver2 authentication mode NOSASL not available in drop down list but appearing in tooltip description Key: AMBARI-21151 URL: https://issues.apache.org/jira/browse/AMBARI-21151 Project: Ambari Issue Type: Bug Components: stacks Affects Versions: 2.5.1 Reporter: Aswathy Chellammal Sreekumar Assignee: Sumit Mohanty Fix For: 2.5.2 When we try to set hive.server2.authentication as NOSASL ambari displays a warning that says "NOSASL is not available in the list of valid values" and is not present in the drop down menu as well. But the tooltip description has the same in the list of options. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-21150) Mpack API
Madhuvanthi Radhakrishnan created AMBARI-21150: -- Summary: Mpack API Key: AMBARI-21150 URL: https://issues.apache.org/jira/browse/AMBARI-21150 Project: Ambari Issue Type: Bug Reporter: Madhuvanthi Radhakrishnan Assignee: Madhuvanthi Radhakrishnan -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21149) Configurations Created During Upgrade Must Use Correct StackId Based on Service
[
https://issues.apache.org/jira/browse/AMBARI-21149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-21149:
-
Description:
When creating an upgrade, the configurations which are part of
{{ConfigureAction}} are still using the cluster's "current" version when
creating new configs. This needs to be changed to using the source/target
versions of the service in the upgrade.
{code}
ambari=# select config_id, type_name version_tag, stack_id, selected from
clusterconfig order by type_name, config_id, version_tag;
config_id |version_tag | stack_id |
selected
---++--+--
5 | cluster-env| 13 |0
9 | cluster-env| 13 |0
18 | cluster-env| 13 |0
56 | cluster-env| 12 |0
102 | cluster-env| 13 |0
107 | cluster-env| 12 |0
113 | cluster-env| 13 |0
118 | cluster-env| 12 |0
152 | cluster-env| 13 |0
157 | cluster-env| 12 |1
10 | ranger-storm-audit | 13 |0
162 | ranger-storm-audit | 12 |1
11 | ranger-storm-plugin-properties | 13 |0
155 | ranger-storm-plugin-properties | 12 |1
12 | ranger-storm-policymgr-ssl | 13 |0
158 | ranger-storm-policymgr-ssl | 12 |1
13 | ranger-storm-security | 13 |0
161 | ranger-storm-security | 12 |1
19 | storm-atlas-application.properties | 13 |0
156 | storm-atlas-application.properties | 12 |1
14 | storm-cluster-log4j| 13 |0
160 | storm-cluster-log4j| 13 |1
15 | storm-env | 13 |0
153 | storm-env | 12 |1
16 | storm-site | 13 |0
154 | storm-site | 12 |1
17 | storm-worker-log4j | 13 |0
159 | storm-worker-log4j | 13 |1
2 | zoo.cfg| 13 |0
6 | zoo.cfg| 13 |1
4 | zookeeper-env | 13 |0
8 | zookeeper-env | 13 |1
3 | zookeeper-log4j| 13 |0
7 | zookeeper-log4j| 13 |1
(34 rows)
{code}
The {{storm-cluster-log4j}} and {{storm-worker-log4j}} are selected with the
wrong stack ID ... they need to be on 12 (HDP 2.6) not 13 (HDP 2.5).
was:
When creating an upgrade, the configurations which are part of
{{ConfigureAction}} are still using the cluster's "current" version when
creating new configs. This needs to be changed to using the source/target
versions of the service in the upgrade.
{code}
ambari=# select config_id, type_name version_tag, stack_id, selected from
clusterconfig order by type_name, config_id, version_tag;
config_id |version_tag | stack_id |
selected
---++--+--
5 | cluster-env| 13 |0
9 | cluster-env| 13 |0
18 | cluster-env| 13 |0
56 | cluster-env| 12 |0
102 | cluster-env| 13 |0
107 | cluster-env| 12 |0
113 | cluster-env| 13 |0
118 | cluster-env| 12 |0
152 | cluster-env| 13 |0
157 | cluster-env| 12 |1
10 | ranger-storm-audit
[jira] [Updated] (AMBARI-21149) Configurations Created During Upgrade Must Use Correct StackId Based on Service
[
https://issues.apache.org/jira/browse/AMBARI-21149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-21149:
-
Attachment: AMBARI-21149.patch
> Configurations Created During Upgrade Must Use Correct StackId Based on
> Service
> ---
>
> Key: AMBARI-21149
> URL: https://issues.apache.org/jira/browse/AMBARI-21149
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: trunk
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-21149.patch
>
>
> When creating an upgrade, the configurations which are part of
> {{ConfigureAction}} are still using the cluster's "current" version when
> creating new configs. This needs to be changed to using the source/target
> versions of the service in the upgrade.
> {code}
> ambari=# select config_id, type_name version_tag, stack_id, selected from
> clusterconfig order by type_name, config_id, version_tag;
>
>
> config_id |version_tag |
> stack_id | selected
> ---++--+--
> 5 | cluster-env| 13 |0
> 9 | cluster-env| 13 |0
> 18 | cluster-env| 13 |0
> 56 | cluster-env| 12 |0
>102 | cluster-env| 13 |0
>107 | cluster-env| 12 |0
>113 | cluster-env| 13 |0
>118 | cluster-env| 12 |0
>152 | cluster-env| 13 |0
>157 | cluster-env| 12 |1
> 10 | ranger-storm-audit | 13 |0
>162 | ranger-storm-audit | 12 |1
> 11 | ranger-storm-plugin-properties | 13 |0
>155 | ranger-storm-plugin-properties | 12 |1
> 12 | ranger-storm-policymgr-ssl | 13 |0
>158 | ranger-storm-policymgr-ssl | 12 |1
> 13 | ranger-storm-security | 13 |0
>161 | ranger-storm-security | 12 |1
> 19 | storm-atlas-application.properties | 13 |0
>156 | storm-atlas-application.properties | 12 |1
> 14 | storm-cluster-log4j| 13 |0
>160 | storm-cluster-log4j| 13 |1
> 15 | storm-env | 13 |0
>153 | storm-env | 12 |1
> 16 | storm-site | 13 |0
>154 | storm-site | 12 |1
> 17 | storm-worker-log4j | 13 |0
>159 | storm-worker-log4j | 13 |1
> 2 | zoo.cfg| 13 |0
> 6 | zoo.cfg| 13 |1
> 4 | zookeeper-env | 13 |0
> 8 | zookeeper-env | 13 |1
> 3 | zookeeper-log4j| 13 |0
> 7 | zookeeper-log4j| 13 |1
> (34 rows)
> {code}
> The {{storm-cluster-log4j}} and {{storm-worker-log4j}} are selected with the
> wrong stack ID ... they need to be on 13 (HDP 2.6) not 12 (HDP 2.5).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-21149) Configurations Created During Upgrade Must Use Correct StackId Based on Service
[
https://issues.apache.org/jira/browse/AMBARI-21149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-21149:
-
Status: Patch Available (was: Open)
> Configurations Created During Upgrade Must Use Correct StackId Based on
> Service
> ---
>
> Key: AMBARI-21149
> URL: https://issues.apache.org/jira/browse/AMBARI-21149
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: trunk
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: trunk
>
> Attachments: AMBARI-21149.patch
>
>
> When creating an upgrade, the configurations which are part of
> {{ConfigureAction}} are still using the cluster's "current" version when
> creating new configs. This needs to be changed to using the source/target
> versions of the service in the upgrade.
> {code}
> ambari=# select config_id, type_name version_tag, stack_id, selected from
> clusterconfig order by type_name, config_id, version_tag;
>
>
> config_id |version_tag |
> stack_id | selected
> ---++--+--
> 5 | cluster-env| 13 |0
> 9 | cluster-env| 13 |0
> 18 | cluster-env| 13 |0
> 56 | cluster-env| 12 |0
>102 | cluster-env| 13 |0
>107 | cluster-env| 12 |0
>113 | cluster-env| 13 |0
>118 | cluster-env| 12 |0
>152 | cluster-env| 13 |0
>157 | cluster-env| 12 |1
> 10 | ranger-storm-audit | 13 |0
>162 | ranger-storm-audit | 12 |1
> 11 | ranger-storm-plugin-properties | 13 |0
>155 | ranger-storm-plugin-properties | 12 |1
> 12 | ranger-storm-policymgr-ssl | 13 |0
>158 | ranger-storm-policymgr-ssl | 12 |1
> 13 | ranger-storm-security | 13 |0
>161 | ranger-storm-security | 12 |1
> 19 | storm-atlas-application.properties | 13 |0
>156 | storm-atlas-application.properties | 12 |1
> 14 | storm-cluster-log4j| 13 |0
>160 | storm-cluster-log4j| 13 |1
> 15 | storm-env | 13 |0
>153 | storm-env | 12 |1
> 16 | storm-site | 13 |0
>154 | storm-site | 12 |1
> 17 | storm-worker-log4j | 13 |0
>159 | storm-worker-log4j | 13 |1
> 2 | zoo.cfg| 13 |0
> 6 | zoo.cfg| 13 |1
> 4 | zookeeper-env | 13 |0
> 8 | zookeeper-env | 13 |1
> 3 | zookeeper-log4j| 13 |0
> 7 | zookeeper-log4j| 13 |1
> (34 rows)
> {code}
> The {{storm-cluster-log4j}} and {{storm-worker-log4j}} are selected with the
> wrong stack ID ... they need to be on 13 (HDP 2.6) not 12 (HDP 2.5).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (AMBARI-21106) Ambari Metrics Anomaly detection prototype.
[ https://issues.apache.org/jira/browse/AMBARI-21106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan resolved AMBARI-21106. Resolution: Fixed Committed to feature branch. > Ambari Metrics Anomaly detection prototype. > --- > > Key: AMBARI-21106 > URL: https://issues.apache.org/jira/browse/AMBARI-21106 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: branch-3.0-ams > > Attachments: AMBARI-21106.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-21149) Configurations Created During Upgrade Must Use Correct StackId Based on Service
Jonathan Hurley created AMBARI-21149:
Summary: Configurations Created During Upgrade Must Use Correct
StackId Based on Service
Key: AMBARI-21149
URL: https://issues.apache.org/jira/browse/AMBARI-21149
Project: Ambari
Issue Type: Task
Components: ambari-server
Affects Versions: trunk
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
Fix For: trunk
When creating an upgrade, the configurations which are part of
{{ConfigureAction}} are still using the cluster's "current" version when
creating new configs. This needs to be changed to using the source/target
versions of the service in the upgrade.
{code}
ambari=# select config_id, type_name version_tag, stack_id, selected from
clusterconfig order by type_name, config_id, version_tag;
config_id |version_tag | stack_id |
selected
---++--+--
5 | cluster-env| 13 |0
9 | cluster-env| 13 |0
18 | cluster-env| 13 |0
56 | cluster-env| 12 |0
102 | cluster-env| 13 |0
107 | cluster-env| 12 |0
113 | cluster-env| 13 |0
118 | cluster-env| 12 |0
152 | cluster-env| 13 |0
157 | cluster-env| 12 |1
10 | ranger-storm-audit | 13 |0
162 | ranger-storm-audit | 12 |1
11 | ranger-storm-plugin-properties | 13 |0
155 | ranger-storm-plugin-properties | 12 |1
12 | ranger-storm-policymgr-ssl | 13 |0
158 | ranger-storm-policymgr-ssl | 12 |1
13 | ranger-storm-security | 13 |0
161 | ranger-storm-security | 12 |1
19 | storm-atlas-application.properties | 13 |0
156 | storm-atlas-application.properties | 12 |1
14 | storm-cluster-log4j| 13 |0
160 | storm-cluster-log4j| 13 |1
15 | storm-env | 13 |0
153 | storm-env | 12 |1
16 | storm-site | 13 |0
154 | storm-site | 12 |1
17 | storm-worker-log4j | 13 |0
159 | storm-worker-log4j | 13 |1
2 | zoo.cfg| 13 |0
6 | zoo.cfg| 13 |1
4 | zookeeper-env | 13 |0
8 | zookeeper-env | 13 |1
3 | zookeeper-log4j| 13 |0
7 | zookeeper-log4j| 13 |1
(34 rows)
{code}
The {{storm-cluster-log4j}} and {{storm-worker-log4j}} are selected with the
wrong stack ID ... they need to be on 13 (HDP 2.6) not 12 (HDP 2.5).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-21130) Delete view privileges from the Users page
[ https://issues.apache.org/jira/browse/AMBARI-21130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj updated AMBARI-21130: -- Attachment: Image1.PNG > Delete view privileges from the Users page > -- > > Key: AMBARI-21130 > URL: https://issues.apache.org/jira/browse/AMBARI-21130 > Project: Ambari > Issue Type: Bug > Components: ambari-admin >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: trunk > > Attachments: AMBARI-21130.patch, Image1.PNG > > > The view permissions are listed in the users page, but in order to remove it, > the user has to drill down to the views page and remove the user from it. To > remove the permission for multiple views for one users, we have to navigate > to different Views page to perform the operation > Including a delete option in the Users page for views privilege will simply > this -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21148) Add a flag to indicate NN restart is rolling
[ https://issues.apache.org/jira/browse/AMBARI-21148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-21148: --- Attachment: AMBARI-21148.patch > Add a flag to indicate NN restart is rolling > > > Key: AMBARI-21148 > URL: https://issues.apache.org/jira/browse/AMBARI-21148 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-21148.patch > > > If restart is rolling stack script should wait for NN to be out of safemode > with large timeout. > Rolling indicates its an HDFS level restart so NN restart needs to be up and > accepting requests before we move on. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21148) Add a flag to indicate NN restart is rolling
[ https://issues.apache.org/jira/browse/AMBARI-21148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-21148: --- Status: Patch Available (was: Open) > Add a flag to indicate NN restart is rolling > > > Key: AMBARI-21148 > URL: https://issues.apache.org/jira/browse/AMBARI-21148 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-21148.patch > > > If restart is rolling stack script should wait for NN to be out of safemode > with large timeout. > Rolling indicates its an HDFS level restart so NN restart needs to be up and > accepting requests before we move on. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-21148) Add a flag to indicate NN restart is rolling
Vitaly Brodetskyi created AMBARI-21148: -- Summary: Add a flag to indicate NN restart is rolling Key: AMBARI-21148 URL: https://issues.apache.org/jira/browse/AMBARI-21148 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 3.0.0 Reporter: Vitaly Brodetskyi Assignee: Vitaly Brodetskyi Priority: Critical Fix For: 3.0.0 If restart is rolling stack script should wait for NN to be out of safemode with large timeout. Rolling indicates its an HDFS level restart so NN restart needs to be up and accepting requests before we move on. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-21137) Blueprint export should allow tokenized values in SingleHostUpdater
[
https://issues.apache.org/jira/browse/AMBARI-21137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1603#comment-1603
]
Hadoop QA commented on AMBARI-21137:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12870136/AMBARI-21137.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/11623//console
This message is automatically generated.
> Blueprint export should allow tokenized values in SingleHostUpdater
> ---
>
> Key: AMBARI-21137
> URL: https://issues.apache.org/jira/browse/AMBARI-21137
> Project: Ambari
> Issue Type: Bug
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-21137.patch
>
>
> During upgrade Biginsights stack tokenizes value for
> 'yarn.resourcemanager.webapp.https.address', therefore this property gets
> removed by SingleHostUpdater during blueprint export. Next time when the
> blueprint is used to create a cluster, this property is assigned default
> value 'localhost' and exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-19369) Add Kerberos HTTP SPNEGO authentication support to Hadoop/hbase/kafka/storm sinks
[ https://issues.apache.org/jira/browse/AMBARI-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qin Liu updated AMBARI-19369: - Attachment: AMBARI-19369.patch > Add Kerberos HTTP SPNEGO authentication support to Hadoop/hbase/kafka/storm > sinks > - > > Key: AMBARI-19369 > URL: https://issues.apache.org/jira/browse/AMBARI-19369 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics, ambari-server >Affects Versions: 2.2.0 >Reporter: Qin Liu >Assignee: Qin Liu > Fix For: trunk > > Attachments: AMBARI-19369.patch > > > This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to > authenticate". > In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari > Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But > Hadoop/hbase/kafka/storm sinks, clients of Ambari Metrics Collector, > currently do not support Kerberos HTTP SPNEGO authentication. > e.g., > /var/log/hadoop-yarn/yarn/yarn-yarn-timelineserver-.log: > 2016-12-16 22:25:29,471 INFO timeline.HadoopTimelineMetricsSink > (AbstractTimelineMetricsSink.java:emitMetricsJson(169)) - Unable to POST > metrics to collector, http://metrics-collector:6188/ws/v1/timeline/metrics, > statusCode = 401 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-19369) Add Kerberos HTTP SPNEGO authentication support to Hadoop/hbase/kafka/storm sinks
[ https://issues.apache.org/jira/browse/AMBARI-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qin Liu updated AMBARI-19369: - Status: Patch Available (was: Open) > Add Kerberos HTTP SPNEGO authentication support to Hadoop/hbase/kafka/storm > sinks > - > > Key: AMBARI-19369 > URL: https://issues.apache.org/jira/browse/AMBARI-19369 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics, ambari-server >Affects Versions: 2.2.0 >Reporter: Qin Liu >Assignee: Qin Liu > Fix For: trunk > > Attachments: AMBARI-19369.patch > > > This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to > authenticate". > In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari > Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But > Hadoop/hbase/kafka/storm sinks, clients of Ambari Metrics Collector, > currently do not support Kerberos HTTP SPNEGO authentication. > e.g., > /var/log/hadoop-yarn/yarn/yarn-yarn-timelineserver-.log: > 2016-12-16 22:25:29,471 INFO timeline.HadoopTimelineMetricsSink > (AbstractTimelineMetricsSink.java:emitMetricsJson(169)) - Unable to POST > metrics to collector, http://metrics-collector:6188/ws/v1/timeline/metrics, > statusCode = 401 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-19369) Add Kerberos HTTP SPNEGO authentication support to Hadoop/hbase/kafka/storm sinks
[ https://issues.apache.org/jira/browse/AMBARI-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qin Liu updated AMBARI-19369: - Status: Open (was: Patch Available) > Add Kerberos HTTP SPNEGO authentication support to Hadoop/hbase/kafka/storm > sinks > - > > Key: AMBARI-19369 > URL: https://issues.apache.org/jira/browse/AMBARI-19369 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics, ambari-server >Affects Versions: 2.2.0 >Reporter: Qin Liu >Assignee: Qin Liu > Fix For: trunk > > Attachments: AMBARI-19369.patch > > > This is a subtask of AMBARI-14384 "Ambari Metrics doesn't use SPNEGO to > authenticate". > In a Kerberos enabled cluster with SPNEGO enabled on Hadoop APIs, Ambari > Metrics Collector web-console will be Kerberos HTTP SPNEGO enabled too. But > Hadoop/hbase/kafka/storm sinks, clients of Ambari Metrics Collector, > currently do not support Kerberos HTTP SPNEGO authentication. > e.g., > /var/log/hadoop-yarn/yarn/yarn-yarn-timelineserver-.log: > 2016-12-16 22:25:29,471 INFO timeline.HadoopTimelineMetricsSink > (AbstractTimelineMetricsSink.java:emitMetricsJson(169)) - Unable to POST > metrics to collector, http://metrics-collector:6188/ws/v1/timeline/metrics, > statusCode = 401 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21106) Ambari Metrics Anomaly detection prototype.
[ https://issues.apache.org/jira/browse/AMBARI-21106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-21106: - Fix Version/s: (was: 3.0.0) > Ambari Metrics Anomaly detection prototype. > --- > > Key: AMBARI-21106 > URL: https://issues.apache.org/jira/browse/AMBARI-21106 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: branch-3.0-ams > > Attachments: AMBARI-21106.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21147) Update Database Access Layer to Support New Database Schema for Improved User Account Management
[
https://issues.apache.org/jira/browse/AMBARI-21147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-21147:
--
Labels: user_management (was: )
> Update Database Access Layer to Support New Database Schema for Improved User
> Account Management
>
>
> Key: AMBARI-21147
> URL: https://issues.apache.org/jira/browse/AMBARI-21147
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Labels: user_management
> Fix For: 3.0.0
>
>
> Update Database Access Layer to Support New Database Schema for Improved User
> Account Management.
> * Update {{org.apache.ambari.server.orm.entities.UserEntity}}
> * Update {{org.apache.ambari.server.orm.dao.UserDAO}}
> * Add {{org.apache.ambari.server.orm.entities.UserAuthenticationEntity}}
> * Add {{org.apache.ambari.server.orm.dao.UserAuthenticationDAO}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMBARI-21106) Ambari Metrics Anomaly detection prototype.
[ https://issues.apache.org/jira/browse/AMBARI-21106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029902#comment-16029902 ] Siddharth Wagle commented on AMBARI-21106: -- +1 for commit to branch. > Ambari Metrics Anomaly detection prototype. > --- > > Key: AMBARI-21106 > URL: https://issues.apache.org/jira/browse/AMBARI-21106 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: branch-3.0-ams > > Attachments: AMBARI-21106.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20859) Improve User Account Management Within Ambari
[ https://issues.apache.org/jira/browse/AMBARI-20859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Levas updated AMBARI-20859: -- Labels: authentication security user_management (was: authentication security) > Improve User Account Management Within Ambari > - > > Key: AMBARI-20859 > URL: https://issues.apache.org/jira/browse/AMBARI-20859 > Project: Ambari > Issue Type: Epic > Components: ambari-server, ambari-web >Affects Versions: 3.0.0 >Reporter: Robert Levas >Assignee: Robert Levas > Labels: authentication, security, user_management > Fix For: 3.0.0 > > > As of Ambari 2.4, user management is confusing and tends to lead to > inconsistent results during synchronization and authentication. With the > addition of new mechanisms such as Kerberos and PAM, this will only get > worse. Therefore, there is a need to rework how Ambari manages users to > ensure that new authentication facilities are easily integrated. > The following problems need to be solved: > * *Case-sensitivity* > Some authentication sources are case sensitive and some are not. Ambari > inconsistently handles the case of user names leading to confusing where user > metadata is being created or being overwritten. This issue extends from the > front end through the backend and to the database layer. > * *Username Collisions* > There are several cases where username collisions occur. One is where a > username exists as a local user as well as an external user. For example, > the initial administrator account has is a local user account with the > username of "admin". There may also be an external user account with the > username "admin". In some cases Ambari will treat both accounts as the same > user, converting the local account during synchronization operation to an > LDAP account. However in other cases, Ambari will treat the accounts as > separate users and create a separate account. > * *REST API* > Due to the implementation of the user resource in the REST API, there is no > way to distinguish between user accounts with the same username and different > data sources. For example usera/LOCAL vs usera/LDAP. This is because the > primary key for user resources is only the username field. This make > managing users confusing since the REST API entrypoint for user resources is > /api/v1/users/:USERNAME and there is no way to retrieve or set the details > for a specific user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20907) Create Database Schema for Improved User Account Management
[
https://issues.apache.org/jira/browse/AMBARI-20907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20907:
--
Labels: user_management (was: )
> Create Database Schema for Improved User Account Management
> ---
>
> Key: AMBARI-20907
> URL: https://issues.apache.org/jira/browse/AMBARI-20907
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Labels: user_management
> Fix For: 3.0.0
>
> Attachments: AMBARI-20907_branch-feature-AMBARI-20859_02.patch,
> AMBARI-20907_branch-feature-AMBARI-20859.patch
>
>
> User management tables in the DB should be:
> *{{users}}*
> ||Name||Type||Description||
> |user_id|INTEGER|Internal unique identifier|
> |principal_id|INTEGER|Foreign key from adminprincipal table|
> |user_name|VARCHAR|Unique, case-insensitive, login identifier expected to be
> used when logging into Ambari|
> |active|BOOLEAN|Active/not active flag|
> |consecutive_failures|INTEGER|The number a failed authorization attempts
> since the last successful authentication|
> |active_widgets_layout|VARCHAR| |
> |display_name|VARCHAR|Cosmetic name value to show the user in user interfaces|
> |local_username|VARCHAR|Case-sensitive username to use when impersonating
> user in facilities like Ambari Views|
> |create_time|TIMESTAMP|Creation time for this account in Ambari|
> * Primary Key: {{user_id}}
> * Foreign Key: {{principal_id}} -> {{adminprincipal.principal_id}}
> *{{user_authentication}}*
> ||Name||Type||Description||
> |user_authentication_id|INTEGER|Primary key for this table|
> |user_id|INTEGER|Foreign key from users table|
> |authentication_type|VARCHAR|Type of authentication system - LOCAL, LDAP,
> KERBEROS, JTW, PAM, etc...
> |authentication_key|VARCHAR|Type-specific key (or identifier):
> * LOCAL: the user's password (digest)
> * LDAP: the user’s distinguished name
> * KERBEROS: the user’s principal
> * etc...|
> |create_time|TIMESTAMP|Creation time of this record
> |update_time|TIMESTAMP|Update time for this record, can be used to enforce
> password retention times|
> * Primary Key: {{user_authentication_id}}
> * Foreign Key: {{user_id}} -> {{users.user_id}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMBARI-21147) Update Database Access Layer to Support New Database Schema for Improved User Account Management
Robert Levas created AMBARI-21147:
-
Summary: Update Database Access Layer to Support New Database
Schema for Improved User Account Management
Key: AMBARI-21147
URL: https://issues.apache.org/jira/browse/AMBARI-21147
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 3.0.0
Reporter: Robert Levas
Assignee: Robert Levas
Fix For: 3.0.0
Update Database Access Layer to Support New Database Schema for Improved User
Account Management.
* Update {{org.apache.ambari.server.orm.entities.UserEntity}}
* Update {{org.apache.ambari.server.orm.dao.UserDAO}}
* Add {{org.apache.ambari.server.orm.entities.UserAuthenticationEntity}}
* Add {{org.apache.ambari.server.orm.dao.UserAuthenticationDAO}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20907) Create Database Schema for Improved User Account Management
[
https://issues.apache.org/jira/browse/AMBARI-20907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-20907:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to branch-feature-AMBARI-20859
{noformat}
commit 7460cebf90e8f77b3b14457a64423ebc3ba028cc
Author: Robert Levas
Date: Tue May 30 14:29:02 2017 -0400
{noformat}
> Create Database Schema for Improved User Account Management
> ---
>
> Key: AMBARI-20907
> URL: https://issues.apache.org/jira/browse/AMBARI-20907
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-20907_branch-feature-AMBARI-20859_02.patch,
> AMBARI-20907_branch-feature-AMBARI-20859.patch
>
>
> User management tables in the DB should be:
> *{{users}}*
> ||Name||Type||Description||
> |user_id|INTEGER|Internal unique identifier|
> |principal_id|INTEGER|Foreign key from adminprincipal table|
> |user_name|VARCHAR|Unique, case-insensitive, login identifier expected to be
> used when logging into Ambari|
> |active|BOOLEAN|Active/not active flag|
> |consecutive_failures|INTEGER|The number a failed authorization attempts
> since the last successful authentication|
> |active_widgets_layout|VARCHAR| |
> |display_name|VARCHAR|Cosmetic name value to show the user in user interfaces|
> |local_username|VARCHAR|Case-sensitive username to use when impersonating
> user in facilities like Ambari Views|
> |create_time|TIMESTAMP|Creation time for this account in Ambari|
> * Primary Key: {{user_id}}
> * Foreign Key: {{principal_id}} -> {{adminprincipal.principal_id}}
> *{{user_authentication}}*
> ||Name||Type||Description||
> |user_authentication_id|INTEGER|Primary key for this table|
> |user_id|INTEGER|Foreign key from users table|
> |authentication_type|VARCHAR|Type of authentication system - LOCAL, LDAP,
> KERBEROS, JTW, PAM, etc...
> |authentication_key|VARCHAR|Type-specific key (or identifier):
> * LOCAL: the user's password (digest)
> * LDAP: the user’s distinguished name
> * KERBEROS: the user’s principal
> * etc...|
> |create_time|TIMESTAMP|Creation time of this record
> |update_time|TIMESTAMP|Update time for this record, can be used to enforce
> password retention times|
> * Primary Key: {{user_authentication_id}}
> * Foreign Key: {{user_id}} -> {{users.user_id}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-21106) Ambari Metrics Anomaly detection prototype.
[ https://issues.apache.org/jira/browse/AMBARI-21106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-21106: - Fix Version/s: (was: 3.0.0) branch-3.0-ams > Ambari Metrics Anomaly detection prototype. > --- > > Key: AMBARI-21106 > URL: https://issues.apache.org/jira/browse/AMBARI-21106 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: 3.0.0, branch-3.0-ams > > Attachments: AMBARI-21106.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21106) Ambari Metrics Anomaly detection prototype.
[ https://issues.apache.org/jira/browse/AMBARI-21106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-21106: - Fix Version/s: 3.0.0 > Ambari Metrics Anomaly detection prototype. > --- > > Key: AMBARI-21106 > URL: https://issues.apache.org/jira/browse/AMBARI-21106 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan > Fix For: 3.0.0, branch-3.0-ams > > Attachments: AMBARI-21106.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[
https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029772#comment-16029772
]
Robert Levas commented on AMBARI-20769:
---
[~patel...@us.ibm.com]...
Thanks for the clarification on this. I didn't know about the
{{/clusters/:CLUSTER_NAME/request_schedules'}} entry point. My guess is that
this was missed when adding the new RBAC features.
So what needs to be done is to add this URL pattern to the list tested in
{{org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter#authorizationPerformedInternally}}.
Then add the correct authorization logic to
{{org.apache.ambari.server.controller.internal.RequestScheduleResourceProvider}}.
Unfortunately, this resource provider handles generic requests, so logic will
need to be implemented to determine what is being asked for and then perform
the appropriate authorization check.
> Recommission fails for Cluster Operators, Service Adminstrators and Service
> Operators
> -
>
> Key: AMBARI-20769
> URL: https://issues.apache.org/jira/browse/AMBARI-20769
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-20769-codeSnippet-for-error.png,
> AMBARI-20769-codeSnippet.png, cluster_operator_1_recommission.png,
> cluster_operator_2_recommission.png
>
>
> Steps to reproduce:
> 1. Create 4 local users assign one to each of the following roles:
> - Cluster Administrator
> - Cluster Operator
> - Service Administrator
> - Service Operator
> 2. Logout and login back as one of the above created users.
> 3. Decommission a node, the operation is successful with the Background
> Operation pop-up showing the decommissioning operation being performed.
> 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is
> able to successfully perform this step. For the rest of the roles mentioned
> in step-1, you will see the following behavior:
> - The background operation pop-up shows up with "0 Operations" in progress.
> - The background operation pop-up disappears and you see the login page
> momentarily.
> - The main Dashboard is seen immediately after that and the node is still in
> the "Decommissioned" state.
> Desired Behavior:
> All the roles mentioned in step-1 must be able to successfully recommission
> the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[
https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029772#comment-16029772
]
Robert Levas edited comment on AMBARI-20769 at 5/30/17 5:17 PM:
[~patel...@us.ibm.com]...
Thanks for the clarification on this. I didn't know about the
{{/clusters/:CLUSTER_NAME/request_schedules}} entry point. My guess is that
this was missed when adding the new RBAC features.
So what needs to be done is to add this URL pattern to the list tested in
{{org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter#authorizationPerformedInternally}}.
Then add the correct authorization logic to
{{org.apache.ambari.server.controller.internal.RequestScheduleResourceProvider}}.
Unfortunately, this resource provider handles generic requests, so logic will
need to be implemented to determine what is being asked for and then perform
the appropriate authorization check.
was (Author: rlevas):
[~patel...@us.ibm.com]...
Thanks for the clarification on this. I didn't know about the
{{/clusters/:CLUSTER_NAME/request_schedules'}} entry point. My guess is that
this was missed when adding the new RBAC features.
So what needs to be done is to add this URL pattern to the list tested in
{{org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter#authorizationPerformedInternally}}.
Then add the correct authorization logic to
{{org.apache.ambari.server.controller.internal.RequestScheduleResourceProvider}}.
Unfortunately, this resource provider handles generic requests, so logic will
need to be implemented to determine what is being asked for and then perform
the appropriate authorization check.
> Recommission fails for Cluster Operators, Service Adminstrators and Service
> Operators
> -
>
> Key: AMBARI-20769
> URL: https://issues.apache.org/jira/browse/AMBARI-20769
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-20769-codeSnippet-for-error.png,
> AMBARI-20769-codeSnippet.png, cluster_operator_1_recommission.png,
> cluster_operator_2_recommission.png
>
>
> Steps to reproduce:
> 1. Create 4 local users assign one to each of the following roles:
> - Cluster Administrator
> - Cluster Operator
> - Service Administrator
> - Service Operator
> 2. Logout and login back as one of the above created users.
> 3. Decommission a node, the operation is successful with the Background
> Operation pop-up showing the decommissioning operation being performed.
> 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is
> able to successfully perform this step. For the rest of the roles mentioned
> in step-1, you will see the following behavior:
> - The background operation pop-up shows up with "0 Operations" in progress.
> - The background operation pop-up disappears and you see the login page
> momentarily.
> - The main Dashboard is seen immediately after that and the node is still in
> the "Decommissioned" state.
> Desired Behavior:
> All the roles mentioned in step-1 must be able to successfully recommission
> the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (AMBARI-18528) Need a way to escape config values that contain $
[
https://issues.apache.org/jira/browse/AMBARI-18528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603928#comment-15603928
]
Ted Yu edited comment on AMBARI-18528 at 5/30/17 4:56 PM:
--
Escaping the dollar sign automatically is the desirable solution.
was (Author: yuzhih...@gmail.com):
Escaping the dollar sign automatically is the desirable solution .
> Need a way to escape config values that contain $
> -
>
> Key: AMBARI-18528
> URL: https://issues.apache.org/jira/browse/AMBARI-18528
> Project: Ambari
> Issue Type: Bug
>Reporter: Ted Yu
> Labels: zookeeper
>
> We tried specifying auth_to_local in zookeeper env input box:
> {code}
> export SERVER_JVMFLAGS="$SERVER_JVMFLAGS
> -Dzookeeper.security.auth_to_local=RULE:[2:$1@$0](hb...@c.net)s/.*/hbase/
> -Djava.security.auth.login.config={{zk_server_jaas_file}}"
> {code}
> However, when zookeeper quorum starts, the rule got interrupted with
> zkServer.sh
> We should add the capability of specifying auth_to_local in Ambari UI
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-17346) Dependent components should be shutdown before stopping hdfs
[ https://issues.apache.org/jira/browse/AMBARI-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-17346: Description: Sometimes admin shuts down hdfs first, then hbase. By the time hbase is shutdown, no data can be persisted (including metadata). This results in large number of inconsistencies when hbase cluster is brought back up. Before hdfs is shutdown, the components dependent on hdfs should be shutdown first. was: Sometimes admin shuts down hdfs first, then hbase. By the time hbase is shutdown, no data can be persisted (including metadata). This results in large number of inconsistencies when hbase cluster is brought back up. Before hdfs is shutdown, the components dependent on hdfs should be shutdown first. > Dependent components should be shutdown before stopping hdfs > > > Key: AMBARI-17346 > URL: https://issues.apache.org/jira/browse/AMBARI-17346 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > Sometimes admin shuts down hdfs first, then hbase. > By the time hbase is shutdown, no data can be persisted (including metadata). > This results in large number of inconsistencies when hbase cluster is brought > back up. > Before hdfs is shutdown, the components dependent on hdfs should be shutdown > first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (AMBARI-18952) Register BackupObserver and BackupHFileCleaner
[ https://issues.apache.org/jira/browse/AMBARI-18952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884466#comment-15884466 ] Ted Yu edited comment on AMBARI-18952 at 5/30/17 4:52 PM: -- Note: There is cost when BackupObserver is registered - it would poll backup table (at the end of bulk load per region) for whether the underlying table has gone thru full backup. was (Author: yuzhih...@gmail.com): Note: There is cost when BackupObserver is registered - it would poll backup table (at the end of bulk load per region) for whether the underlying table has gone thru full backup. > Register BackupObserver and BackupHFileCleaner > -- > > Key: AMBARI-18952 > URL: https://issues.apache.org/jira/browse/AMBARI-18952 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > Over in HBASE-14417, two new classes are added. > org.apache.hadoop.hbase.backup.BackupHFileCleaner should be registered > through hbase.master.hfilecleaner.plugins . It is responsible for keeping > bulk loaded hfiles so that incremental backup can pick them up. > org.apache.hadoop.hbase.backup.BackupObserver should be registered through > hbase.coprocessor.region.classes > It is notified when bulk load completes and writes records into hbase:backup > table. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-18574) Set hbase.hregion.memstore.chunkpool.maxsize to 1.0
[
https://issues.apache.org/jira/browse/AMBARI-18574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated AMBARI-18574:
Description:
The default value for hbase.hregion.memstore.chunkpool.maxsize is:
{code}
final static float POOL_MAX_SIZE_DEFAULT = 0.0f;
{code}
This would result in chunk pool being disabled, leading to excessive
MemStoreLAB chunk allocations.
Ambari should set the value to 1.0
was:
The default value for hbase.hregion.memstore.chunkpool.maxsize is:
{code}
final static float POOL_MAX_SIZE_DEFAULT = 0.0f;
{code}
This would result in chunk pool being disabled, leading to excessive
MemStoreLAB chunk allocations.
Ambari should set the value to 1.0
> Set hbase.hregion.memstore.chunkpool.maxsize to 1.0
> ---
>
> Key: AMBARI-18574
> URL: https://issues.apache.org/jira/browse/AMBARI-18574
> Project: Ambari
> Issue Type: Bug
>Reporter: Ted Yu
>
> The default value for hbase.hregion.memstore.chunkpool.maxsize is:
> {code}
> final static float POOL_MAX_SIZE_DEFAULT = 0.0f;
> {code}
> This would result in chunk pool being disabled, leading to excessive
> MemStoreLAB chunk allocations.
> Ambari should set the value to 1.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMBARI-20945) Configuration parameter 'hdfs-site' was not found error when AMS rootdir is on s3a
[
https://issues.apache.org/jira/browse/AMBARI-20945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated AMBARI-20945:
Description:
When I specify AMS rootdir to be on s3a and restart AMS, I would get the
following error:
{code}
Traceback (most recent call last):
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
line 86, in
AmsCollector().execute()
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 315, in execute
method(env)
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 817, in restart
self.start(env)
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
line 48, in start
self.configure(env, action = 'start') # for security
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 118, in locking_configure
original_configure(obj, *args, **kw)
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
line 43, in configure
hbase('master', action)
File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py",
line 89, in thunk
return fn(*args, **kwargs)
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/hbase.py",
line 222, in hbase
dfs_type=params.dfs_type
File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
line 155, in __init__
self.env.run()
File
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
line 160, in run
self.run_action(resource, action)
File
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
line 119, in run_action
provider = provider_class(resource)
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
line 503, in __init__
self.assert_parameter_is_set('hdfs_site')
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
line 575, in assert_parameter_is_set
if not getattr(self.resource, parameter_name):
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/config_dictionary.py",
line 73, in __getattr__
raise Fail("Configuration parameter '" + self.name + "' was not found in
configurations dictionary!")
resource_management.core.exceptions.Fail: Configuration parameter 'hdfs-site'
was not found in configurations dictionary!
{code}
was:
When I specify AMS rootdir to be on s3a and restart AMS, I would get the
following error:
{code}
Traceback (most recent call last):
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
line 86, in
AmsCollector().execute()
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 315, in execute
method(env)
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 817, in restart
self.start(env)
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
line 48, in start
self.configure(env, action = 'start') # for security
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 118, in locking_configure
original_configure(obj, *args, **kw)
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_collector.py",
line 43, in configure
hbase('master', action)
File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py",
line 89, in thunk
return fn(*args, **kwargs)
File
"/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/hbase.py",
line 222, in hbase
dfs_type=params.dfs_type
File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
line 155, in __init__
self.env.run()
File
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
line 160, in run
self.run_action(resource, action)
File
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
line 119, in run_action
provider = provider_class(resource)
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
line 503, in __init__
self.assert_parameter_is_set('hdfs_site')
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/providers/hdfs_resource.py",
line 575, in assert_parameter_is_set
if not getattr(self.resource, parameter_name):
File
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/config_dictionary.py",
line 73, in __getattr__
raise Fail("Configuration parameter '" + self.name + "' was not
[jira] [Updated] (AMBARI-21144) Create .md files to describe Log Search input configurations
[ https://issues.apache.org/jira/browse/AMBARI-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-21144: Attachment: AMBARI-21144.patch > Create .md files to describe Log Search input configurations > > > Key: AMBARI-21144 > URL: https://issues.apache.org/jira/browse/AMBARI-21144 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 3.0.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely >Priority: Minor > Fix For: 3.0.0 > > Attachments: AMBARI-21144.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21144) Create .md files to describe Log Search input configurations
[ https://issues.apache.org/jira/browse/AMBARI-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely updated AMBARI-21144: Status: Patch Available (was: In Progress) > Create .md files to describe Log Search input configurations > > > Key: AMBARI-21144 > URL: https://issues.apache.org/jira/browse/AMBARI-21144 > Project: Ambari > Issue Type: Improvement > Components: ambari-logsearch >Affects Versions: 3.0.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely >Priority: Minor > Fix For: 3.0.0 > > Attachments: AMBARI-21144.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21146) Knox JAAS configuration file should not allow the Kerberos ticket cache to be used when establishing its identity on startup
[
https://issues.apache.org/jira/browse/AMBARI-21146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Attila Magyar updated AMBARI-21146:
---
Description:
The JAAS configuration for Knox allows the interactive user's ticket cache to
be used to establish the service's identity when starting up. This is
problematic and potentially confusing. To prevent this, the JAAS config should
be set as follows:
{code}
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
renewTGT=false
doNotPrompt=true
useKeyTab=true
keyTab="/etc/security/keytabs/knox.service.keytab"
principal="knox/c6403.ambari.apache@example.com"
storeKey=true
useTicketCache=false;
};
{code}
Note: the keytab file and principal name values need to be set based on the
relevant Kerberos configuration.
was:
The JAAS configuration for Knox allows the interactive user's ticket cache to
be used to establish the service's identity when starting up. This is
problematic and potentially confusing. To prevent this, the JAAS config should
be set as follows:
{code}
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
renewTGT=false
doNotPrompt=true
useKeyTab=true
keyTab="/etc/security/keytabs/knox.service.keytab"
principal="knox/c6403.ambari.apache@example.com"
storeKey=true
useTicketCache=false;
};
{code}
> Knox JAAS configuration file should not allow the Kerberos ticket cache to be
> used when establishing its identity on startup
>
>
> Key: AMBARI-21146
> URL: https://issues.apache.org/jira/browse/AMBARI-21146
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: Attila Magyar
>Assignee: Attila Magyar
> Fix For: 2.5.2
>
>
> The JAAS configuration for Knox allows the interactive user's ticket cache to
> be used to establish the service's identity when starting up. This is
> problematic and potentially confusing. To prevent this, the JAAS config
> should be set as follows:
> {code}
> com.sun.security.jgss.initiate {
> com.sun.security.auth.module.Krb5LoginModule required
> renewTGT=false
> doNotPrompt=true
> useKeyTab=true
> keyTab="/etc/security/keytabs/knox.service.keytab"
> principal="knox/c6403.ambari.apache@example.com"
> storeKey=true
> useTicketCache=false;
> };
> {code}
> Note: the keytab file and principal name values need to be set based on the
> relevant Kerberos configuration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMBARI-21146) Knox JAAS configuration file should not allow the Kerberos ticket cache to be used when establishing its identity on startup
Attila Magyar created AMBARI-21146:
--
Summary: Knox JAAS configuration file should not allow the
Kerberos ticket cache to be used when establishing its identity on startup
Key: AMBARI-21146
URL: https://issues.apache.org/jira/browse/AMBARI-21146
Project: Ambari
Issue Type: Bug
Affects Versions: 1.7.0
Reporter: Attila Magyar
Assignee: Attila Magyar
Fix For: 2.5.2
The JAAS configuration for Knox allows the interactive user's ticket cache to
be used to establish the service's identity when starting up. This is
problematic and potentially confusing. To prevent this, the JAAS config should
be set as follows:
{code}
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
renewTGT=false
doNotPrompt=true
useKeyTab=true
keyTab="/etc/security/keytabs/knox.service.keytab"
principal="knox/c6403.ambari.apache@example.com"
storeKey=true
useTicketCache=false;
};
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMBARI-21145) allow wildcard for log directory folder in the path component of Logfeeder input
Keta Patel created AMBARI-21145: --- Summary: allow wildcard for log directory folder in the path component of Logfeeder input Key: AMBARI-21145 URL: https://issues.apache.org/jira/browse/AMBARI-21145 Project: Ambari Issue Type: Improvement Components: logsearch Affects Versions: 2.5.0 Reporter: Keta Patel Assignee: Keta Patel Priority: Minor The wildcard processing in Logfeeder is carried out only for the last file component in the log path. For a few services, where there are multiple log folders and log files from each of the folders is desired to be parsed in Logsearch UI, the lack of a wildcard processing for the previous portions becomes an issue. Hence, introducing wildcard processing for the log directory part of the "path" in the Logfeeder's input for the service will help resolve this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-17715) Not able to login using KnoxSSO if local/ldap Ambari User with same name exists
[ https://issues.apache.org/jira/browse/AMBARI-17715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029284#comment-16029284 ] Robert Levas commented on AMBARI-17715: --- [~lars_francke]... I think that this has all been resolved, and with AMBARI-20859, we should be able to handle JWT a bit better. As of Ambari 2.4.0 (or maybe a slightly later version), a user may authenticate with Ambari using JWT via Knox causing one of the following to happen: * The user has been previously sync'd with the same LDAP server as Knox and the user is allowed in * The user does not exist in the Ambari database and is automatically created Have you found that this is not the case? > Not able to login using KnoxSSO if local/ldap Ambari User with same name > exists > --- > > Key: AMBARI-17715 > URL: https://issues.apache.org/jira/browse/AMBARI-17715 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Myroslav Papirkovskyi >Assignee: Myroslav Papirkovskyi >Priority: Blocker > Fix For: 2.4.0 > > > Due to API limitations we cannot login JWT user if LDAP/LOCAL one with same > name already exists. > We should temporary threat JWT users as LDAP ones and rely on ldap-sync > process for user creation, as this is most frequent configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-17715) Not able to login using KnoxSSO if local/ldap Ambari User with same name exists
[ https://issues.apache.org/jira/browse/AMBARI-17715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029250#comment-16029250 ] Lars Francke commented on AMBARI-17715: --- Just bumping this again. [~rlevas] > Not able to login using KnoxSSO if local/ldap Ambari User with same name > exists > --- > > Key: AMBARI-17715 > URL: https://issues.apache.org/jira/browse/AMBARI-17715 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Myroslav Papirkovskyi >Assignee: Myroslav Papirkovskyi >Priority: Blocker > Fix For: 2.4.0 > > > Due to API limitations we cannot login JWT user if LDAP/LOCAL one with same > name already exists. > We should temporary threat JWT users as LDAP ones and rely on ldap-sync > process for user creation, as this is most frequent configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-21140) Support CREATE/UPDATE/DELETE of topology, hashes and some events format changes
[ https://issues.apache.org/jira/browse/AMBARI-21140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-21140: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to branch-3.0-perf > Support CREATE/UPDATE/DELETE of topology, hashes and some events format > changes > --- > > Key: AMBARI-21140 > URL: https://issues.apache.org/jira/browse/AMBARI-21140 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-21140.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
