[jira] [Updated] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts

2017-12-15 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivér Szabó updated AMBARI-22647:
--
Description: 
Goals:
- package logsearch / logfeeder classes into jars
- create default logsearch-env and logfeeder-env files (those where only 
generated by ambari stack code)
- rename run.sh start scripts to logsearch.sh and logfeeder.sh, and create a 
symlink for those in /usr/bin/
(therefore we can call commands like: 'logsearch start' or 'logfeeder test 
--test-log-entry ...')
- refactor logfeeder command line tool -> new java entry point -> use it 
through /usr/bin/logfeeder
- remove pid / process handling logic from ambari stack code (as the new 
logsaerch/logfeeder script will handle those)
- move all config files from classes target/package/conf during maven package 
phase
- move "/etc/ambari-logsearch-.../conf" folder to 
/usr/lib/ambari-logsearch.../conf, keep the old one as a symlink. (this 
solution is useful as we can include every requried files in a tar.gz as well 
and it can work without provided rpm/deb)
- as conf file was moved out, we need to handle some cases during yum/apt 
upgrade - move conf/keys/ or conf/checkpoints/ files to the new location (as 
those could be generated there before and we do not want to loose them)
- as conf files are moved, cleanup maven assembly configs
- upgrade docker environment to make it work with the new changes

  was:
Goals:
- package logsearch / logfeeder classes into jars
- create default logsearch-env and logfeeder-env files (those where only 
generated by ambari stack code)
- rename run.sh start scripts to logsearch.sh and logfeeder.sh, and create a 
symlink for those in /usr/bin/
(therefore we can call commands like: 'logsearch start' or 'logfeeder test 
--test-log-entry ...')
- refactor logfeeder command line tool -> new java entry point -> use it 
through /usr/bin/logfeeder
- remove pid / process handling logic from ambari stack code (as the new 
logsaerch/logfeeder script will handle those)
- move all config files from classes target/package/conf during maven package 
phase
- move "/etc/ambari-logsearch-.../conf" folder to 
/usr/lib/ambari-logsearch.../conf, keep the old one as a symlink. (this 
solution is useful as we can include every requried files in a tar.gz as well 
and it can work without provided rpm/deb)
- as conf file was moved out, we need to handle some cases during yum/apt 
upgrade - move conf/keys/ or conf/checkpoints/ files to the new location (as 
those could be generated there before and we do not want to loose them)
- as conf files are moved, cleanup maven assembly configs


> Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
> -
>
> Key: AMBARI-22647
> URL: https://issues.apache.org/jira/browse/AMBARI-22647
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 3.0.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 3.0.0
>
>
> Goals:
> - package logsearch / logfeeder classes into jars
> - create default logsearch-env and logfeeder-env files (those where only 
> generated by ambari stack code)
> - rename run.sh start scripts to logsearch.sh and logfeeder.sh, and create a 
> symlink for those in /usr/bin/
> (therefore we can call commands like: 'logsearch start' or 'logfeeder test 
> --test-log-entry ...')
> - refactor logfeeder command line tool -> new java entry point -> use it 
> through /usr/bin/logfeeder
> - remove pid / process handling logic from ambari stack code (as the new 
> logsaerch/logfeeder script will handle those)
> - move all config files from classes target/package/conf during maven package 
> phase
> - move "/etc/ambari-logsearch-.../conf" folder to 
> /usr/lib/ambari-logsearch.../conf, keep the old one as a symlink. (this 
> solution is useful as we can include every requried files in a tar.gz as well 
> and it can work without provided rpm/deb)
> - as conf file was moved out, we need to handle some cases during yum/apt 
> upgrade - move conf/keys/ or conf/checkpoints/ files to the new location (as 
> those could be generated there before and we do not want to loose them)
> - as conf files are moved, cleanup maven assembly configs
> - upgrade docker environment to make it work with the new changes



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts

2017-12-15 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivér Szabó updated AMBARI-22647:
--
Description: 
Goals:
- package logsearch / logfeeder classes into jars
- create default logsearch-env and logfeeder-env files (those where only 
generated by ambari stack code)
- rename run.sh start scripts to logsearch.sh and logfeeder.sh, and create a 
symlink for those in /usr/bin/
(therefore we can call commands like: 'logsearch start' or 'logfeeder test 
--test-log-entry ...')
- refactor logfeeder command line tool -> new java entry point -> use it 
through /usr/bin/logfeeder
- remove pid / process handling logic from ambari stack code (as the new 
logsaerch/logfeeder script will handle those)
- move all config files from classes target/package/conf during maven package 
phase
- move "/etc/ambari-logsearch-.../conf" folder to 
/usr/lib/ambari-logsearch.../conf, keep the old one as a symlink. (this 
solution is useful as we can include every requried files in a tar.gz as well 
and it can work without provided rpm/deb)
- as conf file was moved out, we need to handle some cases during yum/apt 
upgrade - move conf/keys/ or conf/checkpoints/ files to the new location (as 
those could be generated there before and we do not want to loose them)
- as conf files are moved, cleanup maven assembly configs

> Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
> -
>
> Key: AMBARI-22647
> URL: https://issues.apache.org/jira/browse/AMBARI-22647
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 3.0.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 3.0.0
>
>
> Goals:
> - package logsearch / logfeeder classes into jars
> - create default logsearch-env and logfeeder-env files (those where only 
> generated by ambari stack code)
> - rename run.sh start scripts to logsearch.sh and logfeeder.sh, and create a 
> symlink for those in /usr/bin/
> (therefore we can call commands like: 'logsearch start' or 'logfeeder test 
> --test-log-entry ...')
> - refactor logfeeder command line tool -> new java entry point -> use it 
> through /usr/bin/logfeeder
> - remove pid / process handling logic from ambari stack code (as the new 
> logsaerch/logfeeder script will handle those)
> - move all config files from classes target/package/conf during maven package 
> phase
> - move "/etc/ambari-logsearch-.../conf" folder to 
> /usr/lib/ambari-logsearch.../conf, keep the old one as a symlink. (this 
> solution is useful as we can include every requried files in a tar.gz as well 
> and it can work without provided rpm/deb)
> - as conf file was moved out, we need to handle some cases during yum/apt 
> upgrade - move conf/keys/ or conf/checkpoints/ files to the new location (as 
> those could be generated there before and we do not want to loose them)
> - as conf files are moved, cleanup maven assembly configs



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts

2017-12-15 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivér Szabó updated AMBARI-22647:
--
Summary: Rafactor: Package Log Search and Log Feeder into jars + cleanup 
start scripts  (was: Package Log Search and Log Feeder into jars)

> Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
> -
>
> Key: AMBARI-22647
> URL: https://issues.apache.org/jira/browse/AMBARI-22647
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 3.0.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (AMBARI-22659) unable to proceed with cluster install after component install fails

2017-12-15 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-22659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293160#comment-16293160
 ] 

Hudson commented on AMBARI-22659:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #8526 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/8526/])
AMBARI-22659. unable to proceed with cluster install after component 
(mpapyrkovskyy: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=856d9a53d39b1658a846311d672ba54699b73f90])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostVersionEntity.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostVersionDAO.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/HostVersionDAOTest.java


> unable to proceed with cluster install after component install fails
> 
>
> Key: AMBARI-22659
> URL: https://issues.apache.org/jira/browse/AMBARI-22659
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Myroslav Papirkovskyi
>Assignee: Myroslav Papirkovskyi
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Unable go back in install wizard if install was finished at one of hosts.
> {code}
> Request 
> URL:http://ambari:8080/api/v1/stacks/HDP/versions/2.6/repository_versions/1
> {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: 
> Repository version can't be deleted as it is used by the following hosts: 
> CURRENT on sanjay-divgi-test-2.openstacklocal, 
> sanjay-divgi-test-5.openstacklocal, sanjay-divgi-test-1.openstacklocal, 
> sanjay-divgi-test-4.openstacklocal"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (AMBARI-22659) unable to proceed with cluster install after component install fails

2017-12-15 Thread Myroslav Papirkovskyi (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myroslav Papirkovskyi resolved AMBARI-22659.

Resolution: Fixed

Pushed to trunk

> unable to proceed with cluster install after component install fails
> 
>
> Key: AMBARI-22659
> URL: https://issues.apache.org/jira/browse/AMBARI-22659
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Myroslav Papirkovskyi
>Assignee: Myroslav Papirkovskyi
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Unable go back in install wizard if install was finished at one of hosts.
> {code}
> Request 
> URL:http://ambari:8080/api/v1/stacks/HDP/versions/2.6/repository_versions/1
> {
>   "status" : 500,
>   "message" : "org.apache.ambari.server.controller.spi.SystemException: 
> Repository version can't be deleted as it is used by the following hosts: 
> CURRENT on sanjay-divgi-test-2.openstacklocal, 
> sanjay-divgi-test-5.openstacklocal, sanjay-divgi-test-1.openstacklocal, 
> sanjay-divgi-test-4.openstacklocal"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (AMBARI-22571) Handle passwords/sensitive data in Ambari configuration properties

2017-12-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292894#comment-16292894
 ] 

Hadoop QA commented on AMBARI-22571:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12902256/AMBARI_22571_trunk_01.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

  {color:red}-1 javac{color}.  The applied patch generated 587 javac 
compiler warnings (more than the trunk's current 534 warnings).

{color:red}-1 core tests{color}.  The patch failed these unit tests in 
ambari-server:

  org.apache.ambari.server.topology.BlueprintImplTest

Javac warnings: 
https://builds.apache.org/job/Ambari-trunk-test-patch/12849//artifact/patch-work/diffJavacWarnings.txt
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/12849//console

This message is automatically generated.

> Handle passwords/sensitive data in Ambari configuration properties
> --
>
> Key: AMBARI-22571
> URL: https://issues.apache.org/jira/browse/AMBARI-22571
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Minor
>  Labels: config, security
> Fix For: trunk
>
> Attachments: AMBARI_22571_trunk_01.patch
>
>
> Passwords and other sensitive data stored as values to properties in Ambari 
> configurations need to be masked or not stored in cleartext.
> For example, 
> {{ldap-configuration/ambari.ldap.connectivity.trust_store.password}} and 
> ldap-{{configuration/ambari.ldap.connectivity.bind_password}}.
> If the Ambari credential store is enabled (which might be by default as of 
> Ambari 3.0.0), the sensitive date can be stored there like we do when 
> sensitive data is to be stored in the ambari.properties file - see 
> {{org.apache.ambari.server.security.encryption.CredentialStoreService}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (AMBARI-22404) Set java.home. in ambari-server setup script for server OS family

2017-12-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-22404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292807#comment-16292807
 ] 

Hadoop QA commented on AMBARI-22404:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12902307/AMBARI-22404_branch-feature-AMBARI-21674_01.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-server.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/12848//console

This message is automatically generated.

> Set java.home. in ambari-server setup script for server OS family
> 
>
> Key: AMBARI-22404
> URL: https://issues.apache.org/jira/browse/AMBARI-22404
> Project: Ambari
>  Issue Type: Sub-task
>  Components: ambari-server
>Reporter: Yussuf Shaikh
>Assignee: Yussuf Shaikh
> Attachments: AMBARI-22404.patch, 
> AMBARI-22404_branch-feature-AMBARI-21674_01.patch
>
>
> Changes to ambari-server setup script for accepting user values for java_home 
> for OS type.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (AMBARI-22659) unable to proceed with cluster install after component install fails

2017-12-15 Thread Myroslav Papirkovskyi (JIRA)
Myroslav Papirkovskyi created AMBARI-22659:
--

 Summary: unable to proceed with cluster install after component 
install fails
 Key: AMBARI-22659
 URL: https://issues.apache.org/jira/browse/AMBARI-22659
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.6.1
Reporter: Myroslav Papirkovskyi
Assignee: Myroslav Papirkovskyi
Priority: Blocker
 Fix For: 3.0.0


Unable go back in install wizard if install was finished at one of hosts.

{code}
Request 
URL:http://ambari:8080/api/v1/stacks/HDP/versions/2.6/repository_versions/1

{
  "status" : 500,
  "message" : "org.apache.ambari.server.controller.spi.SystemException: 
Repository version can't be deleted as it is used by the following hosts: 
CURRENT on sanjay-divgi-test-2.openstacklocal, 
sanjay-divgi-test-5.openstacklocal, sanjay-divgi-test-1.openstacklocal, 
sanjay-divgi-test-4.openstacklocal"
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (AMBARI-22657) Oozie service check failed during 4th digit PU

2017-12-15 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-22657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292769#comment-16292769
 ] 

Hudson commented on AMBARI-22657:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8525 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/8525/])
AMBARI-22657 Oozie service check failed during 4th digit PU (dgrinenko) 
(hapylestat: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3ab1045c1f95a90159e69fbd934953927947c754])
* (edit) 
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_packages.json
* (edit) 
ambari-server/src/main/resources/stacks/HDP/3.0/properties/stack_packages.json


> Oozie service check failed during 4th digit PU
> --
>
> Key: AMBARI-22657
> URL: https://issues.apache.org/jira/browse/AMBARI-22657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.6.2
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.6.2
>
> Attachments: AMBARI-22657-trunk.patch, AMBARI-22657.patch
>
>
> {code}
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@a9aa286]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1046 bytes read, 0 bytes written, 0 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@511b97d4]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@3349e2ee]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:27 AM org.apache.catalina.core.StandardContext 
> resourcesStart
> SEVERE: Error starting static Resources
> java.lang.IllegalArgumentException: Document base 
> /usr/hdp/current/oozie-client/oozie-server/webapps/oozie does not exist or is 
> not a readable directory
> at 
> org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
> at 
> org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4390)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4563)
> at 
> org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1287)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385)
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:307)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
> at 
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1393)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1657)
> at 
> 

