[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Status: Patch Available (was: In Progress)
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15682) Views: Provide refresh list of available views with newly deployed views w/o restart
[ https://issues.apache.org/jira/browse/AMBARI-15682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15682: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk branch. > Views: Provide refresh list of available views with newly deployed views w/o > restart > > > Key: AMBARI-15682 > URL: https://issues.apache.org/jira/browse/AMBARI-15682 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.0 >Reporter: Ashwin Rajeev >Assignee: Ashwin Rajeev > Fix For: 2.4.0 > > Attachments: AMBARI-15682.2.trunk.patch, AMBARI-15682.3.trunk.patch, > AMBARI-15682.4.trunk.patch, AMBARI-15682.5.trunk.patch, > AMBARI-15682.branch-2.2.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > Ambari is able to detect that there are new views available (dynamically). > However, there does not appear to be a mechanism to perform a refresh. > What makes the most sense is to refresh everytime the admin view page is > accessed and also provide a manual refresh button > User should be able to: > 1) Place a new view package on Ambari Server > 2) Do not restart Ambari Server > 3) While in Admin View, user clicks refresh in browser on Views section > 4) Newly deployed view is shown. User can create use the view to create > instances, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15735) Check if persist data 'wizard-data' is removed upon exiting any wizard
[ https://issues.apache.org/jira/browse/AMBARI-15735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229939#comment-15229939 ] Andrii Tkach commented on AMBARI-15735: --- committed to trunk > Check if persist data 'wizard-data' is removed upon exiting any wizard > -- > > Key: AMBARI-15735 > URL: https://issues.apache.org/jira/browse/AMBARI-15735 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.0 > > Attachments: AMBARI-15735.patch > > > Sometimes 'wizard-data' is not removed removed upon exiting any wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15735) Check if persist data 'wizard-data' is removed upon exiting any wizard
[ https://issues.apache.org/jira/browse/AMBARI-15735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-15735: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Check if persist data 'wizard-data' is removed upon exiting any wizard > -- > > Key: AMBARI-15735 > URL: https://issues.apache.org/jira/browse/AMBARI-15735 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.0 > > Attachments: AMBARI-15735.patch > > > Sometimes 'wizard-data' is not removed removed upon exiting any wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230023#comment-15230023
]
Sebastian Toader commented on AMBARI-15744:
---
Committed to trunk:
{code}
commit 1cc4a20b33157de8c547929321567911a13d8942
Author: Toader, Sebastian
Date: Thu Apr 7 11:32:42 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (stoader)
{code}
Committed to branch-2.2:
{code}
commit 5edcf8a275a7ec6f80a6d4456942103e3c8c006c
Author: Toader, Sebastian
Date: Thu Apr 7 11:56:52 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (stoader)
{code}
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15753) Ambari Views : Reverting the changes for separation of logs in ambari branch-2.2
Nitiraj Singh Rathore created AMBARI-15753: -- Summary: Ambari Views : Reverting the changes for separation of logs in ambari branch-2.2 Key: AMBARI-15753 URL: https://issues.apache.org/jira/browse/AMBARI-15753 Project: Ambari Issue Type: Bug Components: ambari-views Affects Versions: 2.2.0 Reporter: Nitiraj Singh Rathore Assignee: Nitiraj Singh Rathore Revert changes of AMBARI-14084 from branch-2.2 as it is wrong branch for these changes. Create a new patch which will revert these changes and apply only to branch-2.2 of ambari. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15730) Kerberos "Test Connection" button should not be shown on the host configs page
[
https://issues.apache.org/jira/browse/AMBARI-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230046#comment-15230046
]
Hadoop QA commented on AMBARI-15730:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797282/AMBARI-15730.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6269//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6269//console
This message is automatically generated.
> Kerberos "Test Connection" button should not be shown on the host configs page
> --
>
> Key: AMBARI-15730
> URL: https://issues.apache.org/jira/browse/AMBARI-15730
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: 1Px55.jpg, AMBARI-15730.patch
>
>
> See screenshot attached
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15730) Kerberos "Test Connection" button should not be shown on the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230049#comment-15230049 ] Oleg Nechiporenko commented on AMBARI-15730: Tested manually on the real cluster > Kerberos "Test Connection" button should not be shown on the host configs page > -- > > Key: AMBARI-15730 > URL: https://issues.apache.org/jira/browse/AMBARI-15730 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: 1Px55.jpg, AMBARI-15730.patch > > > See screenshot attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15742) Recommendations return 500 error for HIVE with
[
https://issues.apache.org/jira/browse/AMBARI-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-15742:
-
Status: Patch Available (was: Open)
> Recommendations return 500 error for HIVE with
> --
>
> Key: AMBARI-15742
> URL: https://issues.apache.org/jira/browse/AMBARI-15742
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15742.patch
>
>
> Select "Existing MySQL / MariaDB Database " for HIVE
> Request to {{api/v1/stacks/HDP/versions/2.5/recommendations}} returns:
> {noformat}
> {
> "status" : 500,
> "message" : "Stack Advisor reported an error: AttributeError: 'NoneType'
> object has no attribute 'format'\nStdOut file:
> /var/run/ambari-server/stack-recommendations/73/stackadvisor.out\n\nStdErr
> file: /var/run/ambari-server/stack-recommendations/73/stackadvisor.err"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15742) Recommendations return 500 error for HIVE with
[
https://issues.apache.org/jira/browse/AMBARI-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-15742:
-
Attachment: AMBARI-15742.patch
> Recommendations return 500 error for HIVE with
> --
>
> Key: AMBARI-15742
> URL: https://issues.apache.org/jira/browse/AMBARI-15742
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15742.patch
>
>
> Select "Existing MySQL / MariaDB Database " for HIVE
> Request to {{api/v1/stacks/HDP/versions/2.5/recommendations}} returns:
> {noformat}
> {
> "status" : 500,
> "message" : "Stack Advisor reported an error: AttributeError: 'NoneType'
> object has no attribute 'format'\nStdOut file:
> /var/run/ambari-server/stack-recommendations/73/stackadvisor.out\n\nStdErr
> file: /var/run/ambari-server/stack-recommendations/73/stackadvisor.err"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15734) Empty groups popup for Kerberos in the host configs page
[
https://issues.apache.org/jira/browse/AMBARI-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230072#comment-15230072
]
Hadoop QA commented on AMBARI-15734:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797312/AMBARI-15734.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6270//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6270//console
This message is automatically generated.
> Empty groups popup for Kerberos in the host configs page
>
>
> Key: AMBARI-15734
> URL: https://issues.apache.org/jira/browse/AMBARI-15734
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-15734.patch
>
>
> * Install cluster
> * Enable Kerberos
> * Go to host configs page
> * Do page refresh
> * Select Kerberos
> * Click on Group Change
> * Popup with selectbox appears
> *ER* Selectbox contains list with config group names
> *AR* Selectbox is empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15754) configs.sh expands ***** in config values to a local file list, causing broken config files
Asger Askov Blekinge created AMBARI-15754:
-
Summary: configs.sh expands * in config values to a local file
list, causing broken config files
Key: AMBARI-15754
URL: https://issues.apache.org/jira/browse/AMBARI-15754
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.0.0, 2.0.1, 2.1.0, 2.3.0, 2.0.2, 2.1.1, 2.1.2, trunk,
2.0.3, 2.2.0, 2.4.0, 2.2.1, 2.2.2, 2.4.1
Reporter: Asger Askov Blekinge
When you try to get the value of, say, pig-log4j like this, it outputs correctly
{code}
curl -k -s -u $AMBARI_USER:$AMBARI_PASSWORD
"$AMBARI_HOST:$AMBARI_PORT/api/v1/clusters/$CLUSTER_NAME/configurations?type=pig-log4j&tag=version1"
{code}
If you use configs.sh to do the same
{code}
configs.sh -u $AMBARI_USER -p $AMBARI_PASSWORD -port $AMBARI_PORT get
$AMBARI_HOST $CLUSTER_NAME pig-log4j
{code}
it will have replaced the * with the file list in the working directory
So,
{code}
"content" : "\n#\n#\n# Licensed to the Apache Software Foundation (ASF) under
one\n# or more contributor license agreements. See the NOTICE file\n#
distributed with this work for additional information\n# regarding copyright
ownership. The ASF licenses this file\n# to you under the Apache License,
Version 2.0 (the\n# \"License\"); you may not use this file except in
compliance\n# with the License. You may obtain a copy of the License at\n#\n#
http://www.apache.org/licenses/LICENSE-2.0\n#\n# Unless required by applicable
law or agreed to in writing,\n# software distributed under the License is
distributed on an\n# \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY\n# KIND, either express or implied. See the License for the\n# specific
language governing permissions and limitations\n# under the
License.\n#\n#\n#\n\n# * Set root logger level to DEBUG and its only
appender to A.\nlog4j.logger.org.apache.pig=info, A\n\n# * A is set to be a
ConsoleAppender.\nlog4j.appender.A=org.apache.log4j.ConsoleAppender\n# * A
uses
PatternLayout.\nlog4j.appender.A.layout=org.apache.log4j.PatternLayout\nlog4j.appender.A.layout.ConversionPattern=%-4r
[%t] %-5p %c %x - %m%n"
{code}
will be output as
{code}
"content" : "\n#\n#\n# Licensed to the Apache Software Foundation (ASF) under
one\n# or more contributor license agreements. See the NOTICE file\n#
distributed with this work for additional information\n# regarding copyright
ownership. The ASF licenses this file\n# to you under the Apache License,
Version 2.0 (the\n# \"License\"); you may not use this file except in
compliance\n# with the License. You may obtain a copy of the License at\n#\n#
http://www.apache.org/licenses/LICENSE-2.0\n#\n# Unless required by applicable
law or agreed to in writing,\n# software distributed under the License is
distributed on an\n# \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY\n# KIND, either express or implied. See the License for the\n# specific
language governing permissions and limitations\n# under the
License.\n#\n#\n#\n\n# bigr configs.sh gpfs mmls ssh symphony Set root logger
level to DEBUG and its only appender to A.\nlog4j.logger.org.apache.pig=info,
A\n\n# bigr configs.sh gpfs mmls ssh symphony A is set to be a
ConsoleAppender.\nlog4j.appender.A=org.apache.log4j.ConsoleAppender\n# bigr
configs.sh gpfs mmls ssh symphony A uses
PatternLayout.\nlog4j.appender.A.layout=org.apache.log4j.PatternLayout\nlog4j.appender.A.layout.ConversionPattern=%-4r
[%t] %-5p %c %x - %m%n"
{code}
As you can see, there are no * string in the output any longer, but instead
it has been replaced with "bigr configs.sh gpfs mmls ssh symphony" which
happened to be the local files in my working dir.
It all comes from this line in configs.sh, line 241-247
{code}
if [ "$propertiesStarted" -gt "0" ]; then
if [ -z $FILENAME ]; then
echo $line
else
echo $line >> $FILENAME
fi
fi
{code}
where the echo do not quote the $line to output
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15734) Empty groups popup for Kerberos in the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230075#comment-15230075 ] Oleg Nechiporenko commented on AMBARI-15734: Tested manually on the real cluster > Empty groups popup for Kerberos in the host configs page > > > Key: AMBARI-15734 > URL: https://issues.apache.org/jira/browse/AMBARI-15734 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15734.patch > > > * Install cluster > * Enable Kerberos > * Go to host configs page > * Do page refresh > * Select Kerberos > * Click on Group Change > * Popup with selectbox appears > *ER* Selectbox contains list with config group names > *AR* Selectbox is empty -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230074#comment-15230074
]
Hadoop QA commented on AMBARI-15744:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797373/AMBARI-15744.trunk.v1.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6271//console
This message is automatically generated.
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15754) configs.sh expands ***** in config values to a local file list, causing broken config files
[
https://issues.apache.org/jira/browse/AMBARI-15754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Asger Askov Blekinge updated AMBARI-15754:
--
Status: Patch Available (was: Open)
{code}
Index: ambari-server/src/main/resources/scripts/configs.sh
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- ambari-server/src/main/resources/scripts/configs.sh (revision
96bdecf8474064465b2ecc1261152d9ba68730e2)
+++ ambari-server/src/main/resources/scripts/configs.sh (revision )
@@ -127,7 +127,7 @@
fi
fi
if [ "$propertiesStarted" -gt 0 ]; then
- if [ "`echo $line | grep -E "},?$"`" ]; then
+ if [ "`echo "$line" | grep -E "},?$"`" ]; then
## Properties ended
## Add property
propLen=${#newProperties}
@@ -146,7 +146,7 @@
fi
newProperties=$newProperties$line
propertiesStarted=0
- elif [ "`echo $line | grep "\\\"$CONFIGKEY\\\""`" ]; then
+ elif [ "`echo "$line" | grep "\\\"$CONFIGKEY\\\""`" ]; then
echo "## Config found. Skipping origin value"
else
newProperties=$newProperties$line
@@ -154,9 +154,9 @@
elif [ "$attributesStarted" -gt 0 ]; then
newProperties=$newProperties$line
fi
-if [ "`echo $line | grep -E "{$"`" ]; then
+if [ "`echo "$line" | grep -E "{$"`" ]; then
currentLevel=$((currentLevel+1))
-elif [ "`echo $line | grep -E "},?$"`" ]; then
+elif [ "`echo "$line" | grep -E "},?$"`" ]; then
currentLevel=$((currentLevel-1))
if [ "$currentLevel" == 1 ]; then
# if no properties in current config
@@ -168,7 +168,7 @@
finalJson="{ \"Clusters\": { \"desired_config\": {\"type\":
\"$SITE\", \"tag\":\"$newTag\", $newProperties}}}"
newFile="doSet_$newTag.json"
echo "## PUTting json into: $newFile"
- echo $finalJson > $newFile
+ echo "$finalJson" > $newFile
curl -k -u $USERID:$PASSWD -X PUT -H "X-Requested-By: ambari"
"$AMBARIURL/api/v1/clusters/$CLUSTER" --data @$newFile
currentSiteTag
echo "## NEW Site:$SITE, Tag:$SITETAG";
@@ -193,7 +193,7 @@
newProperties=`cat $FILENAME`;
finalJson="{ \"Clusters\": { \"desired_config\": {\"type\": \"$SITE\",
\"tag\":\"$newTag\", $newProperties}}}"
newFile="doSet_$newTag.json"
- echo $finalJson>$newFile
+ echo "$finalJson">$newFile
echo "## PUTting file:\"$FILENAME\" into config(type:\"$SITE\",
tag:$newTag) via $newFile"
curl -k -u $USERID:$PASSWD -X PUT -H "X-Requested-By: ambari"
"$AMBARIURL/api/v1/clusters/$CLUSTER" --data @$newFile
currentSiteTag
@@ -234,20 +234,20 @@
curl -k -s -u $USERID:$PASSWD
"$AMBARIURL/api/v1/clusters/$CLUSTER/configurations?type=$SITE&tag=$SITETAG" |
while read -r line; do
# echo ">>> $line";
if [ "$propertiesStarted" -eq 0 ]; then
- if [ "`echo $line | grep "\"properties\""`" -o "`echo $line | grep
"\"properties_attributes\""`" ]; then
+ if [ "`echo "$line" | grep "\"properties\""`" -o "`echo "$line" | grep
"\"properties_attributes\""`" ]; then
propertiesStarted=$currentLevel
fi
fi
if [ "$propertiesStarted" -gt "0" ]; then
if [ -z $FILENAME ]; then
-echo $line
+echo "$line"
else
-echo $line >> $FILENAME
+echo "$line" >> $FILENAME
fi
fi
-if [ "`echo $line | grep -E "{$"`" ]; then
+if [ "`echo "$line" | grep -E "{$"`" ]; then
currentLevel=$((currentLevel+1))
-elif [ "`echo $line | grep -E "},?$"`" ]; then
+elif [ "`echo "$line" | grep -E "},?$"`" ]; then
currentLevel=$((currentLevel-1))
fi
if [ "$propertiesStarted" -eq "$currentLevel" ]; then
{code}
> configs.sh expands * in config values to a local file list, causing
> broken config files
> ---
>
> Key: AMBARI-15754
> URL: https://issues.apache.org/jira/browse/AMBARI-15754
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0, 2.0.1, 2.1.0, 2.3.0, 2.0.2, 2.1.1, 2.1.2, trunk,
> 2.0.3, 2.2.0, 2.4.0, 2.2.1, 2.2.2, 2.4.1
>Reporter: Asger Askov Blekinge
>
> When you try to get the value of, say, pig-log4j like this, it outputs
> correctly
> {code}
> curl -k -s -u $AMBARI_USER:$AMBARI_PASSWORD
> "$AMBARI_HOST:$AMBARI_PORT/api/v1/clusters/$CLUSTER_NAME/configurations?type=pig-log4j&tag=version1"
> {code}
> If you use configs.sh to do the same
> {code}
> configs.sh -u $AMBARI_USER -p $AMBARI_PASSWORD -port $AMBARI_PORT get
> $AMBARI_HOST $CLUSTER_NAME pig-log4j
> {code}
> it will have replaced the * with the file list in the
[jira] [Created] (AMBARI-15755) Hive view should have some checks before starting similar to pig view
Pallav Kulshreshtha created AMBARI-15755: Summary: Hive view should have some checks before starting similar to pig view Key: AMBARI-15755 URL: https://issues.apache.org/jira/browse/AMBARI-15755 Project: Ambari Issue Type: Bug Components: ambari-views Affects Versions: 2.1.0 Reporter: Pallav Kulshreshtha Assignee: Pallav Kulshreshtha Fix For: 2.4.0 hive view should have some checks before starting similar to pig view Without this, there are times where file browser view is taking time to load, and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15734) Empty groups popup for Kerberos in the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230079#comment-15230079 ] Oleg Nechiporenko commented on AMBARI-15734: Committed to trunk > Empty groups popup for Kerberos in the host configs page > > > Key: AMBARI-15734 > URL: https://issues.apache.org/jira/browse/AMBARI-15734 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15734.patch > > > * Install cluster > * Enable Kerberos > * Go to host configs page > * Do page refresh > * Select Kerberos > * Click on Group Change > * Popup with selectbox appears > *ER* Selectbox contains list with config group names > *AR* Selectbox is empty -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15730) Kerberos "Test Connection" button should not be shown on the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230080#comment-15230080 ] Oleg Nechiporenko commented on AMBARI-15730: Committed to trunk > Kerberos "Test Connection" button should not be shown on the host configs page > -- > > Key: AMBARI-15730 > URL: https://issues.apache.org/jira/browse/AMBARI-15730 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: 1Px55.jpg, AMBARI-15730.patch > > > See screenshot attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15754) configs.sh expands ***** in config values to a local file list, causing broken config files
[
https://issues.apache.org/jira/browse/AMBARI-15754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Asger Askov Blekinge updated AMBARI-15754:
--
Labels: easyfix patch (was: )
> configs.sh expands * in config values to a local file list, causing
> broken config files
> ---
>
> Key: AMBARI-15754
> URL: https://issues.apache.org/jira/browse/AMBARI-15754
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0, 2.0.1, 2.1.0, 2.3.0, 2.0.2, 2.1.1, 2.1.2, trunk,
> 2.0.3, 2.2.0, 2.4.0, 2.2.1, 2.2.2, 2.4.1
>Reporter: Asger Askov Blekinge
> Labels: easyfix, patch
>
> When you try to get the value of, say, pig-log4j like this, it outputs
> correctly
> {code}
> curl -k -s -u $AMBARI_USER:$AMBARI_PASSWORD
> "$AMBARI_HOST:$AMBARI_PORT/api/v1/clusters/$CLUSTER_NAME/configurations?type=pig-log4j&tag=version1"
> {code}
> If you use configs.sh to do the same
> {code}
> configs.sh -u $AMBARI_USER -p $AMBARI_PASSWORD -port $AMBARI_PORT get
> $AMBARI_HOST $CLUSTER_NAME pig-log4j
> {code}
> it will have replaced the * with the file list in the working directory
> So,
> {code}
> "content" : "\n#\n#\n# Licensed to the Apache Software Foundation (ASF)
> under one\n# or more contributor license agreements. See the NOTICE file\n#
> distributed with this work for additional information\n# regarding copyright
> ownership. The ASF licenses this file\n# to you under the Apache License,
> Version 2.0 (the\n# \"License\"); you may not use this file except in
> compliance\n# with the License. You may obtain a copy of the License
> at\n#\n# http://www.apache.org/licenses/LICENSE-2.0\n#\n# Unless required
> by applicable law or agreed to in writing,\n# software distributed under the
> License is distributed on an\n# \"AS IS\" BASIS, WITHOUT WARRANTIES OR
> CONDITIONS OF ANY\n# KIND, either express or implied. See the License for
> the\n# specific language governing permissions and limitations\n# under the
> License.\n#\n#\n#\n\n# * Set root logger level to DEBUG and its only
> appender to A.\nlog4j.logger.org.apache.pig=info, A\n\n# * A is set to be
> a ConsoleAppender.\nlog4j.appender.A=org.apache.log4j.ConsoleAppender\n#
> * A uses
> PatternLayout.\nlog4j.appender.A.layout=org.apache.log4j.PatternLayout\nlog4j.appender.A.layout.ConversionPattern=%-4r
> [%t] %-5p %c %x - %m%n"
> {code}
> will be output as
> {code}
> "content" : "\n#\n#\n# Licensed to the Apache Software Foundation (ASF) under
> one\n# or more contributor license agreements. See the NOTICE file\n#
> distributed with this work for additional information\n# regarding copyright
> ownership. The ASF licenses this file\n# to you under the Apache License,
> Version 2.0 (the\n# \"License\"); you may not use this file except in
> compliance\n# with the License. You may obtain a copy of the License at\n#\n#
> http://www.apache.org/licenses/LICENSE-2.0\n#\n# Unless required by
> applicable law or agreed to in writing,\n# software distributed under the
> License is distributed on an\n# \"AS IS\" BASIS, WITHOUT WARRANTIES OR
> CONDITIONS OF ANY\n# KIND, either express or implied. See the License for
> the\n# specific language governing permissions and limitations\n# under the
> License.\n#\n#\n#\n\n# bigr configs.sh gpfs mmls ssh symphony Set root logger
> level to DEBUG and its only appender to A.\nlog4j.logger.org.apache.pig=info,
> A\n\n# bigr configs.sh gpfs mmls ssh symphony A is set to be a
> ConsoleAppender.\nlog4j.appender.A=org.apache.log4j.ConsoleAppender\n# bigr
> configs.sh gpfs mmls ssh symphony A uses
> PatternLayout.\nlog4j.appender.A.layout=org.apache.log4j.PatternLayout\nlog4j.appender.A.layout.ConversionPattern=%-4r
> [%t] %-5p %c %x - %m%n"
> {code}
> As you can see, there are no * string in the output any longer, but
> instead it has been replaced with "bigr configs.sh gpfs mmls ssh symphony"
> which happened to be the local files in my working dir.
> It all comes from this line in configs.sh, line 241-247
> {code}
> if [ "$propertiesStarted" -gt "0" ]; then
> if [ -z $FILENAME ]; then
> echo $line
> else
> echo $line >> $FILENAME
> fi
> fi
> {code}
> where the echo do not quote the $line to output
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15736) Service can't be deleted if all component are in state "install failed"
[ https://issues.apache.org/jira/browse/AMBARI-15736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230081#comment-15230081 ] Oleg Nechiporenko commented on AMBARI-15736: Committed to trunk > Service can't be deleted if all component are in state "install failed" > --- > > Key: AMBARI-15736 > URL: https://issues.apache.org/jira/browse/AMBARI-15736 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15736.patch > > > Service is in the state "install failed" > All service's components are in the state "install failed" > Try to delete it via UI > *AR* Popup with message is shown "Prior to deleting SERVICE, you must stop > the service and each slave and master component." > *ER* Service is deleted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15750) [Ambari Web] "Install Packages" option not shown when a new version is registered
[
https://issues.apache.org/jira/browse/AMBARI-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230094#comment-15230094
]
Hadoop QA commented on AMBARI-15750:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797434/AMBARI-15750.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 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6272//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6272//console
This message is automatically generated.
> [Ambari Web] "Install Packages" option not shown when a new version is
> registered
> -
>
> Key: AMBARI-15750
> URL: https://issues.apache.org/jira/browse/AMBARI-15750
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Xi Wang
>Assignee: Xi Wang
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-15750.patch
>
>
> ambari-server --hash
> 6fe7f83277a269dc6d9634b186ff3fc05fca8505
> 1.Install Ambari from trunk (2.4.0.0)
> 2.Install cluster with HDP-2.2
> 3.Register a repo HDP-2.3.4 using version definition file
> 4.Register a repo HDP-2.3.2 using REST API in the old repo version format
> (Refer:
> 5.https://docs.google.com/document/d/1M9WSi7GrozYTxGaqsgCSp25aydP88h8LMgdEVZfzRDM)
> 6.Both the registered versions do not show up in Admin>Stacks and
> Versions>Versions page.
> 7.Kick off Install Packages using the REST API instead.
> 8.Note the new registered version shows up in the UI in "Installing" state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15755) Hive view should have some checks before starting similar to pig view
[ https://issues.apache.org/jira/browse/AMBARI-15755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15755: - Attachment: AMBARI-15755_trunk.patch > Hive view should have some checks before starting similar to pig view > - > > Key: AMBARI-15755 > URL: https://issues.apache.org/jira/browse/AMBARI-15755 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-15755_trunk.patch > > > hive view should have some checks before starting similar to pig view > Without this, there are times where file browser view is taking time to load, > and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15753) Ambari Views : Reverting the changes for separation of logs in ambari branch-2.2
[ https://issues.apache.org/jira/browse/AMBARI-15753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitiraj Singh Rathore updated AMBARI-15753: --- Status: Patch Available (was: Open) > Ambari Views : Reverting the changes for separation of logs in ambari > branch-2.2 > > > Key: AMBARI-15753 > URL: https://issues.apache.org/jira/browse/AMBARI-15753 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.0 >Reporter: Nitiraj Singh Rathore >Assignee: Nitiraj Singh Rathore > > Revert changes of AMBARI-14084 from branch-2.2 as it is wrong branch for > these changes. > Create a new patch which will revert these changes and apply only to > branch-2.2 of ambari. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15755) Hive view should have some checks before starting similar to pig view
[ https://issues.apache.org/jira/browse/AMBARI-15755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15755: - Status: Patch Available (was: Open) > Hive view should have some checks before starting similar to pig view > - > > Key: AMBARI-15755 > URL: https://issues.apache.org/jira/browse/AMBARI-15755 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-15755_trunk.patch > > > hive view should have some checks before starting similar to pig view > Without this, there are times where file browser view is taking time to load, > and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15753) Ambari Views : Reverting the changes for separation of logs in ambari branch-2.2
[ https://issues.apache.org/jira/browse/AMBARI-15753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitiraj Singh Rathore updated AMBARI-15753: --- Attachment: AMBARI-15753_branch-2.2.patch > Ambari Views : Reverting the changes for separation of logs in ambari > branch-2.2 > > > Key: AMBARI-15753 > URL: https://issues.apache.org/jira/browse/AMBARI-15753 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.0 >Reporter: Nitiraj Singh Rathore >Assignee: Nitiraj Singh Rathore > Attachments: AMBARI-15753_branch-2.2.patch > > > Revert changes of AMBARI-14084 from branch-2.2 as it is wrong branch for > these changes. > Create a new patch which will revert these changes and apply only to > branch-2.2 of ambari. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-14084) Ambari Views : each view should have separate log file for better troubleshooting
[ https://issues.apache.org/jira/browse/AMBARI-14084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230104#comment-15230104 ] Hudson commented on AMBARI-14084: - SUCCESS: Integrated in Ambari-trunk-Commit #4611 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4611/]) AMBARI-14084. Views: Provide refresh list of available views with newly (pallav.kul: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1df39c324fc97d4db4cc19023d1e8aed92efc36d]) * ambari-server/src/main/java/org/apache/ambari/server/view/ViewDirectoryWatcher.java * ambari-admin/src/main/resources/ui/admin-web/app/views/ambariViews/listTable.html * ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/ambariViews/ViewsListCtrl.js * ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java * ambari-server/src/main/java/org/apache/ambari/server/view/DirectoryWatcher.java * ambari-server/src/test/java/org/apache/ambari/server/view/ViewDirectoryWatcherTest.java * ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java > Ambari Views : each view should have separate log file for better > troubleshooting > - > > Key: AMBARI-14084 > URL: https://issues.apache.org/jira/browse/AMBARI-14084 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Nitiraj Singh Rathore >Assignee: Nitiraj Singh Rathore > Fix For: 2.2.2 > > Attachments: AMBARI-14084_branch-2.1.patch, > AMBARI-14084_branch-2.2.patch, AMBARI-14084_branch-2.2_1.patch, > AMBARI-14084_branch-2.2_2.patch, AMBARI-14084_trunk.patch > > > There should be separate log files for hive view, tez view for better > debbugability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15742) Recommendations return 500 error for HIVE with
[
https://issues.apache.org/jira/browse/AMBARI-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230105#comment-15230105
]
Hadoop QA commented on AMBARI-15742:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797496/AMBARI-15742.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 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6273//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6273//console
This message is automatically generated.
> Recommendations return 500 error for HIVE with
> --
>
> Key: AMBARI-15742
> URL: https://issues.apache.org/jira/browse/AMBARI-15742
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15742.patch
>
>
> Select "Existing MySQL / MariaDB Database " for HIVE
> Request to {{api/v1/stacks/HDP/versions/2.5/recommendations}} returns:
> {noformat}
> {
> "status" : 500,
> "message" : "Stack Advisor reported an error: AttributeError: 'NoneType'
> object has no attribute 'format'\nStdOut file:
> /var/run/ambari-server/stack-recommendations/73/stackadvisor.out\n\nStdErr
> file: /var/run/ambari-server/stack-recommendations/73/stackadvisor.err"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15742) Recommendations return 500 error for HIVE with
[
https://issues.apache.org/jira/browse/AMBARI-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230113#comment-15230113
]
Dmytro Sen commented on AMBARI-15742:
-
+1
> Recommendations return 500 error for HIVE with
> --
>
> Key: AMBARI-15742
> URL: https://issues.apache.org/jira/browse/AMBARI-15742
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15742.patch
>
>
> Select "Existing MySQL / MariaDB Database " for HIVE
> Request to {{api/v1/stacks/HDP/versions/2.5/recommendations}} returns:
> {noformat}
> {
> "status" : 500,
> "message" : "Stack Advisor reported an error: AttributeError: 'NoneType'
> object has no attribute 'format'\nStdOut file:
> /var/run/ambari-server/stack-recommendations/73/stackadvisor.out\n\nStdErr
> file: /var/run/ambari-server/stack-recommendations/73/stackadvisor.err"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15756) File browser view should have some checks before starting similar to pig view
Pallav Kulshreshtha created AMBARI-15756: Summary: File browser view should have some checks before starting similar to pig view Key: AMBARI-15756 URL: https://issues.apache.org/jira/browse/AMBARI-15756 Project: Ambari Issue Type: Bug Components: ambari-views Affects Versions: 2.1.0 Reporter: Pallav Kulshreshtha Assignee: Pallav Kulshreshtha Fix For: 2.4.0 File browser view should have some checks before starting similar to pig view Without this, there are times where file browser view is taking time to load, and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15742) Recommendations return 500 error for HIVE with
[
https://issues.apache.org/jira/browse/AMBARI-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonenko Alexander updated AMBARI-15742:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk
> Recommendations return 500 error for HIVE with
> --
>
> Key: AMBARI-15742
> URL: https://issues.apache.org/jira/browse/AMBARI-15742
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15742.patch
>
>
> Select "Existing MySQL / MariaDB Database " for HIVE
> Request to {{api/v1/stacks/HDP/versions/2.5/recommendations}} returns:
> {noformat}
> {
> "status" : 500,
> "message" : "Stack Advisor reported an error: AttributeError: 'NoneType'
> object has no attribute 'format'\nStdOut file:
> /var/run/ambari-server/stack-recommendations/73/stackadvisor.out\n\nStdErr
> file: /var/run/ambari-server/stack-recommendations/73/stackadvisor.err"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Gergely updated AMBARI-15646:
Attachment: AMBARI-15646.patch
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> private void auditLog(HostRoleCommandEntity
[jira] [Commented] (AMBARI-15742) Recommendations return 500 error for HIVE with
[
https://issues.apache.org/jira/browse/AMBARI-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230125#comment-15230125
]
Hadoop QA commented on AMBARI-15742:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797496/AMBARI-15742.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 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6274//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6274//console
This message is automatically generated.
> Recommendations return 500 error for HIVE with
> --
>
> Key: AMBARI-15742
> URL: https://issues.apache.org/jira/browse/AMBARI-15742
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
> Fix For: 2.4.0
>
> Attachments: AMBARI-15742.patch
>
>
> Select "Existing MySQL / MariaDB Database " for HIVE
> Request to {{api/v1/stacks/HDP/versions/2.5/recommendations}} returns:
> {noformat}
> {
> "status" : 500,
> "message" : "Stack Advisor reported an error: AttributeError: 'NoneType'
> object has no attribute 'format'\nStdOut file:
> /var/run/ambari-server/stack-recommendations/73/stackadvisor.out\n\nStdErr
> file: /var/run/ambari-server/stack-recommendations/73/stackadvisor.err"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230134#comment-15230134
]
Hudson commented on AMBARI-15744:
-
FAILURE: Integrated in Ambari-branch-2.2 #605 (See
[https://builds.apache.org/job/Ambari-branch-2.2/605/])
AMBARI-15744. Webhcat Server failed to stop while stopping all the (stoader:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=5edcf8a275a7ec6f80a6d4456942103e3c8c006c])
* ambari-server/src/test/python/stacks/2.0.6/HIVE/test_webhcat_server.py
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER
[ https://issues.apache.org/jira/browse/AMBARI-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gautam Borad updated AMBARI-14383: -- Attachment: AMBARI-14383.3.patch > Add support for Ranger TagSync process as a component under RANGER > -- > > Key: AMBARI-14383 > URL: https://issues.apache.org/jira/browse/AMBARI-14383 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, > AMBARI-14383.3.patch, AMBARI-14383.patch > > > Ranger TagSync is a separate service that will be responsible for > synchronizing the tags from Apache Atlas into Apache Ranger (db). > This jira will track changes required to install/configure TagSync from > Ambari. > * Add Ranger TagSync component under existing RANGER service. > * The component will be a master component > * Ability to start/stop the component independently of Ranger Admin. > * Ability to install the component on any host of the cluster > * Support should be available only from HDP 2.3 > * Any other changes required in Ambari stack to support such component -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15756) File browser view should have some checks before starting similar to pig view
[ https://issues.apache.org/jira/browse/AMBARI-15756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15756: - Status: Patch Available (was: Open) > File browser view should have some checks before starting similar to pig view > - > > Key: AMBARI-15756 > URL: https://issues.apache.org/jira/browse/AMBARI-15756 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-15756_trunk.patch > > > File browser view should have some checks before starting similar to pig view > Without this, there are times where file browser view is taking time to load, > and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15756) File browser view should have some checks before starting similar to pig view
[ https://issues.apache.org/jira/browse/AMBARI-15756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15756: - Attachment: AMBARI-15756_trunk.patch > File browser view should have some checks before starting similar to pig view > - > > Key: AMBARI-15756 > URL: https://issues.apache.org/jira/browse/AMBARI-15756 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-15756_trunk.patch > > > File browser view should have some checks before starting similar to pig view > Without this, there are times where file browser view is taking time to load, > and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Gergely updated AMBARI-15646:
Attachment: AMBARI-15646.patch
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> private void auditLog(HostRoleCommandEntity
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Gergely updated AMBARI-15646:
Attachment: (was: AMBARI-15646.patch)
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> private void auditLog(HostRoleCo
[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER
[ https://issues.apache.org/jira/browse/AMBARI-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gautam Borad updated AMBARI-14383: -- Status: Patch Available (was: In Progress) > Add support for Ranger TagSync process as a component under RANGER > -- > > Key: AMBARI-14383 > URL: https://issues.apache.org/jira/browse/AMBARI-14383 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, > AMBARI-14383.3.patch, AMBARI-14383.patch > > > Ranger TagSync is a separate service that will be responsible for > synchronizing the tags from Apache Atlas into Apache Ranger (db). > This jira will track changes required to install/configure TagSync from > Ambari. > * Add Ranger TagSync component under existing RANGER service. > * The component will be a master component > * Ability to start/stop the component independently of Ranger Admin. > * Ability to install the component on any host of the cluster > * Support should be available only from HDP 2.3 > * Any other changes required in Ambari stack to support such component -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
Oleg Nechiporenko created AMBARI-15757: -- Summary: Add Service step4 load step takes 20+ seconds Key: AMBARI-15757 URL: https://issues.apache.org/jira/browse/AMBARI-15757 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Oleg Nechiporenko Assignee: Oleg Nechiporenko Fix For: 2.4.0 * Install cluster with a few services * Open ASW * Select all services to add * Proceed to step4 * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[ https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Nechiporenko updated AMBARI-15757: --- Attachment: AMBARI-15757.patch > Add Service step4 load step takes 20+ seconds > - > > Key: AMBARI-15757 > URL: https://issues.apache.org/jira/browse/AMBARI-15757 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15757.patch > > > * Install cluster with a few services > * Open ASW > * Select all services to add > * Proceed to step4 > * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[ https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Nechiporenko updated AMBARI-15757: --- Status: Patch Available (was: Open) Patch added > Add Service step4 load step takes 20+ seconds > - > > Key: AMBARI-15757 > URL: https://issues.apache.org/jira/browse/AMBARI-15757 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15757.patch > > > * Install cluster with a few services > * Open ASW > * Select all services to add > * Proceed to step4 > * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[ https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230149#comment-15230149 ] Oleg Nechiporenko commented on AMBARI-15757: 25650 tests complete (25 seconds) 154 tests pending > Add Service step4 load step takes 20+ seconds > - > > Key: AMBARI-15757 > URL: https://issues.apache.org/jira/browse/AMBARI-15757 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15757.patch > > > * Install cluster with a few services > * Open ASW > * Select all services to add > * Proceed to step4 > * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15755) Hive view should have some checks before starting similar to pig view
[
https://issues.apache.org/jira/browse/AMBARI-15755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230152#comment-15230152
]
Hadoop QA commented on AMBARI-15755:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797501/AMBARI-15755_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
contrib/views/hive.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6275//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6275//console
This message is automatically generated.
> Hive view should have some checks before starting similar to pig view
> -
>
> Key: AMBARI-15755
> URL: https://issues.apache.org/jira/browse/AMBARI-15755
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.4.0
>
> Attachments: AMBARI-15755_trunk.patch
>
>
> hive view should have some checks before starting similar to pig view
> Without this, there are times where file browser view is taking time to load,
> and hence would need some type of status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[ https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230151#comment-15230151 ] Antonenko Alexander commented on AMBARI-15757: -- +1 for the patch > Add Service step4 load step takes 20+ seconds > - > > Key: AMBARI-15757 > URL: https://issues.apache.org/jira/browse/AMBARI-15757 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15757.patch > > > * Install cluster with a few services > * Open ASW > * Select all services to add > * Proceed to step4 > * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15753) Ambari Views : Reverting the changes for separation of logs in ambari branch-2.2
[
https://issues.apache.org/jira/browse/AMBARI-15753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230154#comment-15230154
]
Hadoop QA commented on AMBARI-15753:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797502/AMBARI-15753_branch-2.2.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6276//console
This message is automatically generated.
> Ambari Views : Reverting the changes for separation of logs in ambari
> branch-2.2
>
>
> Key: AMBARI-15753
> URL: https://issues.apache.org/jira/browse/AMBARI-15753
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.2.0
>Reporter: Nitiraj Singh Rathore
>Assignee: Nitiraj Singh Rathore
> Attachments: AMBARI-15753_branch-2.2.patch
>
>
> Revert changes of AMBARI-14084 from branch-2.2 as it is wrong branch for
> these changes.
> Create a new patch which will revert these changes and apply only to
> branch-2.2 of ambari.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[
https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230176#comment-15230176
]
Hadoop QA commented on AMBARI-15757:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797512/AMBARI-15757.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6277//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6277//console
This message is automatically generated.
> Add Service step4 load step takes 20+ seconds
> -
>
> Key: AMBARI-15757
> URL: https://issues.apache.org/jira/browse/AMBARI-15757
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-15757.patch
>
>
> * Install cluster with a few services
> * Open ASW
> * Select all services to add
> * Proceed to step4
> * It loading takes about 20-30 seconds
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[ https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230179#comment-15230179 ] Oleg Nechiporenko commented on AMBARI-15757: Tested manually on the real cluster > Add Service step4 load step takes 20+ seconds > - > > Key: AMBARI-15757 > URL: https://issues.apache.org/jira/browse/AMBARI-15757 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15757.patch > > > * Install cluster with a few services > * Open ASW > * Select all services to add > * Proceed to step4 > * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[ https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230180#comment-15230180 ] Oleg Nechiporenko commented on AMBARI-15757: Committed to trunk > Add Service step4 load step takes 20+ seconds > - > > Key: AMBARI-15757 > URL: https://issues.apache.org/jira/browse/AMBARI-15757 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15757.patch > > > * Install cluster with a few services > * Open ASW > * Select all services to add > * Proceed to step4 > * It loading takes about 20-30 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15758) Add shiro.ini in Ambari Zeppelin service config
Renjith Kamath created AMBARI-15758: --- Summary: Add shiro.ini in Ambari Zeppelin service config Key: AMBARI-15758 URL: https://issues.apache.org/jira/browse/AMBARI-15758 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: ambari-2.4.0 Reporter: Renjith Kamath Fix For: ambari-2.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15759) After upgrading to Ambari 2.2.1, Storm widgets are gone
Jeff Sposetti created AMBARI-15759: -- Summary: After upgrading to Ambari 2.2.1, Storm widgets are gone Key: AMBARI-15759 URL: https://issues.apache.org/jira/browse/AMBARI-15759 Project: Ambari Issue Type: Bug Components: 2.2.1 Affects Versions: 2.2.1 Reporter: Jeff Sposetti Priority: Blocker 1. Running Ambari 2.2.1.0 2. Upgraded to Amabri 2.2.1.1 3. Storm widgets are not showing on Services > Storm > Summary -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Attachment: AMBARI-15744.trunk.v2.patch
AMBARI-15744.branch-2.2.v2.patch
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15757) Add Service step4 load step takes 20+ seconds
[
https://issues.apache.org/jira/browse/AMBARI-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230199#comment-15230199
]
Hadoop QA commented on AMBARI-15757:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797512/AMBARI-15757.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6278//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6278//console
This message is automatically generated.
> Add Service step4 load step takes 20+ seconds
> -
>
> Key: AMBARI-15757
> URL: https://issues.apache.org/jira/browse/AMBARI-15757
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-15757.patch
>
>
> * Install cluster with a few services
> * Open ASW
> * Select all services to add
> * Proceed to step4
> * It loading takes about 20-30 seconds
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15753) Ambari Views : Reverting the changes for separation of logs in ambari branch-2.2
[ https://issues.apache.org/jira/browse/AMBARI-15753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15753: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to branch-2.2 > Ambari Views : Reverting the changes for separation of logs in ambari > branch-2.2 > > > Key: AMBARI-15753 > URL: https://issues.apache.org/jira/browse/AMBARI-15753 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.0 >Reporter: Nitiraj Singh Rathore >Assignee: Nitiraj Singh Rathore > Attachments: AMBARI-15753_branch-2.2.patch > > > Revert changes of AMBARI-14084 from branch-2.2 as it is wrong branch for > these changes. > Create a new patch which will revert these changes and apply only to > branch-2.2 of ambari. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230212#comment-15230212
]
Sebastian Toader commented on AMBARI-15744:
---
Part2 committed to trunk:
{code}
commit 0e87151795a9bf97f8b7ef8033204b03f08ab91b
Author: Toader, Sebastian
Date: Thu Apr 7 15:08:37 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (part2) (stoader)
{code}
Part2 committed to branch-2.2:
{code}
commit 86a2305c0a8456dfdbe5e80f3cedd1630cad51b1
Author: Toader, Sebastian
Date: Thu Apr 7 15:13:45 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (part2) (stoader)
{code}
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15758) Add shiro.ini in Ambari Zeppelin service config
[ https://issues.apache.org/jira/browse/AMBARI-15758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-15758: Status: Patch Available (was: Open) > Add shiro.ini in Ambari Zeppelin service config > --- > > Key: AMBARI-15758 > URL: https://issues.apache.org/jira/browse/AMBARI-15758 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: ambari-2.4.0 >Reporter: Renjith Kamath > Fix For: ambari-2.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15758) Add shiro.ini in Ambari Zeppelin service config
[ https://issues.apache.org/jira/browse/AMBARI-15758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renjith Kamath updated AMBARI-15758: Attachment: AMBARI-15758-trunk.patch > Add shiro.ini in Ambari Zeppelin service config > --- > > Key: AMBARI-15758 > URL: https://issues.apache.org/jira/browse/AMBARI-15758 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: ambari-2.4.0 >Reporter: Renjith Kamath > Fix For: ambari-2.4.0 > > Attachments: AMBARI-15758-trunk.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15735) Check if persist data 'wizard-data' is removed upon exiting any wizard
[ https://issues.apache.org/jira/browse/AMBARI-15735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230227#comment-15230227 ] Hudson commented on AMBARI-15735: - FAILURE: Integrated in Ambari-trunk-Commit #4612 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4612/]) AMBARI-15735 Check if persist data 'wizard-data' is removed upon exiting (atkach: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=04fe46d74bccd09f4a367193378e90bda09e7bba]) * ambari-web/app/routes/high_availability_routes.js * ambari-web/app/controllers/wizard.js * ambari-web/app/routes/rm_high_availability_routes.js * ambari-web/app/routes/add_service_routes.js * ambari-web/app/routes/add_kerberos_routes.js * ambari-web/app/routes/add_host_routes.js * ambari-web/test/controllers/wizard_test.js * ambari-web/app/routes/ra_high_availability_routes.js * ambari-web/app/routes/reassign_master_routes.js * ambari-web/app/controllers/main/admin/highAvailability_controller.js > Check if persist data 'wizard-data' is removed upon exiting any wizard > -- > > Key: AMBARI-15735 > URL: https://issues.apache.org/jira/browse/AMBARI-15735 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.0 > > Attachments: AMBARI-15735.patch > > > Sometimes 'wizard-data' is not removed removed upon exiting any wizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230226#comment-15230226
]
Hudson commented on AMBARI-15744:
-
FAILURE: Integrated in Ambari-trunk-Commit #4612 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/4612/])
AMBARI-15744. Webhcat Server failed to stop while stopping all the (stoader:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1cc4a20b33157de8c547929321567911a13d8942])
*
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py
* ambari-server/src/test/python/stacks/2.0.6/HIVE/test_webhcat_server.py
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15682) Views: Provide refresh list of available views with newly deployed views w/o restart
[ https://issues.apache.org/jira/browse/AMBARI-15682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230224#comment-15230224 ] Hudson commented on AMBARI-15682: - FAILURE: Integrated in Ambari-trunk-Commit #4612 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4612/]) AMBARI-15682. Views: Provide refresh list of available views with newly (pallav.kul: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=688f6d46d1fe1ba7fc30df1f47d6792414c4e4d4]) * ambari-server/src/main/java/org/apache/ambari/server/view/DirectoryWatcher.java * ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/ambariViews/ViewsListCtrl.js * ambari-server/src/main/java/org/apache/ambari/server/view/ViewDirectoryWatcher.java * ambari-server/src/test/java/org/apache/ambari/server/view/ViewDirectoryWatcherTest.java * ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java * ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java * ambari-admin/src/main/resources/ui/admin-web/app/views/ambariViews/listTable.html > Views: Provide refresh list of available views with newly deployed views w/o > restart > > > Key: AMBARI-15682 > URL: https://issues.apache.org/jira/browse/AMBARI-15682 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.2.0 >Reporter: Ashwin Rajeev >Assignee: Ashwin Rajeev > Fix For: 2.4.0 > > Attachments: AMBARI-15682.2.trunk.patch, AMBARI-15682.3.trunk.patch, > AMBARI-15682.4.trunk.patch, AMBARI-15682.5.trunk.patch, > AMBARI-15682.branch-2.2.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > Ambari is able to detect that there are new views available (dynamically). > However, there does not appear to be a mechanism to perform a refresh. > What makes the most sense is to refresh everytime the admin view page is > accessed and also provide a manual refresh button > User should be able to: > 1) Place a new view package on Ambari Server > 2) Do not restart Ambari Server > 3) While in Admin View, user clicks refresh in browser on Views section > 4) Newly deployed view is shown. User can create use the view to create > instances, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15736) Service can't be deleted if all component are in state "install failed"
[ https://issues.apache.org/jira/browse/AMBARI-15736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230228#comment-15230228 ] Hudson commented on AMBARI-15736: - FAILURE: Integrated in Ambari-trunk-Commit #4612 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4612/]) AMBARI-15736. Service can't be deleted if all component are in state (onechiporenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=9c3fe327d45a384cad8489e3bf65de8a357e0f75]) * ambari-web/app/models/client_component.js * ambari-web/test/controllers/wizard/step8_test.js * ambari-web/test/models/service_test.js * ambari-web/app/models/service.js > Service can't be deleted if all component are in state "install failed" > --- > > Key: AMBARI-15736 > URL: https://issues.apache.org/jira/browse/AMBARI-15736 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15736.patch > > > Service is in the state "install failed" > All service's components are in the state "install failed" > Try to delete it via UI > *AR* Popup with message is shown "Prior to deleting SERVICE, you must stop > the service and each slave and master component." > *ER* Service is deleted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-14084) Ambari Views : each view should have separate log file for better troubleshooting
[ https://issues.apache.org/jira/browse/AMBARI-14084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230229#comment-15230229 ] Hudson commented on AMBARI-14084: - FAILURE: Integrated in Ambari-trunk-Commit #4612 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4612/]) Revert "AMBARI-14084. Views: Provide refresh list of available views (pallav.kul: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=85bb079447706e004e2b2dcb103b0fdac5704290]) * ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java * ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/ambariViews/ViewsListCtrl.js * ambari-server/src/test/java/org/apache/ambari/server/view/ViewDirectoryWatcherTest.java * ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java * ambari-admin/src/main/resources/ui/admin-web/app/views/ambariViews/listTable.html * ambari-server/src/main/java/org/apache/ambari/server/view/ViewDirectoryWatcher.java * ambari-server/src/main/java/org/apache/ambari/server/view/DirectoryWatcher.java > Ambari Views : each view should have separate log file for better > troubleshooting > - > > Key: AMBARI-14084 > URL: https://issues.apache.org/jira/browse/AMBARI-14084 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Nitiraj Singh Rathore >Assignee: Nitiraj Singh Rathore > Fix For: 2.2.2 > > Attachments: AMBARI-14084_branch-2.1.patch, > AMBARI-14084_branch-2.2.patch, AMBARI-14084_branch-2.2_1.patch, > AMBARI-14084_branch-2.2_2.patch, AMBARI-14084_trunk.patch > > > There should be separate log files for hive view, tez view for better > debbugability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15730) Kerberos "Test Connection" button should not be shown on the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230230#comment-15230230 ] Hudson commented on AMBARI-15730: - FAILURE: Integrated in Ambari-trunk-Commit #4612 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4612/]) AMBARI-15730. Kerberos "Test Connection" button should not be shown on (onechiporenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=7b67232361e394a9ae72d2a26dab6201b9fab88b]) * ambari-web/app/views/common/controls_view.js > Kerberos "Test Connection" button should not be shown on the host configs page > -- > > Key: AMBARI-15730 > URL: https://issues.apache.org/jira/browse/AMBARI-15730 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: 1Px55.jpg, AMBARI-15730.patch > > > See screenshot attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15734) Empty groups popup for Kerberos in the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230225#comment-15230225 ] Hudson commented on AMBARI-15734: - FAILURE: Integrated in Ambari-trunk-Commit #4612 (See [https://builds.apache.org/job/Ambari-trunk-Commit/4612/]) AMBARI-15734. Empty groups popup for Kerberos in the host configs page (onechiporenko: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=8bb0d16a66d6d0b7f85ca44daa070c2f35a397f8]) * ambari-web/app/mixins/main/service/configs/config_overridable.js * ambari-web/app/controllers/main/service/info/configs.js > Empty groups popup for Kerberos in the host configs page > > > Key: AMBARI-15734 > URL: https://issues.apache.org/jira/browse/AMBARI-15734 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15734.patch > > > * Install cluster > * Enable Kerberos > * Go to host configs page > * Do page refresh > * Select Kerberos > * Click on Group Change > * Popup with selectbox appears > *ER* Selectbox contains list with config group names > *AR* Selectbox is empty -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15727) "E090 NullPointerException" when executing Hive queries with tez
[
https://issues.apache.org/jira/browse/AMBARI-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pallav Kulshreshtha updated AMBARI-15727:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk and branch-2.2
> "E090 NullPointerException" when executing Hive queries with tez
>
>
> Key: AMBARI-15727
> URL: https://issues.apache.org/jira/browse/AMBARI-15727
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.2.0
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.2.2
>
> Attachments: AMBARI-15727_branch-2.2.patch
>
>
> ISSUE: Queries fail when execution engine is Tez from Hive view.
> Error :
> {code}
> java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.ambari.view.hive.resources.jobs.Aggregator.saveJobInfoIfNeeded(Aggregator.java:180)
>
> at
> org.apache.ambari.view.hive.resources.jobs.Aggregator.readATSJob(Aggregator.java:133)
>
> at
> org.apache.ambari.view.hive.resources.jobs.JobService.jsonObjectFromJob(JobService.java:123)
>
> at
> org.apache.ambari.view.hive.resources.jobs.JobService.getOne(JobService.java:106)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
>
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>
> at
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>
> {code}
> The same query works in the hive view if the execution engine is MR.
> Restarting Ambari did not work. Here is the tail of the ambari-server log:
> {code}
> 25 Feb 2016 13:15:21,451 INFO [qtp-ambari-client-31] Connection:497 - Hive
> session opened
> 25 Feb 2016 13:15:43,598 ERROR [qtp-ambari-client-31]
> ServiceFormattedException:96 - java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.ambari.view.hive.resources.jobs.Aggregator.saveJobInfoIfNeeded(Aggregator.java:180)
>
> at
> org.apache.ambari.view.hive.resources.jobs.Aggregator.readATSJob(Aggregator.java:133)
>
> at
> org.apache.ambari.view.hive.resources.jobs.JobService.jsonObjectFromJob(JobService.java:123)
>
> at
> org.apache.ambari.view.hive.resources.jobs.JobService.getOne(JobService.java:106)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:20
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER
[
https://issues.apache.org/jira/browse/AMBARI-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230235#comment-15230235
]
Hadoop QA commented on AMBARI-14383:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797508/AMBARI-14383.3.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 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6279//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6279//console
This message is automatically generated.
> Add support for Ranger TagSync process as a component under RANGER
> --
>
> Key: AMBARI-14383
> URL: https://issues.apache.org/jira/browse/AMBARI-14383
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch,
> AMBARI-14383.3.patch, AMBARI-14383.patch
>
>
> Ranger TagSync is a separate service that will be responsible for
> synchronizing the tags from Apache Atlas into Apache Ranger (db).
> This jira will track changes required to install/configure TagSync from
> Ambari.
> * Add Ranger TagSync component under existing RANGER service.
> * The component will be a master component
> * Ability to start/stop the component independently of Ranger Admin.
> * Ability to install the component on any host of the cluster
> * Support should be available only from HDP 2.3
> * Any other changes required in Ambari stack to support such component
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15755) Hive view should have some checks before starting similar to pig view
[ https://issues.apache.org/jira/browse/AMBARI-15755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15755: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk. > Hive view should have some checks before starting similar to pig view > - > > Key: AMBARI-15755 > URL: https://issues.apache.org/jira/browse/AMBARI-15755 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-15755_trunk.patch > > > hive view should have some checks before starting similar to pig view > Without this, there are times where file browser view is taking time to load, > and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15756) File browser view should have some checks before starting similar to pig view
[ https://issues.apache.org/jira/browse/AMBARI-15756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pallav Kulshreshtha updated AMBARI-15756: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk. > File browser view should have some checks before starting similar to pig view > - > > Key: AMBARI-15756 > URL: https://issues.apache.org/jira/browse/AMBARI-15756 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.1.0 >Reporter: Pallav Kulshreshtha >Assignee: Pallav Kulshreshtha > Fix For: 2.4.0 > > Attachments: AMBARI-15756_trunk.patch > > > File browser view should have some checks before starting similar to pig view > Without this, there are times where file browser view is taking time to load, > and hence would need some type of status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15760) Add show_logs routines to Ranger Tagsync start/stop
Gautam Borad created AMBARI-15760: - Summary: Add show_logs routines to Ranger Tagsync start/stop Key: AMBARI-15760 URL: https://issues.apache.org/jira/browse/AMBARI-15760 Project: Ambari Issue Type: Bug Components: ambari-server Reporter: Gautam Borad Fix For: 2.4.0 Add show_logs routines to the Ranger Tagsync start/stop functions for better debugging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER
[
https://issues.apache.org/jira/browse/AMBARI-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230252#comment-15230252
]
Andrew Onischuk commented on AMBARI-14383:
--
+1 as this is big patch and hand to merge.
But please create a separate jira to add show_logs, on start/stop failures, as
we do for other components, this would be a pretty useful thing in debugging
failures.
Also just one more change
{noformat}
+ if os.path.isfile(tagsync_services_file):
+File(tagsync_services_file,
+ mode = 0755,
+)
+Execute(('ln','-sf',
format('{tagsync_services_file}'),'/usr/bin/ranger-tagsync'),
+ not_if=format("ls /usr/bin/ranger-tagsync"),
+ only_if=format("ls {tagsync_services_file}"),
+ sudo=True)
{noformat}
That if seems weird as in case someone changes permissions to 000 let's say, we
won't change it back. Can we remove it?
> Add support for Ranger TagSync process as a component under RANGER
> --
>
> Key: AMBARI-14383
> URL: https://issues.apache.org/jira/browse/AMBARI-14383
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0
>
> Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch,
> AMBARI-14383.3.patch, AMBARI-14383.patch
>
>
> Ranger TagSync is a separate service that will be responsible for
> synchronizing the tags from Apache Atlas into Apache Ranger (db).
> This jira will track changes required to install/configure TagSync from
> Ambari.
> * Add Ranger TagSync component under existing RANGER service.
> * The component will be a master component
> * Ability to start/stop the component independently of Ranger Admin.
> * Ability to install the component on any host of the cluster
> * Support should be available only from HDP 2.3
> * Any other changes required in Ambari stack to support such component
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15760) Add show_logs routines to Ranger Tagsync start/stop
[ https://issues.apache.org/jira/browse/AMBARI-15760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gautam Borad updated AMBARI-15760: -- Assignee: Mugdha Varadkar > Add show_logs routines to Ranger Tagsync start/stop > --- > > Key: AMBARI-15760 > URL: https://issues.apache.org/jira/browse/AMBARI-15760 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Gautam Borad >Assignee: Mugdha Varadkar > Fix For: 2.4.0 > > > Add show_logs routines to the Ranger Tagsync start/stop functions for better > debugging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15756) File browser view should have some checks before starting similar to pig view
[
https://issues.apache.org/jira/browse/AMBARI-15756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230254#comment-15230254
]
Hadoop QA commented on AMBARI-15756:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797509/AMBARI-15756_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
contrib/views/files.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6280//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6280//console
This message is automatically generated.
> File browser view should have some checks before starting similar to pig view
> -
>
> Key: AMBARI-15756
> URL: https://issues.apache.org/jira/browse/AMBARI-15756
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views
>Affects Versions: 2.1.0
>Reporter: Pallav Kulshreshtha
>Assignee: Pallav Kulshreshtha
> Fix For: 2.4.0
>
> Attachments: AMBARI-15756_trunk.patch
>
>
> File browser view should have some checks before starting similar to pig view
> Without this, there are times where file browser view is taking time to load,
> and hence would need some type of status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230255#comment-15230255
]
Hadoop QA commented on AMBARI-15744:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797515/AMBARI-15744.trunk.v2.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6281//console
This message is automatically generated.
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15734) Empty groups popup for Kerberos in the host configs page
[
https://issues.apache.org/jira/browse/AMBARI-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230260#comment-15230260
]
Oleg Nechiporenko commented on AMBARI-15734:
Build failed not because of this patch
{noformat}
[INFO] Ambari Web SUCCESS [01:17 min]
[INFO] Ambari Metrics Collector .. FAILURE [04:30 min]
{noformat}
> Empty groups popup for Kerberos in the host configs page
>
>
> Key: AMBARI-15734
> URL: https://issues.apache.org/jira/browse/AMBARI-15734
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-15734.patch
>
>
> * Install cluster
> * Enable Kerberos
> * Go to host configs page
> * Do page refresh
> * Select Kerberos
> * Click on Group Change
> * Popup with selectbox appears
> *ER* Selectbox contains list with config group names
> *AR* Selectbox is empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15736) Service can't be deleted if all component are in state "install failed"
[
https://issues.apache.org/jira/browse/AMBARI-15736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230259#comment-15230259
]
Oleg Nechiporenko commented on AMBARI-15736:
Build failed not because of this patch
{noformat}
[INFO] Ambari Web SUCCESS [01:17 min]
[INFO] Ambari Metrics Collector .. FAILURE [04:30 min]
{noformat}
> Service can't be deleted if all component are in state "install failed"
> ---
>
> Key: AMBARI-15736
> URL: https://issues.apache.org/jira/browse/AMBARI-15736
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: AMBARI-15736.patch
>
>
> Service is in the state "install failed"
> All service's components are in the state "install failed"
> Try to delete it via UI
> *AR* Popup with message is shown "Prior to deleting SERVICE, you must stop
> the service and each slave and master component."
> *ER* Service is deleted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15736) Service can't be deleted if all component are in state "install failed"
[ https://issues.apache.org/jira/browse/AMBARI-15736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Nechiporenko updated AMBARI-15736: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Service can't be deleted if all component are in state "install failed" > --- > > Key: AMBARI-15736 > URL: https://issues.apache.org/jira/browse/AMBARI-15736 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15736.patch > > > Service is in the state "install failed" > All service's components are in the state "install failed" > Try to delete it via UI > *AR* Popup with message is shown "Prior to deleting SERVICE, you must stop > the service and each slave and master component." > *ER* Service is deleted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15734) Empty groups popup for Kerberos in the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Nechiporenko updated AMBARI-15734: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Empty groups popup for Kerberos in the host configs page > > > Key: AMBARI-15734 > URL: https://issues.apache.org/jira/browse/AMBARI-15734 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: AMBARI-15734.patch > > > * Install cluster > * Enable Kerberos > * Go to host configs page > * Do page refresh > * Select Kerberos > * Click on Group Change > * Popup with selectbox appears > *ER* Selectbox contains list with config group names > *AR* Selectbox is empty -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15730) Kerberos "Test Connection" button should not be shown on the host configs page
[ https://issues.apache.org/jira/browse/AMBARI-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Nechiporenko updated AMBARI-15730: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Kerberos "Test Connection" button should not be shown on the host configs page > -- > > Key: AMBARI-15730 > URL: https://issues.apache.org/jira/browse/AMBARI-15730 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Oleg Nechiporenko >Assignee: Oleg Nechiporenko > Fix For: 2.4.0 > > Attachments: 1Px55.jpg, AMBARI-15730.patch > > > See screenshot attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15730) Kerberos "Test Connection" button should not be shown on the host configs page
[
https://issues.apache.org/jira/browse/AMBARI-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230261#comment-15230261
]
Oleg Nechiporenko commented on AMBARI-15730:
Build failed not because of this patch
{noformat}
[INFO] Ambari Web SUCCESS [01:17 min]
[INFO] Ambari Metrics Collector .. FAILURE [04:30 min]
{noformat}
> Kerberos "Test Connection" button should not be shown on the host configs page
> --
>
> Key: AMBARI-15730
> URL: https://issues.apache.org/jira/browse/AMBARI-15730
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Oleg Nechiporenko
>Assignee: Oleg Nechiporenko
> Fix For: 2.4.0
>
> Attachments: 1Px55.jpg, AMBARI-15730.patch
>
>
> See screenshot attached
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15696) BulkCommand stop NodeManagers stops the wrong component
[ https://issues.apache.org/jira/browse/AMBARI-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230271#comment-15230271 ] Di Li commented on AMBARI-15696: committed to trunk as https://git-wip-us.apache.org/repos/asf?p=ambari.git;a=commit;h=10371363d2bae1ee2c5e968afc9e94240a2ee49a > BulkCommand stop NodeManagers stops the wrong component > --- > > Key: AMBARI-15696 > URL: https://issues.apache.org/jira/browse/AMBARI-15696 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li > Fix For: trunk > > Attachments: AMBARI-15696.patch > > > when user clicks on the Stop command for NodeManagers, UI started the wrong > component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15696) BulkCommand stop NodeManagers stops the wrong component
[ https://issues.apache.org/jira/browse/AMBARI-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Di Li updated AMBARI-15696: --- Resolution: Fixed Status: Resolved (was: Patch Available) > BulkCommand stop NodeManagers stops the wrong component > --- > > Key: AMBARI-15696 > URL: https://issues.apache.org/jira/browse/AMBARI-15696 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk >Reporter: Di Li >Assignee: Di Li > Fix For: trunk > > Attachments: AMBARI-15696.patch > > > when user clicks on the Stop command for NodeManagers, UI started the wrong > component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15758) Add shiro.ini in Ambari Zeppelin service config
[
https://issues.apache.org/jira/browse/AMBARI-15758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230288#comment-15230288
]
Hadoop QA commented on AMBARI-15758:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797517/AMBARI-15758-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6282//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6282//console
This message is automatically generated.
> Add shiro.ini in Ambari Zeppelin service config
> ---
>
> Key: AMBARI-15758
> URL: https://issues.apache.org/jira/browse/AMBARI-15758
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: ambari-2.4.0
>Reporter: Renjith Kamath
> Fix For: ambari-2.4.0
>
> Attachments: AMBARI-15758-trunk.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
[
https://issues.apache.org/jira/browse/AMBARI-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-15761:
-
Status: Patch Available (was: Open)
> While creating WEB URLs for Alerts, if we add http/https then we should not
> drop the URL path past port number
> --
>
> Key: AMBARI-15761
> URL: https://issues.apache.org/jira/browse/AMBARI-15761
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15761.patch
>
>
> As an example, look at the following alert:
>
>
>
> "APP_TIMELINE_SERVER": [
> {
> "name": "yarn_app_timeline_server_webui",
> "label": "App Timeline Web UI",
> "description": "This host-level alert is triggered if the App
> Timeline Server Web UI is unreachable.",
> "interval": 5,
> "scope": "ANY",
> "source": {
> "type": "WEB",
> "uri": {
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
> "https_property": "{{yarn-site/yarn.http.policy}}",
> "https_property_value": "HTTPS_ONLY",
> "kerberos_keytab":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
> "kerberos_principal":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
> "connection_timeout": 5.0
> },
> "reporting": {
> "ok": {
> "text": "HTTP {0} response in {2:.3f}s"
> },
> "warning":{
> "text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
> },
> "critical": {
> "text": "Connection failed to {1} ({3})"
> }
> }
> }
> }
> ]
> }
>
> Specifically lines:
>
>
>
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
>
> These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
> the form `host:port`. So the logic that adds http/https does not preserve that
> the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
[
https://issues.apache.org/jira/browse/AMBARI-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-15761:
-
Attachment: AMBARI-15761.patch
> While creating WEB URLs for Alerts, if we add http/https then we should not
> drop the URL path past port number
> --
>
> Key: AMBARI-15761
> URL: https://issues.apache.org/jira/browse/AMBARI-15761
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15761.patch
>
>
> As an example, look at the following alert:
>
>
>
> "APP_TIMELINE_SERVER": [
> {
> "name": "yarn_app_timeline_server_webui",
> "label": "App Timeline Web UI",
> "description": "This host-level alert is triggered if the App
> Timeline Server Web UI is unreachable.",
> "interval": 5,
> "scope": "ANY",
> "source": {
> "type": "WEB",
> "uri": {
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
> "https_property": "{{yarn-site/yarn.http.policy}}",
> "https_property_value": "HTTPS_ONLY",
> "kerberos_keytab":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
> "kerberos_principal":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
> "connection_timeout": 5.0
> },
> "reporting": {
> "ok": {
> "text": "HTTP {0} response in {2:.3f}s"
> },
> "warning":{
> "text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
> },
> "critical": {
> "text": "Connection failed to {1} ({3})"
> }
> }
> }
> }
> ]
> }
>
> Specifically lines:
>
>
>
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
>
> These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
> the form `host:port`. So the logic that adds http/https does not preserve that
> the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
Andrew Onischuk created AMBARI-15761:
Summary: While creating WEB URLs for Alerts, if we add http/https
then we should not drop the URL path past port number
Key: AMBARI-15761
URL: https://issues.apache.org/jira/browse/AMBARI-15761
Project: Ambari
Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
Fix For: 2.2.2
Attachments: AMBARI-15761.patch
As an example, look at the following alert:
"APP_TIMELINE_SERVER": [
{
"name": "yarn_app_timeline_server_webui",
"label": "App Timeline Web UI",
"description": "This host-level alert is triggered if the App
Timeline Server Web UI is unreachable.",
"interval": 5,
"scope": "ANY",
"source": {
"type": "WEB",
"uri": {
"http":
"{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
"https":
"{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
"https_property": "{{yarn-site/yarn.http.policy}}",
"https_property_value": "HTTPS_ONLY",
"kerberos_keytab":
"{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
"kerberos_principal":
"{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
"connection_timeout": 5.0
},
"reporting": {
"ok": {
"text": "HTTP {0} response in {2:.3f}s"
},
"warning":{
"text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
},
"critical": {
"text": "Connection failed to {1} ({3})"
}
}
}
}
]
}
Specifically lines:
"http":
"{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
"https":
"{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
the form `host:port`. So the logic that adds http/https does not preserve that
the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER
[ https://issues.apache.org/jira/browse/AMBARI-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230310#comment-15230310 ] Gautam Borad commented on AMBARI-14383: --- Committed to trunk : https://github.com/apache/ambari/commit/b1d43fbe00e3396524f75904ace3492c44d1de2e Raised AMBARI-15760 for show_logs comment from [~aonishuk] > Add support for Ranger TagSync process as a component under RANGER > -- > > Key: AMBARI-14383 > URL: https://issues.apache.org/jira/browse/AMBARI-14383 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, > AMBARI-14383.3.patch, AMBARI-14383.patch > > > Ranger TagSync is a separate service that will be responsible for > synchronizing the tags from Apache Atlas into Apache Ranger (db). > This jira will track changes required to install/configure TagSync from > Ambari. > * Add Ranger TagSync component under existing RANGER service. > * The component will be a master component > * Ability to start/stop the component independently of Ranger Admin. > * Ability to install the component on any host of the cluster > * Support should be available only from HDP 2.3 > * Any other changes required in Ambari stack to support such component -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14383) Add support for Ranger TagSync process as a component under RANGER
[ https://issues.apache.org/jira/browse/AMBARI-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gautam Borad updated AMBARI-14383: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Add support for Ranger TagSync process as a component under RANGER > -- > > Key: AMBARI-14383 > URL: https://issues.apache.org/jira/browse/AMBARI-14383 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Gautam Borad >Assignee: Gautam Borad > Fix For: 2.4.0 > > Attachments: AMBARI-14383.1.patch, AMBARI-14383.2.patch, > AMBARI-14383.3.patch, AMBARI-14383.patch > > > Ranger TagSync is a separate service that will be responsible for > synchronizing the tags from Apache Atlas into Apache Ranger (db). > This jira will track changes required to install/configure TagSync from > Ambari. > * Add Ranger TagSync component under existing RANGER service. > * The component will be a master component > * Ability to start/stop the component independently of Ranger Admin. > * Ability to install the component on any host of the cluster > * Support should be available only from HDP 2.3 > * Any other changes required in Ambari stack to support such component -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
[
https://issues.apache.org/jira/browse/AMBARI-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230317#comment-15230317
]
Hadoop QA commented on AMBARI-15761:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797522/AMBARI-15761.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6283//console
This message is automatically generated.
> While creating WEB URLs for Alerts, if we add http/https then we should not
> drop the URL path past port number
> --
>
> Key: AMBARI-15761
> URL: https://issues.apache.org/jira/browse/AMBARI-15761
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15761.patch
>
>
> As an example, look at the following alert:
>
>
>
> "APP_TIMELINE_SERVER": [
> {
> "name": "yarn_app_timeline_server_webui",
> "label": "App Timeline Web UI",
> "description": "This host-level alert is triggered if the App
> Timeline Server Web UI is unreachable.",
> "interval": 5,
> "scope": "ANY",
> "source": {
> "type": "WEB",
> "uri": {
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
> "https_property": "{{yarn-site/yarn.http.policy}}",
> "https_property_value": "HTTPS_ONLY",
> "kerberos_keytab":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
> "kerberos_principal":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
> "connection_timeout": 5.0
> },
> "reporting": {
> "ok": {
> "text": "HTTP {0} response in {2:.3f}s"
> },
> "warning":{
> "text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
> },
> "critical": {
> "text": "Connection failed to {1} ({3})"
> }
> }
> }
> }
> ]
> }
>
> Specifically lines:
>
>
>
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
>
> These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
> the form `host:port`. So the logic that adds http/https does not preserve that
> the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
[
https://issues.apache.org/jira/browse/AMBARI-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-15761:
-
Attachment: (was: AMBARI-15761.patch)
> While creating WEB URLs for Alerts, if we add http/https then we should not
> drop the URL path past port number
> --
>
> Key: AMBARI-15761
> URL: https://issues.apache.org/jira/browse/AMBARI-15761
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15761.patch
>
>
> As an example, look at the following alert:
>
>
>
> "APP_TIMELINE_SERVER": [
> {
> "name": "yarn_app_timeline_server_webui",
> "label": "App Timeline Web UI",
> "description": "This host-level alert is triggered if the App
> Timeline Server Web UI is unreachable.",
> "interval": 5,
> "scope": "ANY",
> "source": {
> "type": "WEB",
> "uri": {
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
> "https_property": "{{yarn-site/yarn.http.policy}}",
> "https_property_value": "HTTPS_ONLY",
> "kerberos_keytab":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
> "kerberos_principal":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
> "connection_timeout": 5.0
> },
> "reporting": {
> "ok": {
> "text": "HTTP {0} response in {2:.3f}s"
> },
> "warning":{
> "text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
> },
> "critical": {
> "text": "Connection failed to {1} ({3})"
> }
> }
> }
> }
> ]
> }
>
> Specifically lines:
>
>
>
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
>
> These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
> the form `host:port`. So the logic that adds http/https does not preserve that
> the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
[
https://issues.apache.org/jira/browse/AMBARI-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-15761:
-
Attachment: AMBARI-15761.patch
> While creating WEB URLs for Alerts, if we add http/https then we should not
> drop the URL path past port number
> --
>
> Key: AMBARI-15761
> URL: https://issues.apache.org/jira/browse/AMBARI-15761
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15761.patch
>
>
> As an example, look at the following alert:
>
>
>
> "APP_TIMELINE_SERVER": [
> {
> "name": "yarn_app_timeline_server_webui",
> "label": "App Timeline Web UI",
> "description": "This host-level alert is triggered if the App
> Timeline Server Web UI is unreachable.",
> "interval": 5,
> "scope": "ANY",
> "source": {
> "type": "WEB",
> "uri": {
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
> "https_property": "{{yarn-site/yarn.http.policy}}",
> "https_property_value": "HTTPS_ONLY",
> "kerberos_keytab":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
> "kerberos_principal":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
> "connection_timeout": 5.0
> },
> "reporting": {
> "ok": {
> "text": "HTTP {0} response in {2:.3f}s"
> },
> "warning":{
> "text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
> },
> "critical": {
> "text": "Connection failed to {1} ({3})"
> }
> }
> }
> }
> ]
> }
>
> Specifically lines:
>
>
>
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
>
> These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
> the form `host:port`. So the logic that adds http/https does not preserve that
> the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15740) Unable to add multiple fencing methods for dfs.ha.fencing.methods via Ambari UI
[ https://issues.apache.org/jira/browse/AMBARI-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230338#comment-15230338 ] Andrii Babiichuk commented on AMBARI-15740: --- +1 for the patch > Unable to add multiple fencing methods for dfs.ha.fencing.methods via Ambari > UI > --- > > Key: AMBARI-15740 > URL: https://issues.apache.org/jira/browse/AMBARI-15740 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15740.patch > > > PROBLEM: Unable to add multiple fencing methods for dfs.ha.fencing.methods > via Ambari UI > STEPS TO REPRODUCE: > 1. Configure NN HA Via Ambari > 2. Goto HDFS Service configs > 3. Search for dfs.ha.fencing.methods property > 4. Try to add another fencing method, you wont be able to add -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15761) While creating WEB URLs for Alerts, if we add http/https then we should not drop the URL path past port number
[
https://issues.apache.org/jira/browse/AMBARI-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230345#comment-15230345
]
Hadoop QA commented on AMBARI-15761:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797524/AMBARI-15761.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 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6284//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6284//console
This message is automatically generated.
> While creating WEB URLs for Alerts, if we add http/https then we should not
> drop the URL path past port number
> --
>
> Key: AMBARI-15761
> URL: https://issues.apache.org/jira/browse/AMBARI-15761
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15761.patch
>
>
> As an example, look at the following alert:
>
>
>
> "APP_TIMELINE_SERVER": [
> {
> "name": "yarn_app_timeline_server_webui",
> "label": "App Timeline Web UI",
> "description": "This host-level alert is triggered if the App
> Timeline Server Web UI is unreachable.",
> "interval": 5,
> "scope": "ANY",
> "source": {
> "type": "WEB",
> "uri": {
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
> "https_property": "{{yarn-site/yarn.http.policy}}",
> "https_property_value": "HTTPS_ONLY",
> "kerberos_keytab":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.keytab}}",
> "kerberos_principal":
> "{{yarn-site/yarn.timeline-service.http-authentication.kerberos.principal}}",
> "connection_timeout": 5.0
> },
> "reporting": {
> "ok": {
> "text": "HTTP {0} response in {2:.3f}s"
> },
> "warning":{
> "text": "HTTP {0} response from {1} in {2:.3f}s ({3})"
> },
> "critical": {
> "text": "Connection failed to {1} ({3})"
> }
> }
> }
> }
> ]
> }
>
> Specifically lines:
>
>
>
> "http":
> "{{yarn-site/yarn.timeline-service.webapp.address}}/ws/v1/timeline",
> "https":
> "{{yarn-site/yarn.timeline-service.webapp.https.address}}/ws/v1/timeline",
>
> These properties e.g. `yarn-site/yarn.timeline-service.webapp.address` are of
> the form `host:port`. So the logic that adds http/https does not preserve that
> the URL has `ws/v1/timeline` at the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15762) Component install post processing can not be run in parallel
[
https://issues.apache.org/jira/browse/AMBARI-15762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-15762:
-
Status: Patch Available (was: Open)
> Component install post processing can not be run in parallel
>
>
> Key: AMBARI-15762
> URL: https://issues.apache.org/jira/browse/AMBARI-15762
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15762.patch
>
>
> **Problem**
> Ambari executes component installs in parallel on a host. Each install process
> in the post-install phase executes certain shared/common configuration
> directory related steps (stacks/HDP/2.0.6/hooks/after-
> INSTALL/scripts/shared_initialization.py:link_configs() -> ... -> /resource_ma
> nagement/libraries/functions/conf_select.py:convert_conf_directories_to_symlin
> ks() ) on the directories listed in conf_select.py:PACKAGE_DIRS
> The common configuration directory related processing fail in they are kicked
> of in the same time for the same directory.
> In the case the following code snippet is executed in the same time by
> multiple component installs
> each will see the `backup_dir` as non existent and will try to execute the
> "cp" command. One will succeed while the others fail.
>
>
>
> Execute(("cp", "-R", "-p", old_conf, backup_dir), not_if = format("test
> -e {backup_dir}"), sudo = True)
>
> Similar behaviour is seen for the following code snippet:
>
>
>
> Execute(as_sudo(["cp", "-R", "-p", os.path.join(old_conf, "*"),
> versioned_conf], auto_escape=False), only_if = format("ls -d {old_conf}/*"))
>
> **Possible solution**
> Use the linux "lockfile" command or "mkdir /var/lock/mylock" (see example of
> the mkdir solution here: )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15762) Component install post processing can not be run in parallel
Andrew Onischuk created AMBARI-15762:
Summary: Component install post processing can not be run in
parallel
Key: AMBARI-15762
URL: https://issues.apache.org/jira/browse/AMBARI-15762
Project: Ambari
Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
Fix For: 2.2.2
Attachments: AMBARI-15762.patch
**Problem**
Ambari executes component installs in parallel on a host. Each install process
in the post-install phase executes certain shared/common configuration
directory related steps (stacks/HDP/2.0.6/hooks/after-
INSTALL/scripts/shared_initialization.py:link_configs() -> ... -> /resource_ma
nagement/libraries/functions/conf_select.py:convert_conf_directories_to_symlin
ks() ) on the directories listed in conf_select.py:PACKAGE_DIRS
The common configuration directory related processing fail in they are kicked
of in the same time for the same directory.
In the case the following code snippet is executed in the same time by
multiple component installs
each will see the `backup_dir` as non existent and will try to execute the
"cp" command. One will succeed while the others fail.
Execute(("cp", "-R", "-p", old_conf, backup_dir), not_if = format("test -e
{backup_dir}"), sudo = True)
Similar behaviour is seen for the following code snippet:
Execute(as_sudo(["cp", "-R", "-p", os.path.join(old_conf, "*"),
versioned_conf], auto_escape=False), only_if = format("ls -d {old_conf}/*"))
**Possible solution**
Use the linux "lockfile" command or "mkdir /var/lock/mylock" (see example of
the mkdir solution here: )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15762) Component install post processing can not be run in parallel
[
https://issues.apache.org/jira/browse/AMBARI-15762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-15762:
-
Attachment: AMBARI-15762.patch
> Component install post processing can not be run in parallel
>
>
> Key: AMBARI-15762
> URL: https://issues.apache.org/jira/browse/AMBARI-15762
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-15762.patch
>
>
> **Problem**
> Ambari executes component installs in parallel on a host. Each install process
> in the post-install phase executes certain shared/common configuration
> directory related steps (stacks/HDP/2.0.6/hooks/after-
> INSTALL/scripts/shared_initialization.py:link_configs() -> ... -> /resource_ma
> nagement/libraries/functions/conf_select.py:convert_conf_directories_to_symlin
> ks() ) on the directories listed in conf_select.py:PACKAGE_DIRS
> The common configuration directory related processing fail in they are kicked
> of in the same time for the same directory.
> In the case the following code snippet is executed in the same time by
> multiple component installs
> each will see the `backup_dir` as non existent and will try to execute the
> "cp" command. One will succeed while the others fail.
>
>
>
> Execute(("cp", "-R", "-p", old_conf, backup_dir), not_if = format("test
> -e {backup_dir}"), sudo = True)
>
> Similar behaviour is seen for the following code snippet:
>
>
>
> Execute(as_sudo(["cp", "-R", "-p", os.path.join(old_conf, "*"),
> versioned_conf], auto_escape=False), only_if = format("ls -d {old_conf}/*"))
>
> **Possible solution**
> Use the linux "lockfile" command or "mkdir /var/lock/mylock" (see example of
> the mkdir solution here: )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Gergely updated AMBARI-15646:
Attachment: AMBARI-15646.patch
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> private void auditLog(HostRoleCommandEntity
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Gergely updated AMBARI-15646:
Attachment: (was: AMBARI-15646.patch)
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> private void auditLog(HostRoleCo
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Gergely updated AMBARI-15646:
Status: Patch Available (was: In Progress)
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> private void auditLog(HostRole
[jira] [Created] (AMBARI-15763) Delete service: UX edits v2
Antonenko Alexander created AMBARI-15763: Summary: Delete service: UX edits v2 Key: AMBARI-15763 URL: https://issues.apache.org/jira/browse/AMBARI-15763 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Antonenko Alexander Assignee: Antonenko Alexander Fix For: 2.4.0 Minor text edit to dependent service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15740) Unable to add multiple fencing methods for dfs.ha.fencing.methods via Ambari UI
[
https://issues.apache.org/jira/browse/AMBARI-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230365#comment-15230365
]
Hadoop QA commented on AMBARI-15740:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12797351/AMBARI-15740.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/6285//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/6285//console
This message is automatically generated.
> Unable to add multiple fencing methods for dfs.ha.fencing.methods via Ambari
> UI
> ---
>
> Key: AMBARI-15740
> URL: https://issues.apache.org/jira/browse/AMBARI-15740
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15740.patch
>
>
> PROBLEM: Unable to add multiple fencing methods for dfs.ha.fencing.methods
> via Ambari UI
> STEPS TO REPRODUCE:
> 1. Configure NN HA Via Ambari
> 2. Goto HDFS Service configs
> 3. Search for dfs.ha.fencing.methods property
> 4. Try to add another fencing method, you wont be able to add
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
