[jira] [Updated] (AMBARI-22571) Handle passwords/sensitive data in Ambari configuration properties
[
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated AMBARI-22571:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> 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-22571) Handle passwords/sensitive data in Ambari configuration properties
[
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296220#comment-16296220
]
Hudson commented on AMBARI-22571:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8532 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/8532/])
AMBARI-22571. Handle passwords/sensitive data in Ambari configuration (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=be0e87bef52458955eddf1b824e6c5ddc6f31de6])
* (add)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AmbariServerConfigurationUtils.java
* (edit) ambari-server/pom.xml
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RootServiceComponentConfigurationResourceProvider.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RootServiceComponentConfigurationHandler.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AmbariServerLDAPConfigurationHandler.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/configuration/ConfigurationPropertyType.java
* (add)
ambari-server/src/main/java/org/apache/ambari/server/api/services/RootServiceComponentConfiguration.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/RootServiceComponentConfigurationResourceProviderTest.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AmbariServerConfigurationHandler.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/ldap/domain/AmbariLdapConfigurationKeys.java
> 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-22656) Add slot info for Hosts page
[
https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296194#comment-16296194
]
Hadoop QA commented on AMBARI-22656:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12902754/hostDetails.png
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/12857//console
This message is automatically generated.
> 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
> Fix For: 2.5.2
>
> Attachments: AMBARI-22656-branch-2.5.patch, hostDetails.png,
> hostPage.png
>
>
> 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)
[jira] [Commented] (AMBARI-22571) Handle passwords/sensitive data in Ambari configuration properties
[
https://issues.apache.org/jira/browse/AMBARI-22571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296195#comment-16296195
]
Robert Levas commented on AMBARI-22571:
---
Committed to trunk
{noformat}
commit be0e87bef52458955eddf1b824e6c5ddc6f31de6
Author: Sandor Molnar
Date: Mon Dec 18 23:38:29 2017 -0500
{noformat}
[~smolnar], This has been committed to the trunk. You can resolve this JIRA and
close the ReviewBoard.
> 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-22656) Add slot info for Hosts page
[ https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mathildaMa09 updated AMBARI-22656: -- Attachment: hostDetails.png hostPage.png > 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 > Fix For: 2.5.2 > > Attachments: AMBARI-22656-branch-2.5.patch, hostDetails.png, > hostPage.png > > > 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)
[jira] [Updated] (AMBARI-22656) Add slot info for Hosts page
[ https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mathildaMa09 updated AMBARI-22656: -- Attachment: (was: 2.png) > 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 > Fix For: 2.5.2 > > Attachments: AMBARI-22656-branch-2.5.patch > > > 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)
[jira] [Updated] (AMBARI-22656) Add slot info for Hosts page
[ https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mathildaMa09 updated AMBARI-22656: -- Attachment: (was: 1.png) > 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 > Fix For: 2.5.2 > > Attachments: AMBARI-22656-branch-2.5.patch > > > 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)
[jira] [Updated] (AMBARI-22656) Add slot info for Hosts page
[ https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mathildaMa09 updated AMBARI-22656: -- Attachment: AMBARI-22656-branch-2.5.patch 1.png 2.png > 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 > Fix For: 2.5.2 > > Attachments: 1.png, 2.png, AMBARI-22656-branch-2.5.patch > > > 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)
[jira] [Comment Edited] (AMBARI-22656) Add slot info for Hosts page
[ https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296031#comment-16296031 ] mathildaMa09 edited comment on AMBARI-22656 at 12/19/17 2:08 AM: - Comments: Totally changes on web UI: 1、 In Hosts page, add 1 column “slot”; 2、 Editable slot info is added when check details about host. was (Author: mathildama09): Comments: Totally changes on web UI: 1、 In Hosts page, add 1 column “slot”; 2、 Editable slot info is added when check details about host. > 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 > Fix For: 2.5.2 > > > 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)
[jira] [Updated] (AMBARI-22656) Add slot info for Hosts page
[ https://issues.apache.org/jira/browse/AMBARI-22656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mathildaMa09 updated AMBARI-22656: -- Fix Version/s: 2.5.2 Status: Patch Available (was: Open) Comments: Totally changes on web UI: 1、 In Hosts page, add 1 column “slot”; 2、 Editable slot info is added when check details about host. > 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 > Fix For: 2.5.2 > > > 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)
[jira] [Created] (AMBARI-22666) Ambari should upload dependencies for Yarn services to HDFS
Yesha Vora created AMBARI-22666: --- Summary: Ambari should upload dependencies for Yarn services to HDFS Key: AMBARI-22666 URL: https://issues.apache.org/jira/browse/AMBARI-22666 Project: Ambari Issue Type: Bug Affects Versions: 3.0.0 Reporter: Yesha Vora Scenario: 1) Install Hadoop 3.0 cluster 2) Run Yarn service application yarn app -launch my-sleeper1 sleeper.json Here, the first application will start to upload Hadoop libs etc to HDFS which makes submission of the application slow. Thus, Ambari should upload all necessary files to HDFS as part of either yarn service check or yarn install. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22249) Add service group dependencies
[ https://issues.apache.org/jira/browse/AMBARI-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-22249: --- Attachment: AMBARI-22249_part3.patch > Add service group dependencies > -- > > Key: AMBARI-22249 > URL: https://issues.apache.org/jira/browse/AMBARI-22249 > Project: Ambari > Issue Type: Task > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 3.0.0 > > Attachments: AMBARI-22249.patch, AMBARI-22249_part2.patch, > AMBARI-22249_part3.patch > > > Add table servicegroupdependencies -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
[ https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295755#comment-16295755 ] Hudson commented on AMBARI-22647: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8531 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8531/]) AMBARI-22647. ADDENDUM -Rafactor: Package Log Search and Log Feeder into (oleewere: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=afe469c98564aa7face62fe185eeb50b9b322e5f]) * (edit) ambari-logsearch/ambari-logsearch-logfeeder/src/main/scripts/logfeeder.sh * (edit) ambari-logsearch/ambari-logsearch-logfeeder/src/main/resources/logfeeder.properties * (edit) ambari-logsearch/ambari-logsearch-server/src/main/scripts/logsearch.sh * (edit) ambari-logsearch/docker/bin/start.sh > 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] [Commented] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295747#comment-16295747
]
Hadoop QA commented on AMBARI-22665:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12902686/AMBARI-22665.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/12856//console
This message is automatically generated.
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMBARI-22522) Livy server fails to start during downgrade due to absence of 'conf' directory
[
https://issues.apache.org/jira/browse/AMBARI-22522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295711#comment-16295711
]
Hudson commented on AMBARI-22522:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8530 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/8530/])
AMBARI-22522 - Livy server fails to start during downgrade due to (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=2817ad481507033bccd1732943c305108585dc4b])
* (edit)
ambari-server/src/main/resources/custom_actions/scripts/install_packages.py
> Livy server fails to start during downgrade due to absence of 'conf' directory
> --
>
> Key: AMBARI-22522
> URL: https://issues.apache.org/jira/browse/AMBARI-22522
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.1
>
> Attachments: AMBARI-22522.patch
>
>
> *STR*
> # Deployed cluster with Ambari version: 2.4.3.0-30 and HDP version:
> 2.5.5.0-157
> # Upgrade Ambari to 2.6.1.0-43
> # Start EU to 2.6.4.0-36 and downgrade at final step
> *Result*
> Observed during downgrade that Livy server start failed with below error:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/SPARK/1.2.1/package/scripts/livy_server.py",
> line 141, in
> LivyServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 367, in execute
> method(env)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 970, in restart
> self.start(env, upgrade_type=upgrade_type)
> File
> "/var/lib/ambari-agent/cache/common-services/SPARK/1.2.1/package/scripts/livy_server.py",
> line 61, in start
> self.configure(env)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 120, in locking_configure
> original_configure(obj, *args, **kw)
> File
> "/var/lib/ambari-agent/cache/common-services/SPARK/1.2.1/package/scripts/livy_server.py",
> line 51, in configure
> setup_livy(env, 'server', upgrade_type=upgrade_type, action = 'config')
> File
> "/var/lib/ambari-agent/cache/common-services/SPARK/1.2.1/package/scripts/setup_livy.py",
> line 56, in setup_livy
> mode=0644,
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 166, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
> line 120, in action_create
> raise Fail("Applying %s failed, parent directory %s doesn't exist" %
> (self.resource, dirname))
> resource_management.core.exceptions.Fail: Applying
> File['/usr/hdp/current/livy-server/conf/livy-env.sh'] failed, parent
> directory /usr/hdp/current/livy-server/conf doesn't exist
> {code}
> On livy node, observed the following:
> {code}
> root@ctr-e134-1499953498516-324773-01-07:/usr/hdp/current/livy-server# ls
> -la /usr/hdp/current/livy-server/
> total 40
> drwxr-xr-x 8 root root 4096 Nov 20 23:49 .
> drwxr-xr-x 42 root root 4096 Nov 21 00:05 ..
> drwxr-xr-x 2 root root 4096 Nov 20 23:43 bin
> lrwxrwxrwx 1 root root14 Apr 21 2017 conf -> /etc/livy/conf
> drwxr-xr-x 3 root root 4096 Nov 20 23:43 etc
> drwxr-xr-x 2 root root 12288 Nov 20 23:43 jars
> drwxr-xr-x 2 livy livy 4096 Nov 20 23:49 logs
> drwxr-xr-x 2 root root 4096 Nov 20 23:43 repl-jars
> drwxr-xr-x 2 root root 4096 Nov 20 23:43 rsc-jars
> ===
> root@ctr-e134-1499953498516-324773-01-07:~# ls -la /etc/livy/
> total 16
> drwxr-xr-x 4 root root 4096 Nov 21 04:32 .
> drwxr-xr-x 120 root root 4096 Nov 21 03:26 ..
> drwxr-xr-x 3 root root 4096 Nov 21 03:30 2.6.4.0-36
> lrwxrwxrwx 1 root root 21 Nov 21 04:32 conf -> /usr/hdp/current/livy
> drwxr-xr-x 2 root root 4096 Nov 20 23:49 conf.backup
> {code}
> Looks like there is no directory '/etc/livy/2.5.5.0-157/0'
> From downgrade wizard, found that 'Set Version on All Hosts' Upgrade group
> printed the following for livy:
> {code}
> 2017-11-21 04:32:08,022 - Link['/etc/livy/conf'] {'to':
> '/usr/hdp/current/livy'}
> 2017-11-21 04:32:08,022 - Link['/etc/livy/conf'] replacing old symlink to
> /grid/0/hdp/current/livy
> 2017-11-21 04:32:08,022 - Warning: linking to nonexistent location
> /usr/hdp/current/livy
> 2017-11-21
[jira] [Commented] (AMBARI-22644) Node Managers fail to start after Spark2 is patched due to CNF YarnShuffleService
[
https://issues.apache.org/jira/browse/AMBARI-22644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295709#comment-16295709
]
Hudson commented on AMBARI-22644:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8530 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/8530/])
AMBARI-22644 - Node Managers fail to start after Spark2 is patched due
(jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1d87b21cf34c51bc19f80199e2b8641474fe098a])
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.5/services/YARN/configuration/yarn-site.xml
* (edit)
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.6/upgrades/config-upgrade.xml
* (edit)
ambari-server/src/main/resources/common-services/YARN/3.0.0.3.0/package/scripts/params_linux.py
* (edit)
ambari-server/src/main/resources/stacks/HDP/3.0/services/YARN/configuration/yarn-site.xml
> Node Managers fail to start after Spark2 is patched due to CNF
> YarnShuffleService
> -
>
> Key: AMBARI-22644
> URL: https://issues.apache.org/jira/browse/AMBARI-22644
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Vivek Sharma
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.6.2
>
>
> *STR*
> # Deploy HDP-2.6.4.0 cluster with Ambari-2.6.1.0-114
> # Apply HBase patch Upgrade on the cluster (this step is optional)
> # Then apply Spark2 patch Upgrade on the cluster
> # Restart Node Managers
> *Result*
> NM restart fails with below error:
> {code}
> 2017-12-10 07:17:02,559 INFO impl.MetricsSystemImpl
> (MetricsSystemImpl.java:shutdown(606)) - NodeManager metrics system shutdown
> complete.
> 2017-12-10 07:17:02,559 FATAL nodemanager.NodeManager
> (NodeManager.java:initAndStartNodeManager(549)) - Error starting NodeManager
> org.apache.hadoop.service.ServiceStateException:
> java.lang.ClassNotFoundException:
> org.apache.spark.network.yarn.YarnShuffleService
> at
> org.apache.hadoop.service.ServiceStateException.convert(ServiceStateException.java:59)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:172)
> at
> org.apache.hadoop.service.CompositeService.serviceInit(CompositeService.java:107)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.ContainerManagerImpl.serviceInit(ContainerManagerImpl.java:245)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> at
> org.apache.hadoop.service.CompositeService.serviceInit(CompositeService.java:107)
> at
> org.apache.hadoop.yarn.server.nodemanager.NodeManager.serviceInit(NodeManager.java:291)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> at
> org.apache.hadoop.yarn.server.nodemanager.NodeManager.initAndStartNodeManager(NodeManager.java:546)
> at
> org.apache.hadoop.yarn.server.nodemanager.NodeManager.main(NodeManager.java:594)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.spark.network.yarn.YarnShuffleService
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.hadoop.util.ApplicationClassLoader.loadClass(ApplicationClassLoader.java:197)
> at
> org.apache.hadoop.util.ApplicationClassLoader.loadClass(ApplicationClassLoader.java:165)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.AuxiliaryServiceWithCustomClassLoader.getInstance(AuxiliaryServiceWithCustomClassLoader.java:169)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.AuxServices.serviceInit(AuxServices.java:131)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> ... 8 more
> 2017-12-10 07:17:02,562 INFO nodemanager.NodeManager
> (LogAdapter.java:info(45)) - SHUTDOWN_MSG:
> {code}
> The spark properties are correctly being written out as per AMBARI-22525.
> Initially, we had defined Spark properties for ATS like this:
> {code}
> yarn.nodemanager.aux-services.spark_shuffle.classpath
> {{stack_root}}/${hdp.version}/spark/aux/*
> {code}
> When YARN upgrades without Spark, we run into AMBARI-22525. Seems like the
> shuffle classes are installed as part of RPM dependencies, but not the
> SparkATSPlugin.
> So:
> - If we use YARN's version for the Spark classes, then ATS can't find
>
[jira] [Commented] (AMBARI-22640) HBase Cannot Find LZO Classes After Being Patched
[
https://issues.apache.org/jira/browse/AMBARI-22640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295708#comment-16295708
]
Hudson commented on AMBARI-22640:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8530 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/8530/])
AMBARI-22640 - HBase Cannot Find LZO Classes After Being Patched (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=eab6722f705f24a1d731fa39b5e220578e231478])
* (edit)
ambari-server/src/main/resources/common-services/HBASE/2.0.0.3.0/package/scripts/hbase.py
* (edit)
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
> HBase Cannot Find LZO Classes After Being Patched
> -
>
> Key: AMBARI-22640
> URL: https://issues.apache.org/jira/browse/AMBARI-22640
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.6.2
>
> Attachments: AMBARI-22640.patch
>
>
> After patching HBase where LZO compression is being used, the following is
> seen:
> {code}
> 2017-12-10 22:31:09,244|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|Exception in thread "main"
> java.lang.RuntimeException: java.lang.ClassNotFoundException:
> com.hadoop.compression.lzo.LzoCodec
> 2017-12-10 22:31:09,245|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm$1.buildCodec(Compression.java:130)
> 2017-12-10 22:31:09,245|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm$1.getCodec(Compression.java:116)
> 2017-12-10 22:31:09,245|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.compress.Compression$Algorithm.getCompressor(Compression.java:301)
> 2017-12-10 22:31:09,245|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.encoding.HFileBlockDefaultEncodingContext.(HFileBlockDefaultEncodingContext.java:90)
> 2017-12-10 22:31:09,245|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.hfile.HFileBlock$Writer.(HFileBlock.java:853)
> 2017-12-10 22:31:09,246|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV2.finishInit(HFileWriterV2.java:121)
> 2017-12-10 22:31:09,246|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV2.(HFileWriterV2.java:113)
> 2017-12-10 22:31:09,246|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV3.(HFileWriterV3.java:67)
> 2017-12-10 22:31:09,246|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.hfile.HFileWriterV3$WriterFactoryV3.createWriter(HFileWriterV3.java:59)
> 2017-12-10 22:31:09,246|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.io.hfile.HFile$WriterFactory.create(HFile.java:325)
> 2017-12-10 22:31:09,246|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.util.CompressionTest.doSmokeTest(CompressionTest.java:127)
> 2017-12-10 22:31:09,247|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> org.apache.hadoop.hbase.util.CompressionTest.main(CompressionTest.java:160)
> 2017-12-10 22:31:09,247|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|Caused by:
> java.lang.ClassNotFoundException: com.hadoop.compression.lzo.LzoCodec
> 2017-12-10 22:31:09,247|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> 2017-12-10 22:31:09,247|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> 2017-12-10 22:31:09,247|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> 2017-12-10 22:31:09,248|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 2017-12-10 22:31:09,248|INFO|MainThread|machine.py:164 -
> run()||GUID=37b565a7-e164-4641-b335-19884c614ffd|at
[jira] [Commented] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295712#comment-16295712
]
Hudson commented on AMBARI-22665:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8530 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/8530/])
AMBARI-22665 - Livy2 Does Not Start On HDP 2.6.0 to 2.6.3 (jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=5c95c4a7a9c75f0b0932b3accf4fb536a3175c0e])
* (edit)
ambari-server/src/main/resources/custom_actions/scripts/install_packages.py
* (edit)
ambari-common/src/main/python/resource_management/libraries/functions/conf_select.py
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMBARI-22655) Livy/Livy2 Unable To Start Due to Address Already In Use
[
https://issues.apache.org/jira/browse/AMBARI-22655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295710#comment-16295710
]
Hudson commented on AMBARI-22655:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8530 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/8530/])
AMBARI-22655 - Livy/Livy2 Unable To Start Due to Address Already In Use
(jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=fded8228015231afcae0900502db27ddc863773a])
* (edit)
ambari-server/src/main/resources/common-services/SPARK2/2.0.0/package/scripts/setup_livy2.py
* (edit) ambari-server/src/test/python/stacks/2.6/SPARK2/test_spark_livy2.py
* (edit)
ambari-server/src/main/resources/common-services/SPARK2/2.0.0/package/scripts/livy2_service.py
* (edit)
ambari-server/src/main/resources/stacks/HDP/3.0/properties/stack_packages.json
* (edit) ambari-server/src/test/python/stacks/2.5/SPARK/test_spark_livy.py
* (edit)
ambari-server/src/main/resources/common-services/SPARK/2.2.0/package/scripts/livy_service.py
* (edit)
ambari-server/src/main/resources/common-services/SPARK/1.2.1/package/scripts/livy_service.py
* (edit)
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_packages.json
> Livy/Livy2 Unable To Start Due to Address Already In Use
>
>
> Key: AMBARI-22655
> URL: https://issues.apache.org/jira/browse/AMBARI-22655
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.6.2
>
>
> While restarting Livy and Livy2 on a non-root cluster, the following is seen:
> {code}
> 17/12/14 14:36:23 WARN LivyConf: The configuration key
> livy.repl.enableHiveContext has been deprecated as of Livy 0.4 and may be
> removed in the future. Please use the new key livy.repl.enable-hive-context
> instead.
> 17/12/14 14:36:23 WARN LivyConf: The configuration key
> livy.server.csrf_protection.enabled has been deprecated as of Livy 0.4 and
> may be removed in the future. Please use the new key
> livy.server.csrf-protection.enabled instead.
> 17/12/14 14:36:23 INFO AccessManager: AccessControlManager acls
> disabled;users with view permission: ;users with modify permission: ;users
> with super permission: cstm-zeppelin;other allowed users: *
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Welcome to
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: __
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: / __/__ ___ _/
> /__
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: _\ \/ _ \/ _ `/ __/
> '_/
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout:/___/ .__/\_,_/_/
> /_/\_\ version 2.2.0.2.6.4.0-73
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: /_/
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout:
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Using Scala version
> 2.11.8, OpenJDK 64-Bit Server VM, 1.8.0_131
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Branch HEAD
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Compiled by user jenkins
> on 2017-12-13T19:08:32Z
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Revision
> a24017869f5450397136ee8b11be818e7cd3facb
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Url
> g...@github.com:hortonworks/spark2.git
> 17/12/14 14:36:28 INFO LineBufferedStream: stdout: Type --help for more
> information.
> 17/12/14 14:36:29 WARN NativeCodeLoader: Unable to load native-hadoop library
> for your platform... using builtin-java classes where applicable
> 17/12/14 14:36:31 INFO AHSProxy: Connecting to Application History server at
> nat-yc-r7-ovvs-ambari-autostart-4-re-2.openstacklocal/172.22.121.144:10200
> 17/12/14 14:36:32 WARN DomainSocketFactory: The short-circuit local reads
> feature cannot be used because libhadoop cannot be loaded.
> 17/12/14 14:36:33 INFO StateStore$: Using FileSystemStateStore for recovery.
> 17/12/14 14:36:33 INFO BatchSessionManager: Recovered 0 batch sessions. Next
> session id: 0
> 17/12/14 14:36:33 INFO InteractiveSessionManager: Recovered 0 interactive
> sessions. Next session id: 0
> 17/12/14 14:36:33 INFO InteractiveSessionManager: Heartbeat watchdog thread
> started.
> 17/12/14 14:36:33 INFO LivyServer: SPNEGO auth enabled (principal =
> HTTP/nat-yc-r7-ovvs-ambari-autostart-4-re-3.openstacklo...@example.com)
> 17/12/14 14:36:33 INFO LivyServer: CSRF protection is enabled.
> 17/12/14 14:36:34 INFO KerberosAuthenticationHandler: Login using keytab
> /etc/security/keytabs/spnego.service.keytab, for principal
> HTTP/nat-yc-r7-ovvs-ambari-autostart-4-re-3.openstacklo...@example.com
> 17/12/14 14:36:34 INFO KerberosAuthenticationHandler: Map server:
> nat-yc-r7-ovvs-ambari-autostart-4-re-3.openstacklocal
[jira] [Commented] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
[
https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295663#comment-16295663
]
Olivér Szabó commented on AMBARI-22647:
---
committed to trunk (addendum):
{code:java}
commit afe469c98564aa7face62fe185eeb50b9b322e5f
Author: Oliver Szabo
Date: Mon Dec 18 22:01:09 2017 +0100
AMBARI-22647. ADDENDUM -Rafactor: Package Log Search and Log Feeder into
jars + cleanup start scripts (oleewere)
{code}
> 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] [Commented] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295343#comment-16295343
]
Nate Cole commented on AMBARI-22665:
+1 on patch
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-22665:
-
Attachment: (was: AMBARI-22665.patch)
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-22665:
-
Attachment: AMBARI-22665.patch
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295310#comment-16295310
]
Hadoop QA commented on AMBARI-22665:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12902684/AMBARI-22665.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/12855//console
This message is automatically generated.
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-22665:
-
Status: Patch Available (was: Open)
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
[
https://issues.apache.org/jira/browse/AMBARI-22665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-22665:
-
Attachment: AMBARI-22665.patch
> Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
> --
>
> Key: AMBARI-22665
> URL: https://issues.apache.org/jira/browse/AMBARI-22665
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.6.2
>
> Attachments: AMBARI-22665.patch
>
>
> Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0.
> However, there was no stack-select or conf-select support for some reason.
> stack-select and conf-select was built into HDP 2.6.4.0.
> Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
> deployments of HDP 2.6.4+, this is correct and the server can properly start.
> However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
> following:
> {code}
> 2017-12-18 14:53:52,711 - Checking to see which directories will be created
> for livy2 on version 2.6.0.0-334
> 2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not
> exist
> 2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
> 'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
> '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
> 'stderr': -1}
> 2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
> package name', '')
> 2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
> '/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
> '--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput':
> False, 'sudo': True, 'quiet': False}
> 2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
> Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
> --package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1.
> livy2 not installed or incorrect package name
> 2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be
> converted into a symlink
> {code}
> Essentially, Ambari is trying to setup the configuration pointers, but it is
> ignoring the dry-run result code. At the end of the day, we end up with Livy2
> not starting b/c we're manipulated the configuration pointers, but
> {{conf-select}} failed to properly create a versioned configuration directory.
> The solution is to check the dry-run result code and do nothing if
> conf-select doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (AMBARI-22665) Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
Jonathan Hurley created AMBARI-22665:
Summary: Livy2 Does Not Start On HDP 2.6.0 to 2.6.3
Key: AMBARI-22665
URL: https://issues.apache.org/jira/browse/AMBARI-22665
Project: Ambari
Issue Type: Bug
Affects Versions: 2.6.1
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Blocker
Fix For: 2.6.2
Livy2 was added as a component in HDP 2.6, starting with HDP 2.6.0.0. However,
there was no stack-select or conf-select support for some reason. stack-select
and conf-select was built into HDP 2.6.4.0.
Ambari added {{livy2}} as a known conf-select to the HDP 2.6 stack. On
deployments of HDP 2.6.4+, this is correct and the server can properly start.
However, when using Ambari to deploy Livy2 on HDP 2.6.0 - 2.6.3, we see the
following:
{code}
2017-12-18 14:53:52,711 - Checking to see which directories will be created for
livy2 on version 2.6.0.0-334
2017-12-18 14:53:52,711 - call[('ambari-python-wrap', '/usr/bin/conf-select',
'dry-run-create', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
'--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
'stderr': -1}
2017-12-18 14:53:52,734 - call returned (1, 'livy2 not installed or incorrect
package name', '')
2017-12-18 14:53:52,735 - Creating /etc/livy2/2.6.0.0-334/0 if it does not exist
2017-12-18 14:53:52,736 - call[('ambari-python-wrap', '/usr/bin/conf-select',
'create-conf-dir', '--package', 'livy2', '--stack-version', '2.6.0.0-334',
'--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False,
'stderr': -1}
2017-12-18 14:53:52,765 - call returned (1, 'livy2 not installed or incorrect
package name', '')
2017-12-18 14:53:52,766 - checked_call[('ambari-python-wrap',
'/usr/bin/conf-select', 'set-conf-dir', '--package', 'livy2',
'--stack-version', '2.6.0.0-334', '--conf-version', '0')] {'logoutput': False,
'sudo': True, 'quiet': False}
2017-12-18 14:53:52,795 - Could not select the directory for package livy2.
Error: Execution of 'ambari-python-wrap /usr/bin/conf-select set-conf-dir
--package livy2 --stack-version 2.6.0.0-334 --conf-version 0' returned 1. livy2
not installed or incorrect package name
2017-12-18 14:53:52,796 - /etc/livy2/conf is a directory - it must be converted
into a symlink
{code}
Essentially, Ambari is trying to setup the configuration pointers, but it is
ignoring the dry-run result code. At the end of the day, we end up with Livy2
not starting b/c we're manipulated the configuration pointers, but
{{conf-select}} failed to properly create a versioned configuration directory.
The solution is to check the dry-run result code and do nothing if conf-select
doesn't support the package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
[ https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295182#comment-16295182 ] Hudson commented on AMBARI-22647: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8529 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8529/]) AMBARI-22647. Rafactor: Package Log Search and Log Feeder into jars + (oleewere: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=562795c4d35bf3b45d196856e9d66e5dfdd0a17b]) * (edit) ambari-logsearch/docker/bin/start.sh * (edit) ambari-logsearch/ambari-logsearch-logfeeder/run.sh * (edit) ambari-logsearch/ambari-logsearch-logfeeder/README.md * (edit) ambari-logsearch/ambari-logsearch-server/src/main/java/org/apache/ambari/logsearch/LogSearch.java * (edit) ambari-logsearch/ambari-logsearch-server/README.md * (edit) ambari-logsearch/docker/logsearch-logfeeder.yml * (edit) ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/logfeeder/postinst * (edit) ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/portal/preinst * (edit) ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/portal/postrm * (add) ambari-logsearch/ambari-logsearch-logfeeder/src/main/scripts/logfeeder-env.sh * (add) ambari-logsearch/ambari-logsearch-assembly/src/main/package/rpm/logfeeder/postremove.sh * (edit) ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/portal/postinst * (delete) ambari-logsearch/ambari-logsearch-assembly/src/main/package/deb/logfeeder/posttrm * (edit) ambari-server/src/test/python/stacks/2.0.6/hooks/after-INSTALL/test_after_install.py * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py * (add) ambari-logsearch/ambari-logsearch-assembly/src/main/package/rpm/portal/postinstall.sh * (add) ambari-logsearch/ambari-logsearch-assembly/src/main/package/rpm/logfeeder/preinstall.sh * (edit) ambari-logsearch/ambari-logsearch-server/run.sh * (edit) ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py * (edit) ambari-logsearch/ambari-logsearch-server/pom.xml * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-properties.xml * (delete) ambari-logsearch/ambari-logsearch-logfeeder/src/main/package/deb/control/prerm * (edit) ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py * (edit) ambari-logsearch/ambari-logsearch-server/build.xml * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py * (edit) ambari-logsearch/docker/test-config/logfeeder/logfeeder-env.sh * (edit) ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/LogFeeder.java * (edit) ambari-server/src/main/resources/stack-hooks/after-INSTALL/scripts/params.py * (add) ambari-logsearch/ambari-logsearch-logfeeder/src/main/scripts/logfeeder.sh * (edit) ambari-logsearch/docker/logsearch-server.yml * (delete) ambari-logsearch/ambari-logsearch-server/src/main/scripts/stop.sh * (delete) ambari-logsearch/ambari-logsearch-logfeeder/src/main/scripts/run.sh * (edit) ambari-logsearch/ambari-logsearch-logfeeder/build.xml * (delete) ambari-logsearch/ambari-logsearch-logfeeder/src/main/package/deb/control/postrm * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/properties/logfeeder-env.sh.j2 * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/properties/logsearch-env.sh.j2 * (add) ambari-logsearch/ambari-logsearch-server/src/main/scripts/logsearch-env.sh * (add) ambari-logsearch/ambari-logsearch-server/src/main/scripts/logsearch.sh * (delete) ambari-logsearch/ambari-logsearch-logfeeder/build.properties * (edit) ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/LogFeederCommandLine.java * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logsearch.py * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml * (edit) ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/common/ConfigHandler.java * (add) ambari-logsearch/ambari-logsearch-assembly/src/main/package/rpm/logfeeder/postinstall.sh * (edit) ambari-logsearch/docker/test-config/logfeeder/logfeeder.properties * (edit) ambari-logsearch/docker/Dockerfile * (edit) ambari-logsearch/docker/all.yml * (edit) ambari-logsearch/docker/test-config/logsearch/logsearch-env.sh * (delete) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logsearch_common.py * (edit) ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-env.xml * (edit) ambari-logsearch/docker/test-config/logsearch/logsearch.properties * (edit)
[jira] [Commented] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
[
https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295127#comment-16295127
]
Olivér Szabó commented on AMBARI-22647:
---
committed to trunk:
{code:java}
commit 562795c4d35bf3b45d196856e9d66e5dfdd0a17b
Author: Oliver Szabo
Date: Fri Dec 15 22:17:46 2017 +0100
AMBARI-22647. Rafactor: Package Log Search and Log Feeder into jars +
cleanup start scripts (oleewere)
{code}
> 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] [Resolved] (AMBARI-22647) Rafactor: Package Log Search and Log Feeder into jars + cleanup start scripts
[ https://issues.apache.org/jira/browse/AMBARI-22647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó resolved AMBARI-22647. --- Resolution: Fixed > 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] [Resolved] (AMBARI-22660) Fix unit tests failing due to ServiceGroup issues
[
https://issues.apache.org/jira/browse/AMBARI-22660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila resolved AMBARI-22660.
Resolution: Fixed
Committed to
[branch-feature-AMBARI-14714|http://git-wip-us.apache.org/repos/asf/ambari/commit/4e575a59ac].
> Fix unit tests failing due to ServiceGroup issues
> -
>
> Key: AMBARI-22660
> URL: https://issues.apache.org/jira/browse/AMBARI-22660
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
> Fix For: 3.0.0
>
> Attachments: AMBARI-22660.branch-feature-AMBARI-14714.001.patch,
> AMBARI-22660.branch-feature-AMBARI-14714.002.patch
>
>
> Fix unit tests broken by AMBARI-21594 and AMBARI-21824 (ie. ones failing due
> to {{ServiceGroup}}-related errors).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22660) Fix unit tests failing due to ServiceGroup issues
[
https://issues.apache.org/jira/browse/AMBARI-22660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-22660:
---
Attachment: AMBARI-22660.branch-feature-AMBARI-14714.002.patch
> Fix unit tests failing due to ServiceGroup issues
> -
>
> Key: AMBARI-22660
> URL: https://issues.apache.org/jira/browse/AMBARI-22660
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
> Fix For: 3.0.0
>
> Attachments: AMBARI-22660.branch-feature-AMBARI-14714.001.patch,
> AMBARI-22660.branch-feature-AMBARI-14714.002.patch
>
>
> Fix unit tests broken by AMBARI-21594 and AMBARI-21824 (ie. ones failing due
> to {{ServiceGroup}}-related errors).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22664) Fix unit test failures caused by old json format
[ https://issues.apache.org/jira/browse/AMBARI-22664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-22664: - Resolution: Fixed Status: Resolved (was: Patch Available) Committed to branch-3.0-perf > Fix unit test failures caused by old json format > > > Key: AMBARI-22664 > URL: https://issues.apache.org/jira/browse/AMBARI-22664 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-22664.patch > > > This fixes around 100 of failed unit tests due to old format of input json > files. > Before the fix: > > > Total run:1206 > Total errors:281 > Total failures:41 > > After the fix: > > > Total run:1210 > Total errors:195 > Total failures:44 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22664) Fix unit test failures caused by old json format
[
https://issues.apache.org/jira/browse/AMBARI-22664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294959#comment-16294959
]
Hadoop QA commented on AMBARI-22664:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12902642/AMBARI-22664.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/12854//console
This message is automatically generated.
> Fix unit test failures caused by old json format
>
>
> Key: AMBARI-22664
> URL: https://issues.apache.org/jira/browse/AMBARI-22664
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-22664.patch
>
>
> This fixes around 100 of failed unit tests due to old format of input json
> files.
> Before the fix:
>
>
> Total run:1206
> Total errors:281
> Total failures:41
>
> After the fix:
>
>
> Total run:1210
> Total errors:195
> Total failures:44
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22664) Fix unit test failures caused by old json format
[ https://issues.apache.org/jira/browse/AMBARI-22664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-22664: - Attachment: AMBARI-22664.patch > Fix unit test failures caused by old json format > > > Key: AMBARI-22664 > URL: https://issues.apache.org/jira/browse/AMBARI-22664 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-22664.patch > > > This fixes around 100 of failed unit tests due to old format of input json > files. > Before the fix: > > > Total run:1206 > Total errors:281 > Total failures:41 > > After the fix: > > > Total run:1210 > Total errors:195 > Total failures:44 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22664) Fix unit test failures caused by old json format
[ https://issues.apache.org/jira/browse/AMBARI-22664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-22664: - Status: Patch Available (was: Open) > Fix unit test failures caused by old json format > > > Key: AMBARI-22664 > URL: https://issues.apache.org/jira/browse/AMBARI-22664 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 3.0.0 > > Attachments: AMBARI-22664.patch > > > This fixes around 100 of failed unit tests due to old format of input json > files. > Before the fix: > > > Total run:1206 > Total errors:281 > Total failures:41 > > After the fix: > > > Total run:1210 > Total errors:195 > Total failures:44 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (AMBARI-22664) Fix unit test failures caused by old json format
Andrew Onischuk created AMBARI-22664: Summary: Fix unit test failures caused by old json format Key: AMBARI-22664 URL: https://issues.apache.org/jira/browse/AMBARI-22664 Project: Ambari Issue Type: Bug Reporter: Andrew Onischuk Assignee: Andrew Onischuk Fix For: 3.0.0 This fixes around 100 of failed unit tests due to old format of input json files. Before the fix: Total run:1206 Total errors:281 Total failures:41 After the fix: Total run:1210 Total errors:195 Total failures:44 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22663) Log Search UI: incorrect caption for graph gap in weeks
[ https://issues.apache.org/jira/browse/AMBARI-22663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294919#comment-16294919 ] Hudson commented on AMBARI-22663: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #8528 (See [https://builds.apache.org/job/Ambari-trunk-Commit/8528/]) AMBARI-22663 Log Search UI: incorrect caption for graph gap in weeks. (ababiichuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f9ad13d0a304414b7e37b6a61afac876912e74ce]) * (edit) ambari-logsearch/ambari-logsearch-web/src/assets/i18n/en.json > Log Search UI: incorrect caption for graph gap in weeks > --- > > Key: AMBARI-22663 > URL: https://issues.apache.org/jira/browse/AMBARI-22663 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-22663.patch > > > There's a text reflecting the gap between values of the graph. It's incorrect > when the unit is week (caption is not defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22634) Kerberos support for OneFS
[
https://issues.apache.org/jira/browse/AMBARI-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294894#comment-16294894
]
Hadoop QA commented on AMBARI-22634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12902605/AMBARI-22634.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/12853//console
This message is automatically generated.
> Kerberos support for OneFS
> --
>
> Key: AMBARI-22634
> URL: https://issues.apache.org/jira/browse/AMBARI-22634
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Attila Magyar
>Assignee: Attila Magyar
> Fix For: 3.0.0
>
> Attachments: AMBARI-22634.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22663) Log Search UI: incorrect caption for graph gap in weeks
[ https://issues.apache.org/jira/browse/AMBARI-22663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-22663: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk > Log Search UI: incorrect caption for graph gap in weeks > --- > > Key: AMBARI-22663 > URL: https://issues.apache.org/jira/browse/AMBARI-22663 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-22663.patch > > > There's a text reflecting the gap between values of the graph. It's incorrect > when the unit is week (caption is not defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22663) Log Search UI: incorrect caption for graph gap in weeks
[
https://issues.apache.org/jira/browse/AMBARI-22663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294880#comment-16294880
]
Hadoop QA commented on AMBARI-22663:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12902627/AMBARI-22663.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 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-logsearch/ambari-logsearch-web.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/12851//console
This message is automatically generated.
> Log Search UI: incorrect caption for graph gap in weeks
> ---
>
> Key: AMBARI-22663
> URL: https://issues.apache.org/jira/browse/AMBARI-22663
> Project: Ambari
> Issue Type: Bug
> Components: ambari-logsearch
>Affects Versions: 3.0.0
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 3.0.0
>
> Attachments: AMBARI-22663.patch
>
>
> There's a text reflecting the gap between values of the graph. It's incorrect
> when the unit is week (caption is not defined).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMBARI-22663) Log Search UI: incorrect caption for graph gap in weeks
[ https://issues.apache.org/jira/browse/AMBARI-22663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-22663: -- Status: Patch Available (was: Open) > Log Search UI: incorrect caption for graph gap in weeks > --- > > Key: AMBARI-22663 > URL: https://issues.apache.org/jira/browse/AMBARI-22663 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-22663.patch > > > There's a text reflecting the gap between values of the graph. It's incorrect > when the unit is week (caption is not defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22663) Log Search UI: incorrect caption for graph gap in weeks
[ https://issues.apache.org/jira/browse/AMBARI-22663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-22663: -- Attachment: AMBARI-22663.patch > Log Search UI: incorrect caption for graph gap in weeks > --- > > Key: AMBARI-22663 > URL: https://issues.apache.org/jira/browse/AMBARI-22663 > Project: Ambari > Issue Type: Bug > Components: ambari-logsearch >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-22663.patch > > > There's a text reflecting the gap between values of the graph. It's incorrect > when the unit is week (caption is not defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22637) Fix misuses of os.path.dirname(path) in yarn.py
[ https://issues.apache.org/jira/browse/AMBARI-22637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294839#comment-16294839 ] Andrew Onischuk commented on AMBARI-22637: -- Nice find. +1 > Fix misuses of os.path.dirname(path) in yarn.py > --- > > Key: AMBARI-22637 > URL: https://issues.apache.org/jira/browse/AMBARI-22637 > Project: Ambari > Issue Type: Sub-task > Components: ambari-server >Reporter: Akira Ajisaka >Assignee: Akira Ajisaka > Attachments: AMBARI-22637.001.patch > > > As I written in AMBARI-22632, yarn.py wrongly sets 755 permission to > '/ats/done' and '/ats/active' by default. This is because the default value > of yarn.timeline-service.entity-group-fs-store.done-dir is '/ats/done/' and > the default value of yarn.timeline-service.entity-group-fs-store.active-dir > is '/ats/active/', and both of the default value have trailing '/'. > Next yarn.py sets 700 permission to the directories, so finally the > permissions become correct. > This issue causes redundant WebHDFS calls every time when launching ATS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (AMBARI-22663) Log Search UI: incorrect caption for graph gap in weeks
Andrii Babiichuk created AMBARI-22663: - Summary: Log Search UI: incorrect caption for graph gap in weeks Key: AMBARI-22663 URL: https://issues.apache.org/jira/browse/AMBARI-22663 Project: Ambari Issue Type: Bug Components: ambari-logsearch Affects Versions: 3.0.0 Reporter: Andrii Babiichuk Assignee: Andrii Babiichuk Fix For: 3.0.0 There's a text reflecting the gap between values of the graph. It's incorrect when the unit is week (caption is not defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AMBARI-22637) Fix misuses of os.path.dirname(path) in yarn.py
[ https://issues.apache.org/jira/browse/AMBARI-22637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16294769#comment-16294769 ] Akira Ajisaka commented on AMBARI-22637: Hi [~aonishuk] and [~dsen], would you review this issue? > Fix misuses of os.path.dirname(path) in yarn.py > --- > > Key: AMBARI-22637 > URL: https://issues.apache.org/jira/browse/AMBARI-22637 > Project: Ambari > Issue Type: Sub-task > Components: ambari-server >Reporter: Akira Ajisaka >Assignee: Akira Ajisaka > Attachments: AMBARI-22637.001.patch > > > As I written in AMBARI-22632, yarn.py wrongly sets 755 permission to > '/ats/done' and '/ats/active' by default. This is because the default value > of yarn.timeline-service.entity-group-fs-store.done-dir is '/ats/done/' and > the default value of yarn.timeline-service.entity-group-fs-store.active-dir > is '/ats/active/', and both of the default value have trailing '/'. > Next yarn.py sets 700 permission to the directories, so finally the > permissions become correct. > This issue causes redundant WebHDFS calls every time when launching ATS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22485) Allow Ambari to support non-kerberos SASL mechanisms for Kafka
[ https://issues.apache.org/jira/browse/AMBARI-22485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doroszlai, Attila updated AMBARI-22485: --- Fix Version/s: 2.6.1 > Allow Ambari to support non-kerberos SASL mechanisms for Kafka > -- > > Key: AMBARI-22485 > URL: https://issues.apache.org/jira/browse/AMBARI-22485 > Project: Ambari > Issue Type: Bug > Components: stacks >Affects Versions: 2.6.0 >Reporter: Yolanda M. Davis >Assignee: Yolanda M. Davis > Fix For: 2.6.1 > > Attachments: AMBARI-22485.patch, AMBARI-22485_branch-2.6.patch > > > Currently AMBARI support's SASL and SSL as the security options for Kafka. > Within SASL Ambari only supports GSSAPI(kerberos) only. Kafka supports other > mechanisms such as plain, md5 etc.. This allows users to plug in their LDAP > system into Kafka. > Also another important option is SASL_SSL. > We need to expose necessary configs in Ambari to enable these mechanisms for > users. > Ambari should allow users to not only configure Kafka for non-kerberos based > SASL mechanisms, but also ensure that jaas configuration files are written > when these options are provided (as opposed to only writing those files when > kerberos has been enabled).. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (AMBARI-22662) Escape special characters in URLs for a.o. Group Management
Rene created AMBARI-22662: - Summary: Escape special characters in URLs for a.o. Group Management Key: AMBARI-22662 URL: https://issues.apache.org/jira/browse/AMBARI-22662 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.5.0 Reporter: Rene Priority: Trivial In Ambari User + Group Management when I click on a link to a group beginning with a '#' character, the URL doesn't load. This is due to the character not being being escaped in the URL. Hence the '#' character and possibly others should be correctly encoded. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22634) Kerberos support for OneFS
[ https://issues.apache.org/jira/browse/AMBARI-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-22634: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Kerberos support for OneFS > -- > > Key: AMBARI-22634 > URL: https://issues.apache.org/jira/browse/AMBARI-22634 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-22634.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (AMBARI-22634) Kerberos support for OneFS
[ https://issues.apache.org/jira/browse/AMBARI-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar reopened AMBARI-22634: > Kerberos support for OneFS > -- > > Key: AMBARI-22634 > URL: https://issues.apache.org/jira/browse/AMBARI-22634 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-22634.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22634) Kerberos support for OneFS
[ https://issues.apache.org/jira/browse/AMBARI-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-22634: --- Status: Patch Available (was: Reopened) > Kerberos support for OneFS > -- > > Key: AMBARI-22634 > URL: https://issues.apache.org/jira/browse/AMBARI-22634 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-22634.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22634) Kerberos support for OneFS
[ https://issues.apache.org/jira/browse/AMBARI-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-22634: --- Attachment: AMBARI-22634.patch > Kerberos support for OneFS > -- > > Key: AMBARI-22634 > URL: https://issues.apache.org/jira/browse/AMBARI-22634 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-22634.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMBARI-22634) Kerberos support for OneFS
[ https://issues.apache.org/jira/browse/AMBARI-22634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Magyar updated AMBARI-22634: --- Status: Patch Available (was: Open) > Kerberos support for OneFS > -- > > Key: AMBARI-22634 > URL: https://issues.apache.org/jira/browse/AMBARI-22634 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Attila Magyar >Assignee: Attila Magyar > Fix For: 3.0.0 > > Attachments: AMBARI-22634.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