[jira] [Commented] (AMBARI-22658) Cannot write krbPasswordExpiry in FreeIPA

2017-12-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-22658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292750#comment-16292750
 ] 

Hadoop QA commented on AMBARI-22658:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12902393/IPKerberosOperationHandler-for-FreeIPA-4.3.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/12847//console

This message is automatically generated.

> Cannot write krbPasswordExpiry in FreeIPA
> -
>
> Key: AMBARI-22658
> URL: https://issues.apache.org/jira/browse/AMBARI-22658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.6.0
> Environment: Ubuntu 16.04 LTS with FreeIPA 4.3.1
>Reporter: Tobias Hofer
> Attachments: IPKerberosOperationHandler-for-FreeIPA-4.3.patch
>
>
> Ambari Server fails to change the krbPasswordExpiry date because of an 
> invalid date format.
> IPA fails to update the user by IPAKerberosOperationHandler.
> {code:java}
> user-mod %s --setattr krbPasswordExpiration=%s
> {code}
> The used format
> {noformat}
> MMddHHmmss.SSS'Z'
> {noformat}
> needs to be
> {noformat}
> MMddHHmmss'Z'
> {noformat}
> at least for the FreeIPA version distributed with Ubuntu 16.04.
> It would be great if Ambari is going to support FreeIPA 4.3.1 as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22657) Oozie service check failed during 4th digit PU

2017-12-15 Thread Dmytro Grinenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-22657:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed: 
 f1f730229f..3ab1045c1f  trunk -> trunk

> Oozie service check failed during 4th digit PU
> --
>
> Key: AMBARI-22657
> URL: https://issues.apache.org/jira/browse/AMBARI-22657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.6.2
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.6.2
>
> Attachments: AMBARI-22657-trunk.patch, AMBARI-22657.patch
>
>
> {code}
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@a9aa286]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1046 bytes read, 0 bytes written, 0 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@511b97d4]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@3349e2ee]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:27 AM org.apache.catalina.core.StandardContext 
> resourcesStart
> SEVERE: Error starting static Resources
> java.lang.IllegalArgumentException: Document base 
> /usr/hdp/current/oozie-client/oozie-server/webapps/oozie does not exist or is 
> not a readable directory
> at 
> org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
> at 
> org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4390)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4563)
> at 
> org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1287)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385)
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:307)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
> at 
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1393)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1657)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1666)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1646)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22657) Oozie service check failed during 4th digit PU

2017-12-15 Thread Dmytro Grinenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-22657:
-
Status: Patch Available  (was: In Progress)

> Oozie service check failed during 4th digit PU
> --
>
> Key: AMBARI-22657
> URL: https://issues.apache.org/jira/browse/AMBARI-22657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.6.2
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.6.2
>
> Attachments: AMBARI-22657-trunk.patch, AMBARI-22657.patch
>
>
> {code}
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@a9aa286]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1046 bytes read, 0 bytes written, 0 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@511b97d4]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@3349e2ee]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:27 AM org.apache.catalina.core.StandardContext 
> resourcesStart
> SEVERE: Error starting static Resources
> java.lang.IllegalArgumentException: Document base 
> /usr/hdp/current/oozie-client/oozie-server/webapps/oozie does not exist or is 
> not a readable directory
> at 
> org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
> at 
> org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4390)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4563)
> at 
> org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1287)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385)
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:307)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
> at 
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1393)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1657)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1666)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1646)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22657) Oozie service check failed during 4th digit PU

2017-12-15 Thread Dmytro Grinenko (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-22657:
-
Attachment: AMBARI-22657.patch
AMBARI-22657-trunk.patch

> Oozie service check failed during 4th digit PU
> --
>
> Key: AMBARI-22657
> URL: https://issues.apache.org/jira/browse/AMBARI-22657
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk, 2.6.2
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: trunk, 2.6.2
>
> Attachments: AMBARI-22657-trunk.patch, AMBARI-22657.patch
>
>
> {code}
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@a9aa286]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1046 bytes read, 0 bytes written, 0 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@511b97d4]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [org.apache.oozie.util.XLog$Info$1] (value 
> [org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
> [org.apache.oozie.util.XLog.Info] (value 
> [org.apache.oozie.util.XLog$Info@3349e2ee]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value 
> of type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value 
> [1884 bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write 
> ops]) but failed to remove it when the web application was stopped. This is 
> very likely to create a memory leak.
> Dec 04, 2017 2:40:27 AM org.apache.catalina.core.StandardContext 
> resourcesStart
> SEVERE: Error starting static Resources
> java.lang.IllegalArgumentException: Document base 
> /usr/hdp/current/oozie-client/oozie-server/webapps/oozie does not exist or is 
> not a readable directory
> at 
> org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
> at 
> org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4390)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4563)
> at 
> org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1287)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385)
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:307)
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
> at 
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1393)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1657)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1666)
> at 
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1646)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22658) Cannot write krbPasswordExpiry in FreeIPA

2017-12-15 Thread Tobias Hofer (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tobias Hofer updated AMBARI-22658:
--
Attachment: IPKerberosOperationHandler-for-FreeIPA-4.3.patch

> Cannot write krbPasswordExpiry in FreeIPA
> -
>
> Key: AMBARI-22658
> URL: https://issues.apache.org/jira/browse/AMBARI-22658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.6.0
> Environment: Ubuntu 16.04 LTS with FreeIPA 4.3.1
>Reporter: Tobias Hofer
> Attachments: IPKerberosOperationHandler-for-FreeIPA-4.3.patch
>
>
> Ambari Server fails to change the krbPasswordExpiry date because of an 
> invalid date format.
> IPA fails to update the user by IPAKerberosOperationHandler.
> {code:java}
> user-mod %s --setattr krbPasswordExpiration=%s
> {code}
> The used format
> {noformat}
> MMddHHmmss.SSS'Z'
> {noformat}
> needs to be
> {noformat}
> MMddHHmmss'Z'
> {noformat}
> at least for the FreeIPA version distributed with Ubuntu 16.04.
> It would be great if Ambari is going to support FreeIPA 4.3.1 as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22658) Cannot write krbPasswordExpiry in FreeIPA

2017-12-15 Thread Tobias Hofer (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tobias Hofer updated AMBARI-22658:
--
Status: Patch Available  (was: Open)

> Cannot write krbPasswordExpiry in FreeIPA
> -
>
> Key: AMBARI-22658
> URL: https://issues.apache.org/jira/browse/AMBARI-22658
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.6.0
> Environment: Ubuntu 16.04 LTS with FreeIPA 4.3.1
>Reporter: Tobias Hofer
>
> Ambari Server fails to change the krbPasswordExpiry date because of an 
> invalid date format.
> IPA fails to update the user by IPAKerberosOperationHandler.
> {code:java}
> user-mod %s --setattr krbPasswordExpiration=%s
> {code}
> The used format
> {noformat}
> MMddHHmmss.SSS'Z'
> {noformat}
> needs to be
> {noformat}
> MMddHHmmss'Z'
> {noformat}
> at least for the FreeIPA version distributed with Ubuntu 16.04.
> It would be great if Ambari is going to support FreeIPA 4.3.1 as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (AMBARI-22658) Cannot write krbPasswordExpiry in FreeIPA

2017-12-15 Thread Tobias Hofer (JIRA)
Tobias Hofer created AMBARI-22658:
-

 Summary: Cannot write krbPasswordExpiry in FreeIPA
 Key: AMBARI-22658
 URL: https://issues.apache.org/jira/browse/AMBARI-22658
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.6.0
 Environment: Ubuntu 16.04 LTS with FreeIPA 4.3.1
Reporter: Tobias Hofer


Ambari Server fails to change the krbPasswordExpiry date because of an invalid 
date format.

IPA fails to update the user by IPAKerberosOperationHandler.
{code:java}
user-mod %s --setattr krbPasswordExpiration=%s
{code}

The used format
{noformat}
MMddHHmmss.SSS'Z'
{noformat}

needs to be
{noformat}
MMddHHmmss'Z'
{noformat}

at least for the FreeIPA version distributed with Ubuntu 16.04.

It would be great if Ambari is going to support FreeIPA 4.3.1 as well.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (AMBARI-22654) Kerberos: Kerberos-related tasks occur after INSTALL stage of services being added

2017-12-15 Thread Maciej Sitarz (JIRA)

[ 
https://issues.apache.org/jira/browse/AMBARI-22654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292571#comment-16292571
 ] 

Maciej Sitarz commented on AMBARI-22654:


I just now checked on Ambari version 2.6.0. Exactly the same problem occurs.

> Kerberos: Kerberos-related tasks occur after INSTALL stage of services being 
> added
> --
>
> Key: AMBARI-22654
> URL: https://issues.apache.org/jira/browse/AMBARI-22654
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.3, 2.5.2, 2.6.0
>Reporter: Maciej Sitarz
>Assignee: Robert Levas
>Priority: Critical
> Attachments: SAMPLESRV2_v1.tgz, all_hosts.png, host1_master.png, 
> host2_master.png, host3_slave.png, host4_client.png, host5_slave_client.png
>
>
> Kerberos-related configs (keytab,principal creation) are not applied before 
> INSTALL command is built on add service.
> This occurs when new services and components are added to an existing cluster 
> where Kerberos is enabled. Due to the order Kerberos-related configurations 
> (keytabs, principals) will not be available for new services INSTALL step 
> functions.
> This seems to be identical problem to the one mentioned in #AMBARI-17772



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22654) Kerberos: Kerberos-related tasks occur after INSTALL stage of services being added

2017-12-15 Thread Maciej Sitarz (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maciej Sitarz updated AMBARI-22654:
---
Affects Version/s: 2.6.0

> Kerberos: Kerberos-related tasks occur after INSTALL stage of services being 
> added
> --
>
> Key: AMBARI-22654
> URL: https://issues.apache.org/jira/browse/AMBARI-22654
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.3, 2.5.2, 2.6.0
>Reporter: Maciej Sitarz
>Assignee: Robert Levas
>Priority: Critical
> Attachments: SAMPLESRV2_v1.tgz, all_hosts.png, host1_master.png, 
> host2_master.png, host3_slave.png, host4_client.png, host5_slave_client.png
>
>
> Kerberos-related configs (keytab,principal creation) are not applied before 
> INSTALL command is built on add service.
> This occurs when new services and components are added to an existing cluster 
> where Kerberos is enabled. Due to the order Kerberos-related configurations 
> (keytabs, principals) will not be available for new services INSTALL step 
> functions.
> This seems to be identical problem to the one mentioned in #AMBARI-17772



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (AMBARI-22650) Add ability to define packages at stack level

2017-12-15 Thread Dmytro Sen (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Sen resolved AMBARI-22650.
-
Resolution: Fixed

Committed into branch-feature-AMBARI-14714

> Add ability to define packages at stack level
> -
>
> Key: AMBARI-22650
> URL: https://issues.apache.org/jira/browse/AMBARI-22650
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Today, we define the list of packages to be installed at individual service 
> level metainfo.xml. 
> In the new mpack model Ambari will no longer execute (i.e. "yum install 
> hadoop", "yum install hadoop-client"), but instead Ambari will install 
> individual mpack meta-rpms (i.e. "yum install hdpcore", "yum install edw") 
> whenever a component from that mpack is installed. 
> So we should add ability to define list of packages at the stack level (i.e. 
> stack/metainfo.xml). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22404) Set java.home. in ambari-server setup script for server OS family

2017-12-15 Thread Yussuf Shaikh (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yussuf Shaikh updated AMBARI-22404:
---
Attachment: AMBARI-22404_branch-feature-AMBARI-21674_01.patch

> Set java.home. in ambari-server setup script for server OS family
> 
>
> Key: AMBARI-22404
> URL: https://issues.apache.org/jira/browse/AMBARI-22404
> Project: Ambari
>  Issue Type: Sub-task
>  Components: ambari-server
>Reporter: Yussuf Shaikh
>Assignee: Yussuf Shaikh
> Attachments: AMBARI-22404.patch, 
> AMBARI-22404_branch-feature-AMBARI-21674_01.patch
>
>
> Changes to ambari-server setup script for accepting user values for java_home 
> for OS type.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (AMBARI-22657) Oozie service check failed during 4th digit PU

2017-12-15 Thread Dmytro Grinenko (JIRA)
Dmytro Grinenko created AMBARI-22657:


 Summary: Oozie service check failed during 4th digit PU
 Key: AMBARI-22657
 URL: https://issues.apache.org/jira/browse/AMBARI-22657
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: trunk, 2.6.2
Reporter: Dmytro Grinenko
Assignee: Dmytro Grinenko
Priority: Critical
 Fix For: trunk, 2.6.2


{code}
SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value of 
type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value [1884 
bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write ops]) but 
failed to remove it when the web application was stopped. This is very likely 
to create a memory leak.
Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@a9aa286]) and a value of 
type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value [1046 
bytes read, 0 bytes written, 0 read ops, 0 large read ops, 0 write ops]) but 
failed to remove it when the web application was stopped. This is very likely 
to create a memory leak.
Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
[org.apache.oozie.util.XLog$Info$1] (value 
[org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
[org.apache.oozie.util.XLog.Info] (value 
[org.apache.oozie.util.XLog$Info@511b97d4]) but failed to remove it when the 
web application was stopped. This is very likely to create a memory leak.
Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
[org.apache.oozie.util.XLog$Info$1] (value 
[org.apache.oozie.util.XLog$Info$1@e4a9a09]) and a value of type 
[org.apache.oozie.util.XLog.Info] (value 
[org.apache.oozie.util.XLog$Info@3349e2ee]) but failed to remove it when the 
web application was stopped. This is very likely to create a memory leak.
Dec 04, 2017 2:40:26 AM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/oozie] created a ThreadLocal with key of type 
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@724836f5]) and a value of 
type [org.apache.hadoop.fs.FileSystem.Statistics.StatisticsData] (value [1884 
bytes read, 0 bytes written, 23 read ops, 0 large read ops, 0 write ops]) but 
failed to remove it when the web application was stopped. This is very likely 
to create a memory leak.
Dec 04, 2017 2:40:27 AM org.apache.catalina.core.StandardContext resourcesStart
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base 
/usr/hdp/current/oozie-client/oozie-server/webapps/oozie does not exist or is 
not a readable directory
at 
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
at 
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4390)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4563)
at 
org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1287)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:307)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at 
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1393)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1657)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1666)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1646)
at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22571) Handle passwords/sensitive data in Ambari configuration properties

2017-12-15 Thread Sandor Molnar (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandor Molnar updated AMBARI-22571:
---
Status: Patch Available  (was: In Progress)

> Handle passwords/sensitive data in Ambari configuration properties
> --
>
> Key: AMBARI-22571
> URL: https://issues.apache.org/jira/browse/AMBARI-22571
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Minor
>  Labels: config, security
> Fix For: trunk
>
> Attachments: AMBARI_22571_trunk_01.patch
>
>
> Passwords and other sensitive data stored as values to properties in Ambari 
> configurations need to be masked or not stored in cleartext.
> For example, 
> {{ldap-configuration/ambari.ldap.connectivity.trust_store.password}} and 
> ldap-{{configuration/ambari.ldap.connectivity.bind_password}}.
> If the Ambari credential store is enabled (which might be by default as of 
> Ambari 3.0.0), the sensitive date can be stored there like we do when 
> sensitive data is to be stored in the ambari.properties file - see 
> {{org.apache.ambari.server.security.encryption.CredentialStoreService}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (AMBARI-22571) Handle passwords/sensitive data in Ambari configuration properties

2017-12-15 Thread Sandor Molnar (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandor Molnar updated AMBARI-22571:
---
Attachment: AMBARI_22571_trunk_01.patch

> Handle passwords/sensitive data in Ambari configuration properties
> --
>
> Key: AMBARI-22571
> URL: https://issues.apache.org/jira/browse/AMBARI-22571
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Minor
>  Labels: config, security
> Fix For: trunk
>
> Attachments: AMBARI_22571_trunk_01.patch
>
>
> Passwords and other sensitive data stored as values to properties in Ambari 
> configurations need to be masked or not stored in cleartext.
> For example, 
> {{ldap-configuration/ambari.ldap.connectivity.trust_store.password}} and 
> ldap-{{configuration/ambari.ldap.connectivity.bind_password}}.
> If the Ambari credential store is enabled (which might be by default as of 
> Ambari 3.0.0), the sensitive date can be stored there like we do when 
> sensitive data is to be stored in the ambari.properties file - see 
> {{org.apache.ambari.server.security.encryption.CredentialStoreService}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (AMBARI-22656) Add slot info for Hosts page

2017-12-15 Thread mathildaMa09 (JIRA)
mathildaMa09 created AMBARI-22656:
-

 Summary: Add slot info for Hosts page
 Key: AMBARI-22656
 URL: https://issues.apache.org/jira/browse/AMBARI-22656
 Project: Ambari
  Issue Type: Improvement
  Components: ambari-agent, ambari-server, ambari-web
Affects Versions: 2.5.2
Reporter: mathildaMa09


In Hosts Page lists info about hosts like Rack、IP、Cores、DiskUsage .etc, but I 
need more details about my hosts’ physical position, like slot for instance, to 
know exactly where my machine locates. So, in hosts page, we can add slot info 
to describe their location. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)