[jira] [Commented] (AMBARI-12977) ambari-metrics fails to package from .deb on ubuntu 14.04
[ https://issues.apache.org/jira/browse/AMBARI-12977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537960#comment-15537960 ] Ramu.R commented on AMBARI-12977: - Same problem exists in 2.4.1 in apache-metrics-grafana. Adding similar patch resoles the same > ambari-metrics fails to package from .deb on ubuntu 14.04 > - > > Key: AMBARI-12977 > URL: https://issues.apache.org/jira/browse/AMBARI-12977 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Reporter: Canan Girgin >Priority: Minor > Fix For: 2.3.0 > > Attachments: AMBARI-12977.patch > > > running "mvn -B clean install package jdeb:jdeb -DskipTests > -Dpython.ver="python >= 2.6" -Preplaceurl" command on ambari directory, shows > failure caused by problems during dep packaging. > if want to package only ambari-metrics and run command on ambari-metrics > directory everything is ok. > [INFO] Ambari Main ... SUCCESS [7.888s] > [INFO] Apache Ambari Project POM . SUCCESS [0.069s] > [INFO] Ambari Web SUCCESS [15.178s] > [INFO] Ambari Views .. SUCCESS [2.366s] > [INFO] Ambari Admin View . SUCCESS [24.536s] > [INFO] ambari-metrics SUCCESS [1.602s] > [INFO] Ambari Metrics Common . SUCCESS [1.215s] > [INFO] Ambari Metrics Hadoop Sink FAILURE [3.265s] > [INFO] Ambari Metrics Flume Sink . SKIPPED > [INFO] Ambari Metrics Kafka Sink . SKIPPED > [INFO] Ambari Metrics Storm Sink . SKIPPED > [INFO] Ambari Metrics Collector .. SKIPPED > [INFO] Ambari Metrics Monitor SKIPPED > [INFO] Ambari Metrics Assembly ... SKIPPED > [INFO] Ambari Server . SKIPPED > [INFO] Ambari Agent .. SKIPPED > [INFO] Ambari Client . SKIPPED > [INFO] Ambari Python Client .. SKIPPED > [INFO] Ambari Groovy Client .. SKIPPED > [INFO] Ambari Shell .. SKIPPED > [INFO] Ambari Python Shell ... SKIPPED > [INFO] Ambari Groovy Shell ... SKIPPED > [ERROR] Failed to create debian package > /home/a/repo/ambariRoot/ambari-metrics/ambari-metrics-hadoop-sink/target/ambari-metrics-hadoop-sink_2.1.0~SNAPSHOT_all.deb > org.vafer.jdeb.PackagingException: > "/home/a/repo/ambariRoot/ambari-metrics/ambari-metrics-hadoop-sink/src/main/package/deb/control" > is not a valid 'control' directory) > at org.vafer.jdeb.maven.DebMaker.makeDeb(DebMaker.java:186) > * > [ERROR] Failed to create debian package > /home/a/repo/ambari/ambari-metrics/ambari-metrics-flume-sink/target/ambari-metrics-flume-sink_2.1.0~SNAPSHOT_all.deb > org.vafer.jdeb.PackagingException: > "/home/a/repo/ambari/ambari-metrics/ambari-metrics-flume-sink/src/main/package/deb/control" > is not a valid 'control' directory) > at org.vafer.jdeb.maven.DebMaker.makeDeb(DebMaker.java:186) > * > [ERROR] Failed to create debian package > /home/a/repo/ambari/ambari-metrics/ambari-metrics-flume-sink/target/ambari-metrics-flume-sink_2.1.0~SNAPSHOT_all.deb > org.vafer.jdeb.PackagingException: > "/home/a/repo/ambari/ambari-metrics/ambari-metrics-flume-sink/src/main/package/deb/control" > is not a valid 'control' directory) > at org.vafer.jdeb.maven.DebMaker.makeDeb(DebMaker.java:186) > * > [ERROR] Failed to create debian package > /home/a/repo/ambari/ambari-metrics/ambari-metrics-kafka-sink/target/ambari-metrics-kafka-sink_2.1.0~SNAPSHOT_all.deb > org.vafer.jdeb.PackagingException: > "/home/a/repo/ambari/ambari-metrics/ambari-metrics-kafka-sink/src/main/package/deb/control" > is not a valid 'control' directory) > at org.vafer.jdeb.maven.DebMaker.makeDeb(DebMaker.java:186) > * > [ERROR] Failed to create debian package > /home/a/repo/ambari/ambari-metrics/ambari-metrics-timelineservice/target/ambari-metrics-timelineservice_2.1.0~SNAPSHOT_all.deb > org.vafer.jdeb.PackagingException: > "/home/a/repo/ambari/ambari-metrics/ambari-metrics-timelineservice/src/main/package/deb/control" > is not a valid 'control' directory) > at org.vafer.jdeb.maven.DebMaker.makeDeb(DebMaker.java:186) > * > [ERROR] Failed to create debian package > /home/a/repo/ambari/ambari-metrics/ambari-metrics-host-monitoring/target/ambari-metrics-host-monitoring_2.1.0~SNAPSHOT_all.deb > org.vafer.jdeb.PackagingException: > "/home/a/repo/ambari/ambari-metrics/ambar
[jira] [Updated] (AMBARI-17311) Modify HTTP headers to follow best security practices
[ https://issues.apache.org/jira/browse/AMBARI-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-17311: Status: Patch Available (was: Open) > Modify HTTP headers to follow best security practices > - > > Key: AMBARI-17311 > URL: https://issues.apache.org/jira/browse/AMBARI-17311 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: trunk > > Attachments: AMBARI-17311.patch > > > Add the following HTTP headers to follow security best practices. > X-Content-Type-Options: nosniff > Cache-control: no-store > Pragma: no-cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17311) Modify HTTP headers to follow best security practices
[ https://issues.apache.org/jira/browse/AMBARI-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-17311: Status: Open (was: Patch Available) > Modify HTTP headers to follow best security practices > - > > Key: AMBARI-17311 > URL: https://issues.apache.org/jira/browse/AMBARI-17311 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: trunk > > Attachments: AMBARI-17311.patch > > > Add the following HTTP headers to follow security best practices. > X-Content-Type-Options: nosniff > Cache-control: no-store > Pragma: no-cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18509) Zipfile size would require ZIP64 extensions
[ https://issues.apache.org/jira/browse/AMBARI-18509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537843#comment-15537843 ] Frank Legler commented on AMBARI-18509: --- Workaround is similar as in https://issues.apache.org/jira/browse/AMBARI-17593 Add 'allowZip64 = True' to /usr/lib/python2.6/site-packages/ambari_server/resourceFilesKeeper.py in this line (zf = zipfile.ZipFile(zip_file_path, "w", allowZip64 = True)) > Zipfile size would require ZIP64 extensions > --- > > Key: AMBARI-18509 > URL: https://issues.apache.org/jira/browse/AMBARI-18509 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Frank Legler > > $ ambari-server --version > 2.2.1.0 > $ ambari-server start > Using python /usr/bin/python2 > Starting ambari-server > Ambari Server running with administrator privileges. > Organizing resource files at /var/lib/ambari-server/resources... > ERROR: Exiting with exit code -1. > REASON: Can not organize resource files at /var/lib/ambari-server/resources: > Can not create zip archive of directory > /var/lib/ambari-server/resources/stacks/HDP/2.4/services//package > : Zipfile size would require ZIP64 extensions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17311) Modify HTTP headers to follow best security practices
[ https://issues.apache.org/jira/browse/AMBARI-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-17311: Attachment: (was: AMBARI-17311.patch) > Modify HTTP headers to follow best security practices > - > > Key: AMBARI-17311 > URL: https://issues.apache.org/jira/browse/AMBARI-17311 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: trunk > > Attachments: AMBARI-17311.patch > > > Add the following HTTP headers to follow security best practices. > X-Content-Type-Options: nosniff > Cache-control: no-store > Pragma: no-cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18487) Test and refine Collector writes w.r.t sharing and timeouts
[ https://issues.apache.org/jira/browse/AMBARI-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-18487: --- Status: Patch Available (was: Open) > Test and refine Collector writes w.r.t sharing and timeouts > --- > > Key: AMBARI-18487 > URL: https://issues.apache.org/jira/browse/AMBARI-18487 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18487-2.patch > > > Change metric monitor sharding strategy to hostname based. > Fix issues in AbstractTimelineMetricSink > Change Sink Zk retry policy to BoundedExponentialBackoffRetry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18487) Test and refine Collector writes w.r.t sharing and timeouts
[ https://issues.apache.org/jira/browse/AMBARI-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-18487: --- Attachment: AMBARI-18487-2.patch > Test and refine Collector writes w.r.t sharing and timeouts > --- > > Key: AMBARI-18487 > URL: https://issues.apache.org/jira/browse/AMBARI-18487 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18487-2.patch > > > Change metric monitor sharding strategy to hostname based. > Fix issues in AbstractTimelineMetricSink > Change Sink Zk retry policy to BoundedExponentialBackoffRetry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18487) Test and refine Collector writes w.r.t sharing and timeouts
[ https://issues.apache.org/jira/browse/AMBARI-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-18487: --- Status: Open (was: Patch Available) > Test and refine Collector writes w.r.t sharing and timeouts > --- > > Key: AMBARI-18487 > URL: https://issues.apache.org/jira/browse/AMBARI-18487 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 3.0.0 > > > Change metric monitor sharding strategy to hostname based. > Fix issues in AbstractTimelineMetricSink > Change Sink Zk retry policy to BoundedExponentialBackoffRetry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18487) Test and refine Collector writes w.r.t sharing and timeouts
[ https://issues.apache.org/jira/browse/AMBARI-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravindan Vijayan updated AMBARI-18487: --- Attachment: (was: AMBARI-18487.patch) > Test and refine Collector writes w.r.t sharing and timeouts > --- > > Key: AMBARI-18487 > URL: https://issues.apache.org/jira/browse/AMBARI-18487 > Project: Ambari > Issue Type: Task > Components: ambari-metrics >Affects Versions: 3.0.0 >Reporter: Aravindan Vijayan >Assignee: Aravindan Vijayan >Priority: Critical > Fix For: 3.0.0 > > > Change metric monitor sharding strategy to hostname based. > Fix issues in AbstractTimelineMetricSink > Change Sink Zk retry policy to BoundedExponentialBackoffRetry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-18509) Zipfile size would require ZIP64 extensions
[ https://issues.apache.org/jira/browse/AMBARI-18509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537357#comment-15537357 ] Frank Legler edited comment on AMBARI-18509 at 9/30/16 11:15 PM: - Issue is similar to https://issues.apache.org/jira/browse/AMBARI-17593 Size of the directory is 2.1 GB before starting Ambari. was (Author: grillian): Issue is similar to https://issues.apache.org/jira/browse/AMBARI-17593 > Zipfile size would require ZIP64 extensions > --- > > Key: AMBARI-18509 > URL: https://issues.apache.org/jira/browse/AMBARI-18509 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Frank Legler > > $ ambari-server --version > 2.2.1.0 > $ ambari-server start > Using python /usr/bin/python2 > Starting ambari-server > Ambari Server running with administrator privileges. > Organizing resource files at /var/lib/ambari-server/resources... > ERROR: Exiting with exit code -1. > REASON: Can not organize resource files at /var/lib/ambari-server/resources: > Can not create zip archive of directory > /var/lib/ambari-server/resources/stacks/HDP/2.4/services//package > : Zipfile size would require ZIP64 extensions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14439) Categorize unit tests so can run mvn test -P $PROFILE
[ https://issues.apache.org/jira/browse/AMBARI-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-14439: - Description: Categorize the unit tests so we that "mvn test -P $PROFILE" command can run only the desired category in order to run the tests faster. was: Categorize the unit tests with wither SlowTest, FastTest, and some other group based on the area. This will allow us to run a test suite that matches a given group. > Categorize unit tests so can run mvn test -P $PROFILE > - > > Key: AMBARI-14439 > URL: https://issues.apache.org/jira/browse/AMBARI-14439 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.3.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez > Fix For: trunk, 2.5.0 > > Attachments: AMBARI-14439.branch-2.5.patch, AMBARI-14439.trunk.patch > > > Categorize the unit tests so we that "mvn test -P $PROFILE" command can run > only the desired category in order to run the tests faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18509) Zipfile size would require ZIP64 extensions
[ https://issues.apache.org/jira/browse/AMBARI-18509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537357#comment-15537357 ] Frank Legler commented on AMBARI-18509: --- Issue is similar to https://issues.apache.org/jira/browse/AMBARI-17593 > Zipfile size would require ZIP64 extensions > --- > > Key: AMBARI-18509 > URL: https://issues.apache.org/jira/browse/AMBARI-18509 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Frank Legler > > $ ambari-server --version > 2.2.1.0 > $ ambari-server start > Using python /usr/bin/python2 > Starting ambari-server > Ambari Server running with administrator privileges. > Organizing resource files at /var/lib/ambari-server/resources... > ERROR: Exiting with exit code -1. > REASON: Can not organize resource files at /var/lib/ambari-server/resources: > Can not create zip archive of directory > /var/lib/ambari-server/resources/stacks/HDP/2.4/services//package > : Zipfile size would require ZIP64 extensions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18509) Zipfile size would require ZIP64 extensions
[ https://issues.apache.org/jira/browse/AMBARI-18509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Legler updated AMBARI-18509: -- Description: $ ambari-server --version 2.2.1.0 $ ambari-server start Using python /usr/bin/python2 Starting ambari-server Ambari Server running with administrator privileges. Organizing resource files at /var/lib/ambari-server/resources... ERROR: Exiting with exit code -1. REASON: Can not organize resource files at /var/lib/ambari-server/resources: Can not create zip archive of directory /var/lib/ambari-server/resources/stacks/HDP/2.4/services//package : Zipfile size would require ZIP64 extensions was: $ ambari-server --version 2.2.1.0 $ ambari-server start Using python /usr/bin/python2 Starting ambari-server Ambari Server running with administrator privileges. Organizing resource files at /var/lib/ambari-server/resources... ERROR: Exiting with exit code -1. REASON: Can not organize resource files at /var/lib/ambari-server/resources: Can not create zip archive of directory /var/lib/ambari-server/resources/stacks/HDP/2.4/services/vora-manager/package : Zipfile size would require ZIP64 extensions > Zipfile size would require ZIP64 extensions > --- > > Key: AMBARI-18509 > URL: https://issues.apache.org/jira/browse/AMBARI-18509 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Frank Legler > > $ ambari-server --version > 2.2.1.0 > $ ambari-server start > Using python /usr/bin/python2 > Starting ambari-server > Ambari Server running with administrator privileges. > Organizing resource files at /var/lib/ambari-server/resources... > ERROR: Exiting with exit code -1. > REASON: Can not organize resource files at /var/lib/ambari-server/resources: > Can not create zip archive of directory > /var/lib/ambari-server/resources/stacks/HDP/2.4/services//package > : Zipfile size would require ZIP64 extensions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18509) Zipfile size would require ZIP64 extensions
[ https://issues.apache.org/jira/browse/AMBARI-18509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Legler updated AMBARI-18509: -- Description: $ ambari-server --version 2.2.1.0 $ ambari-server start Using python /usr/bin/python2 Starting ambari-server Ambari Server running with administrator privileges. Organizing resource files at /var/lib/ambari-server/resources... ERROR: Exiting with exit code -1. REASON: Can not organize resource files at /var/lib/ambari-server/resources: Can not create zip archive of directory /var/lib/ambari-server/resources/stacks/HDP/2.4/services/vora-manager/package : Zipfile size would require ZIP64 extensions was: # ambari-server --version 2.2.1.0 # ambari-server start Using python /usr/bin/python2 Starting ambari-server Ambari Server running with administrator privileges. Organizing resource files at /var/lib/ambari-server/resources... ERROR: Exiting with exit code -1. REASON: Can not organize resource files at /var/lib/ambari-server/resources: Can not create zip archive of directory /var/lib/ambari-server/resources/stacks/HDP/2.4/services/vora-manager/package : Zipfile size would require ZIP64 extensions > Zipfile size would require ZIP64 extensions > --- > > Key: AMBARI-18509 > URL: https://issues.apache.org/jira/browse/AMBARI-18509 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Frank Legler > > $ ambari-server --version > 2.2.1.0 > $ ambari-server start > Using python /usr/bin/python2 > Starting ambari-server > Ambari Server running with administrator privileges. > Organizing resource files at /var/lib/ambari-server/resources... > ERROR: Exiting with exit code -1. > REASON: Can not organize resource files at /var/lib/ambari-server/resources: > Can not create zip archive of directory > /var/lib/ambari-server/resources/stacks/HDP/2.4/services/vora-manager/package > : Zipfile size would require ZIP64 extensions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18509) Zipfile size would require ZIP64 extensions
Frank Legler created AMBARI-18509: - Summary: Zipfile size would require ZIP64 extensions Key: AMBARI-18509 URL: https://issues.apache.org/jira/browse/AMBARI-18509 Project: Ambari Issue Type: Bug Affects Versions: 2.2.1 Reporter: Frank Legler # ambari-server --version 2.2.1.0 # ambari-server start Using python /usr/bin/python2 Starting ambari-server Ambari Server running with administrator privileges. Organizing resource files at /var/lib/ambari-server/resources... ERROR: Exiting with exit code -1. REASON: Can not organize resource files at /var/lib/ambari-server/resources: Can not create zip archive of directory /var/lib/ambari-server/resources/stacks/HDP/2.4/services/vora-manager/package : Zipfile size would require ZIP64 extensions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18476) Ambari UI changes to support PAM authentication
[ https://issues.apache.org/jira/browse/AMBARI-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-18476: Description: AMBARI-12263 adds support for PAM as authentication mechanism for accessing Ambari UI/REST. Since a new column group_type has been added for groups, the UI will display labels for group type and enable/disable group delete/add member functionality based on the group_type instead of the ldap_group flag. The user_type will be used to determine if the user can be deleted or if the user's password can be changed. > Ambari UI changes to support PAM authentication > --- > > Key: AMBARI-18476 > URL: https://issues.apache.org/jira/browse/AMBARI-18476 > Project: Ambari > Issue Type: Task > Components: ambari-web >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Attachments: AMBARI-18476.patch > > > AMBARI-12263 adds support for PAM as authentication mechanism for accessing > Ambari UI/REST. > Since a new column group_type has been added for groups, the UI will display > labels for group type and enable/disable group delete/add member > functionality based on the group_type instead of the ldap_group flag. > The user_type will be used to determine if the user can be deleted or if the > user's password can be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14439) Categorize unit tests so can run mvn test -P $PROFILE
[ https://issues.apache.org/jira/browse/AMBARI-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-14439: - Attachment: AMBARI-14439.trunk.patch AMBARI-14439.branch-2.5.patch > Categorize unit tests so can run mvn test -P $PROFILE > - > > Key: AMBARI-14439 > URL: https://issues.apache.org/jira/browse/AMBARI-14439 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.3.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez > Fix For: trunk, 2.5.0 > > Attachments: AMBARI-14439.branch-2.5.patch, AMBARI-14439.trunk.patch > > > Categorize the unit tests with wither SlowTest, FastTest, and some other > group based on the area. > This will allow us to run a test suite that matches a given group. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14439) Categorize unit tests so can run mvn test -P $PROFILE
[ https://issues.apache.org/jira/browse/AMBARI-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-14439: - Status: Open (was: Patch Available) > Categorize unit tests so can run mvn test -P $PROFILE > - > > Key: AMBARI-14439 > URL: https://issues.apache.org/jira/browse/AMBARI-14439 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.3.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez > Fix For: trunk, 2.5.0 > > > Categorize the unit tests with wither SlowTest, FastTest, and some other > group based on the area. > This will allow us to run a test suite that matches a given group. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14439) Categorize unit tests so can run mvn test -P $PROFILE
[ https://issues.apache.org/jira/browse/AMBARI-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-14439: - Fix Version/s: (was: 2.3.0) 2.5.0 trunk > Categorize unit tests so can run mvn test -P $PROFILE > - > > Key: AMBARI-14439 > URL: https://issues.apache.org/jira/browse/AMBARI-14439 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.3.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez > Fix For: trunk, 2.5.0 > > > Categorize the unit tests with wither SlowTest, FastTest, and some other > group based on the area. > This will allow us to run a test suite that matches a given group. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14439) Categorize unit tests so can run mvn test -P $PROFILE
[ https://issues.apache.org/jira/browse/AMBARI-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-14439: - Attachment: (was: AMBARI-14439.trunk.patch) > Categorize unit tests so can run mvn test -P $PROFILE > - > > Key: AMBARI-14439 > URL: https://issues.apache.org/jira/browse/AMBARI-14439 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.3.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez > Fix For: 2.3.0 > > > Categorize the unit tests with wither SlowTest, FastTest, and some other > group based on the area. > This will allow us to run a test suite that matches a given group. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14439) Categorize unit tests so can run mvn test -P $PROFILE
[ https://issues.apache.org/jira/browse/AMBARI-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Fernandez updated AMBARI-14439: - Summary: Categorize unit tests so can run mvn test -P $PROFILE (was: Categorize Ambari unit tests with Slow/Fast to run only desired group) > Categorize unit tests so can run mvn test -P $PROFILE > - > > Key: AMBARI-14439 > URL: https://issues.apache.org/jira/browse/AMBARI-14439 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.3.0 >Reporter: Alejandro Fernandez >Assignee: Alejandro Fernandez > Fix For: 2.3.0 > > Attachments: AMBARI-14439.trunk.patch > > > Categorize the unit tests with wither SlowTest, FastTest, and some other > group based on the area. > This will allow us to run a test suite that matches a given group. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18355) Introduce conditional dependencies in stack defition to handle blueprint validation gracefully
[ https://issues.apache.org/jira/browse/AMBARI-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-18355: --- Attachment: AMBARI-18355_v5.patch > Introduce conditional dependencies in stack defition to handle blueprint > validation gracefully > -- > > Key: AMBARI-18355 > URL: https://issues.apache.org/jira/browse/AMBARI-18355 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Amruta Borkar >Assignee: Amruta Borkar > Fix For: trunk > > Attachments: AMBARI-18355.patch, AMBARI-18355_v1.patch, > AMBARI-18355_v2.patch, AMBARI-18355_v3.patch, AMBARI-18355_v4.patch, > AMBARI-18355_v5.patch, Adding Conditional Dependencies.pdf > > > Currently stack definitions do not list conditional dependencies, adding > those to the stack definitions would make it easy to validate errors in case > of blueprint deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18355) Introduce conditional dependencies in stack defition to handle blueprint validation gracefully
[ https://issues.apache.org/jira/browse/AMBARI-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-18355: --- Status: Patch Available (was: In Progress) > Introduce conditional dependencies in stack defition to handle blueprint > validation gracefully > -- > > Key: AMBARI-18355 > URL: https://issues.apache.org/jira/browse/AMBARI-18355 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Amruta Borkar >Assignee: Amruta Borkar > Fix For: trunk > > Attachments: AMBARI-18355.patch, AMBARI-18355_v1.patch, > AMBARI-18355_v2.patch, AMBARI-18355_v3.patch, AMBARI-18355_v4.patch, > AMBARI-18355_v5.patch, Adding Conditional Dependencies.pdf > > > Currently stack definitions do not list conditional dependencies, adding > those to the stack definitions would make it easy to validate errors in case > of blueprint deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18355) Introduce conditional dependencies in stack defition to handle blueprint validation gracefully
[ https://issues.apache.org/jira/browse/AMBARI-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-18355: --- Status: Open (was: Patch Available) > Introduce conditional dependencies in stack defition to handle blueprint > validation gracefully > -- > > Key: AMBARI-18355 > URL: https://issues.apache.org/jira/browse/AMBARI-18355 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Amruta Borkar >Assignee: Amruta Borkar > Fix For: trunk > > Attachments: AMBARI-18355.patch, AMBARI-18355_v1.patch, > AMBARI-18355_v2.patch, AMBARI-18355_v3.patch, AMBARI-18355_v4.patch, > AMBARI-18355_v5.patch, Adding Conditional Dependencies.pdf > > > Currently stack definitions do not list conditional dependencies, adding > those to the stack definitions would make it easy to validate errors in case > of blueprint deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18508) Increasing headroom on heap size is from 1G to 6G for LLAP.
[
https://issues.apache.org/jira/browse/AMBARI-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapan Shridhar updated AMBARI-18508:
-
Fix Version/s: 2.5.0
> Increasing headroom on heap size is from 1G to 6G for LLAP.
> ---
>
> Key: AMBARI-18508
> URL: https://issues.apache.org/jira/browse/AMBARI-18508
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.1
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18508.patch
>
>
> *Issue:* LLAP daemons can be killed by the YARN Memory Monitor
> The following messages in the AM log of LLAP YARN Application.
> {quote}
> is running beyond physical memory limits. Current usage: of
> GB physical memory used.
> {quote}
> *Fix:* Increase the headroom space for heap from 1G (existing) to 6G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18508) Increasing headroom on heap size is from 1G to 6G for LLAP.
[
https://issues.apache.org/jira/browse/AMBARI-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapan Shridhar updated AMBARI-18508:
-
Status: Patch Available (was: Open)
> Increasing headroom on heap size is from 1G to 6G for LLAP.
> ---
>
> Key: AMBARI-18508
> URL: https://issues.apache.org/jira/browse/AMBARI-18508
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.1
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18508.patch
>
>
> *Issue:* LLAP daemons can be killed by the YARN Memory Monitor
> The following messages in the AM log of LLAP YARN Application.
> {quote}
> is running beyond physical memory limits. Current usage: of
> GB physical memory used.
> {quote}
> *Fix:* Increase the headroom space for heap from 1G (existing) to 6G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18508) Increasing headroom on heap size is from 1G to 6G for LLAP.
[
https://issues.apache.org/jira/browse/AMBARI-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapan Shridhar updated AMBARI-18508:
-
Attachment: AMBARI-18508.patch
> Increasing headroom on heap size is from 1G to 6G for LLAP.
> ---
>
> Key: AMBARI-18508
> URL: https://issues.apache.org/jira/browse/AMBARI-18508
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.1
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18508.patch
>
>
> *Issue:* LLAP daemons can be killed by the YARN Memory Monitor
> The following messages in the AM log of LLAP YARN Application.
> {quote}
> is running beyond physical memory limits. Current usage: of
> GB physical memory used.
> {quote}
> *Fix:* Increase the headroom space for heap from 1G (existing) to 6G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18508) Increasing headroom on heap size is from 1G to 6G for LLAP.
[
https://issues.apache.org/jira/browse/AMBARI-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapan Shridhar updated AMBARI-18508:
-
Description:
*Issue:* LLAP daemons can be killed by the YARN Memory Monitor
The following messages in the AM log of LLAP YARN Application.
{quote}
is running beyond physical memory limits. Current usage: of
GB physical memory used.
{quote}
*Fix:* Increase the headroom space for heap from 1G (existing) to 6G.
was:
LLAP daemons can be killed by the YARN Memory Monitor
Detecting this: The following messages in the AM log of LLAP YARN Application.
is running beyond physical memory limits. Current usage: of
GB physical memory used
> Increasing headroom on heap size is from 1G to 6G for LLAP.
> ---
>
> Key: AMBARI-18508
> URL: https://issues.apache.org/jira/browse/AMBARI-18508
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.1
>Reporter: Swapan Shridhar
>Assignee: Swapan Shridhar
> Fix For: 2.4.2
>
>
> *Issue:* LLAP daemons can be killed by the YARN Memory Monitor
> The following messages in the AM log of LLAP YARN Application.
> {quote}
> is running beyond physical memory limits. Current usage: of
> GB physical memory used.
> {quote}
> *Fix:* Increase the headroom space for heap from 1G (existing) to 6G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18501) If ambari-server fails to start, appropriate error message should be displayed.
[ https://issues.apache.org/jira/browse/AMBARI-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18501: --- Attachment: (was: AMBARI-18501.patch) > If ambari-server fails to start, appropriate error message should be > displayed. > --- > > Key: AMBARI-18501 > URL: https://issues.apache.org/jira/browse/AMBARI-18501 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 3.0.0 > > Attachments: AMBARI-18501.patch > > > If due to some error, ambari-server JAR exits with -1, we still display > “Ambari Server ‘start’ completed successfully” > In AmbariServer.java::main(), if an exception occurs, the program exits with > -1. Howerver, the caller ambari-server.py::main() displays the status message > as "Ambari Server 'start' completed successfully". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18501) If ambari-server fails to start, appropriate error message should be displayed.
[ https://issues.apache.org/jira/browse/AMBARI-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18501: --- Attachment: AMBARI-18501.patch > If ambari-server fails to start, appropriate error message should be > displayed. > --- > > Key: AMBARI-18501 > URL: https://issues.apache.org/jira/browse/AMBARI-18501 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 3.0.0 > > Attachments: AMBARI-18501.patch > > > If due to some error, ambari-server JAR exits with -1, we still display > “Ambari Server ‘start’ completed successfully” > In AmbariServer.java::main(), if an exception occurs, the program exits with > -1. Howerver, the caller ambari-server.py::main() displays the status message > as "Ambari Server 'start' completed successfully". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18508) Increasing headroom on heap size is from 1G to 6G for LLAP.
[ https://issues.apache.org/jira/browse/AMBARI-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapan Shridhar updated AMBARI-18508: - Description: LLAP daemons can be killed by the YARN Memory Monitor Detecting this: The following messages in the AM log of LLAP YARN Application. is running beyond physical memory limits. Current usage: of GB physical memory used > Increasing headroom on heap size is from 1G to 6G for LLAP. > --- > > Key: AMBARI-18508 > URL: https://issues.apache.org/jira/browse/AMBARI-18508 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.1 >Reporter: Swapan Shridhar >Assignee: Swapan Shridhar > Fix For: 2.4.2 > > > LLAP daemons can be killed by the YARN Memory Monitor > Detecting this: The following messages in the AM log of LLAP YARN Application. > is running beyond physical memory limits. Current usage: of > GB physical memory used -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18508) Increasing headroom on heap size is from 1G to 6G for LLAP.
Swapan Shridhar created AMBARI-18508: Summary: Increasing headroom on heap size is from 1G to 6G for LLAP. Key: AMBARI-18508 URL: https://issues.apache.org/jira/browse/AMBARI-18508 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.1 Reporter: Swapan Shridhar Assignee: Swapan Shridhar Fix For: 2.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18463) Regression: krb5JAASLogin.conf is not updated during secure BP install
[
https://issues.apache.org/jira/browse/AMBARI-18463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18463:
--
Attachment: AMBARI-18463_trunk_02.patch
AMBARI-18463_branch-2.5_02.patch
> Regression: krb5JAASLogin.conf is not updated during secure BP install
> --
>
> Key: AMBARI-18463
> URL: https://issues.apache.org/jira/browse/AMBARI-18463
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Blocker
> Labels: blueprints, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-18463_branch-2.5_01.patch,
> AMBARI-18463_branch-2.5_02.patch, AMBARI-18463_trunk_01.patch,
> AMBARI-18463_trunk_02.patch
>
>
> When installing a secure cluster using Blueprints, Ambari's
> {{/etc/ambari-server/conf/krb5JAASLogin.conf}} is not updated to reflect the
> details of the Ambari Kerberos identity.
> This was introduced by the patch for AMBARI-18406.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18507) Ambari issue: Unexpected repo used while installing services
[
https://issues.apache.org/jira/browse/AMBARI-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shubhangi Nivas Pardeshi updated AMBARI-18507:
--
Attachment: repo_version_withaddedepourl.txt
> Ambari issue: Unexpected repo used while installing services
>
>
> Key: AMBARI-18507
> URL: https://issues.apache.org/jira/browse/AMBARI-18507
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Shubhangi Nivas Pardeshi
>Priority: Critical
> Attachments: Formatted_repositoriesJSON_From_repo_version.txt,
> Original_repo_version.txt, Screenshot1.png, Screenshot2.png, Screenshot3.png,
> repo_version_withaddedepourl.txt
>
>
> PROBLEM:
> Ambari picks up public repository instead one registed because of incorrect
> HDP repo ID. Details are given below.
> Scanario :
> Lets consider one HDP version is already registered(screenshot1.png). Here we
> have repo URL for Redhat6 (screenshot2.png)
> Now For given version of HDP already registered to Ambari, we add new
> local/custom repository URLs for Redhat7(screenshot3.png)
> We try to add new node with Redhat7 OS , this will pick up public repo
> inspite of local repo configuration
> Cause of picking up public repo :
> RepoID of repository added later are not correct in Ambari database table
> repo_version.
> Excerpt of repositories column value from repo_version table after adding
> redhat7 repo URLs.
> [
> {
> "OperatingSystems/stack_name": "HDP",
> "OperatingSystems/stack_version": "2.3",
> "repositories": [
> {
> "Repositories/repo_id": "HDP-2.3",
> "Repositories/os_type": "redhat6",
>
> },
> {
> "Repositories/repo_id": "HDP-UTILS-1.1.0.20",
> "Repositories/os_type": "redhat6",
> ...
> }
> ],
> ...
> },
> {
> "repositories": [
> {
> "Repositories/repo_id": "HDP-2.3.4.0-3485",
> ...
> },
> {
> "Repositories/repo_id": "HDP-UTILS-2.3.4.0-3485",
> ...
> }
> ],
> "OperatingSystems/os_type": "redhat7",
> ...
> }
> ]
> In above JSON we see repoID for redhat6 is "HDP-2.3" and redhat7 is
> "HDP-2.3.4.0-3485".
> Please provide fix to register repo correctly into Ambari DB.
> EXPECTED RESULT:
> Installation should happen from registered custom/local repo.
> ACTUAL RESULT:
> Public repo is used instead of registered custom/local repo.
> WORKAROUND :
> Modify repo_version table and fix repoID for repositoried added later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18507) Ambari issue: Unexpected repo used while installing services
[
https://issues.apache.org/jira/browse/AMBARI-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shubhangi Nivas Pardeshi updated AMBARI-18507:
--
Attachment: Original_repo_version.txt
Formatted_repositoriesJSON_From_repo_version.txt
Screenshot3.png
Screenshot2.png
Screenshot1.png
> Ambari issue: Unexpected repo used while installing services
>
>
> Key: AMBARI-18507
> URL: https://issues.apache.org/jira/browse/AMBARI-18507
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Shubhangi Nivas Pardeshi
>Priority: Critical
> Attachments: Formatted_repositoriesJSON_From_repo_version.txt,
> Original_repo_version.txt, Screenshot1.png, Screenshot2.png, Screenshot3.png
>
>
> PROBLEM:
> Ambari picks up public repository instead one registed because of incorrect
> HDP repo ID. Details are given below.
> Scanario :
> Lets consider one HDP version is already registered(screenshot1.png). Here we
> have repo URL for Redhat6 (screenshot2.png)
> Now For given version of HDP already registered to Ambari, we add new
> local/custom repository URLs for Redhat7(screenshot3.png)
> We try to add new node with Redhat7 OS , this will pick up public repo
> inspite of local repo configuration
> Cause of picking up public repo :
> RepoID of repository added later are not correct in Ambari database table
> repo_version.
> Excerpt of repositories column value from repo_version table after adding
> redhat7 repo URLs.
> [
> {
> "OperatingSystems/stack_name": "HDP",
> "OperatingSystems/stack_version": "2.3",
> "repositories": [
> {
> "Repositories/repo_id": "HDP-2.3",
> "Repositories/os_type": "redhat6",
>
> },
> {
> "Repositories/repo_id": "HDP-UTILS-1.1.0.20",
> "Repositories/os_type": "redhat6",
> ...
> }
> ],
> ...
> },
> {
> "repositories": [
> {
> "Repositories/repo_id": "HDP-2.3.4.0-3485",
> ...
> },
> {
> "Repositories/repo_id": "HDP-UTILS-2.3.4.0-3485",
> ...
> }
> ],
> "OperatingSystems/os_type": "redhat7",
> ...
> }
> ]
> In above JSON we see repoID for redhat6 is "HDP-2.3" and redhat7 is
> "HDP-2.3.4.0-3485".
> Please provide fix to register repo correctly into Ambari DB.
> EXPECTED RESULT:
> Installation should happen from registered custom/local repo.
> ACTUAL RESULT:
> Public repo is used instead of registered custom/local repo.
> WORKAROUND :
> Modify repo_version table and fix repoID for repositoried added later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18507) Ambari issue: Unexpected repo used while installing services
Shubhangi Nivas Pardeshi created AMBARI-18507:
-
Summary: Ambari issue: Unexpected repo used while installing
services
Key: AMBARI-18507
URL: https://issues.apache.org/jira/browse/AMBARI-18507
Project: Ambari
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Shubhangi Nivas Pardeshi
Priority: Critical
PROBLEM:
Ambari picks up public repository instead one registed because of incorrect HDP
repo ID. Details are given below.
Scanario :
Lets consider one HDP version is already registered(screenshot1.png). Here we
have repo URL for Redhat6 (screenshot2.png)
Now For given version of HDP already registered to Ambari, we add new
local/custom repository URLs for Redhat7(screenshot3.png)
We try to add new node with Redhat7 OS , this will pick up public repo inspite
of local repo configuration
Cause of picking up public repo :
RepoID of repository added later are not correct in Ambari database table
repo_version.
Excerpt of repositories column value from repo_version table after adding
redhat7 repo URLs.
[
{
"OperatingSystems/stack_name": "HDP",
"OperatingSystems/stack_version": "2.3",
"repositories": [
{
"Repositories/repo_id": "HDP-2.3",
"Repositories/os_type": "redhat6",
},
{
"Repositories/repo_id": "HDP-UTILS-1.1.0.20",
"Repositories/os_type": "redhat6",
...
}
],
...
},
{
"repositories": [
{
"Repositories/repo_id": "HDP-2.3.4.0-3485",
...
},
{
"Repositories/repo_id": "HDP-UTILS-2.3.4.0-3485",
...
}
],
"OperatingSystems/os_type": "redhat7",
...
}
]
In above JSON we see repoID for redhat6 is "HDP-2.3" and redhat7 is
"HDP-2.3.4.0-3485".
Please provide fix to register repo correctly into Ambari DB.
EXPECTED RESULT:
Installation should happen from registered custom/local repo.
ACTUAL RESULT:
Public repo is used instead of registered custom/local repo.
WORKAROUND :
Modify repo_version table and fix repoID for repositoried added later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-13135) Provide recommendation w.r.t. CMSInitiatingOccupancy for HBase
[
https://issues.apache.org/jira/browse/AMBARI-13135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated AMBARI-13135:
Description:
The following options are recommended for HBase when ConcMarkSweepGC is used:
{code}
-XX:CMSInitiatingOccupancyFraction=50
-XX:+UseCMSInitiatingOccupancyOnly
{code}
The band for CMSInitiatingOccupancyFraction is [40, 60], depending on workload.
This should be reflected in stack_advisor.py
was:
The following options are recommended for HBase when ConcMarkSweepGC is used:
{code}
-XX:CMSInitiatingOccupancyFraction=50
-XX:+UseCMSInitiatingOccupancyOnly
{code}
The band for CMSInitiatingOccupancyFraction is [40, 60], depending on workload.
This should be reflected in stack_advisor.py
> Provide recommendation w.r.t. CMSInitiatingOccupancy for HBase
> --
>
> Key: AMBARI-13135
> URL: https://issues.apache.org/jira/browse/AMBARI-13135
> Project: Ambari
> Issue Type: Improvement
>Reporter: Ted Yu
>
> The following options are recommended for HBase when ConcMarkSweepGC is used:
> {code}
> -XX:CMSInitiatingOccupancyFraction=50
> -XX:+UseCMSInitiatingOccupancyOnly
> {code}
> The band for CMSInitiatingOccupancyFraction is [40, 60], depending on
> workload.
> This should be reflected in stack_advisor.py
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-13109) Verify that max logs parameter wouldn't cause premature region flush
[ https://issues.apache.org/jira/browse/AMBARI-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-13109: Description: For hbase, the following relationship should be maintained: dfs.blocksize * 0.95 * hbase.regionserver.maxlogs (default 32) > hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE The rationale is to avoid premature region flush due to log roll which is triggered by insufficiently high max logs. When user changes the values for max logs, memstore upper limit or max heap size, we should verify that the above relationship is satisfied. was: For hbase, the following relationship should be maintained: dfs.blocksize * 0.95 * hbase.regionserver.maxlogs (default 32) > hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE The rationale is to avoid premature region flush due to log roll which is triggered by insufficiently high max logs. When user changes the values for max logs, memstore upper limit or max heap size, we should verify that the above relationship is satisfied. > Verify that max logs parameter wouldn't cause premature region flush > > > Key: AMBARI-13109 > URL: https://issues.apache.org/jira/browse/AMBARI-13109 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > For hbase, the following relationship should be maintained: > dfs.blocksize * 0.95 * hbase.regionserver.maxlogs (default 32) > > hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE > The rationale is to avoid premature region flush due to log roll which is > triggered by insufficiently high max logs. > When user changes the values for max logs, memstore upper limit or max heap > size, we should verify that the above relationship is satisfied. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-13671) Ambari should check for duplicate config values
[ https://issues.apache.org/jira/browse/AMBARI-13671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-13671: Description: Using /#/main/services/HBASE/configs, I was able to save duplicate values for hbase.coprocessor.region.classes : org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint Ambari should check for duplicate config values. was: Using /#/main/services/HBASE/configs, I was able to save duplicate values for hbase.coprocessor.region.classes : org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint Ambari should check for duplicate config values. > Ambari should check for duplicate config values > --- > > Key: AMBARI-13671 > URL: https://issues.apache.org/jira/browse/AMBARI-13671 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > Using /#/main/services/HBASE/configs, I was able to save duplicate values for > hbase.coprocessor.region.classes : > org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint > Ambari should check for duplicate config values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14163) zookeeper session timeout for hbase should take zookeeper tickTime into account
[ https://issues.apache.org/jira/browse/AMBARI-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-14163: Description: With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value of 1 min 40 seconds. The change was accepted. However, such timeout is not reachable (it is > 20 times tickTime) Ambari should detect such scenario and warn user. was: With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value of 1 min 40 seconds. The change was accepted. However, such timeout is not reachable (it is > 20 times tickTime) Ambari should detect such scenario and warn user. > zookeeper session timeout for hbase should take zookeeper tickTime into > account > --- > > Key: AMBARI-14163 > URL: https://issues.apache.org/jira/browse/AMBARI-14163 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value > of 1 min 40 seconds. > The change was accepted. > However, such timeout is not reachable (it is > 20 times tickTime) > Ambari should detect such scenario and warn user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14160) Ambari Slider View should pick up multiple versions of the same app package
[ https://issues.apache.org/jira/browse/AMBARI-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-14160: Description: I was validating some fix for Slider hbase with Gour. A new Slider hbase app package was built and moved to under: /var/lib/ambari-server/resources/apps We tried naming the new app package ending with -ted.zip -999.zip After 'ambari-server restart', the new app package was not picked up by Ambari. Ambari Slider View should be able to accommodate more than one version of app package. was: I was validating some fix for Slider hbase with Gour. A new Slider hbase app package was built and moved to under: /var/lib/ambari-server/resources/apps We tried naming the new app package ending with -ted.zip -999.zip After 'ambari-server restart', the new app package was not picked up by Ambari. Ambari Slider View should be able to accommodate more than one version of app package. > Ambari Slider View should pick up multiple versions of the same app package > --- > > Key: AMBARI-14160 > URL: https://issues.apache.org/jira/browse/AMBARI-14160 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > I was validating some fix for Slider hbase with Gour. > A new Slider hbase app package was built and moved to under: > /var/lib/ambari-server/resources/apps > We tried naming the new app package ending with -ted.zip -999.zip > After 'ambari-server restart', the new app package was not picked up by > Ambari. > Ambari Slider View should be able to accommodate more than one version of app > package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16278) Give more time for HBase system tables to be assigned
[ https://issues.apache.org/jira/browse/AMBARI-16278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-16278: Description: We have observed extended cluster downtime due to HBase system tables not being assigned at cluster start up. The default values for the following two parameters are too low: hbase.regionserver.executor.openregion.threads (default: 3) hbase.master.namespace.init.timeout (default: 30) We set hbase.regionserver.executor.openregion.threads=200 and hbase.master.namespace.init.timeout=240 in some case to work around HBASE-14190. Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 240 for hbase.master.namespace.init.timeout as default value. was: We have observed extended cluster downtime due to HBase system tables not being assigned at cluster start up. The default values for the following two parameters are too low: hbase.regionserver.executor.openregion.threads (default: 3) hbase.master.namespace.init.timeout (default: 30) We set hbase.regionserver.executor.openregion.threads=200 and hbase.master.namespace.init.timeout=240 in some case to work around HBASE-14190. Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 240 for hbase.master.namespace.init.timeout as default value. > Give more time for HBase system tables to be assigned > - > > Key: AMBARI-16278 > URL: https://issues.apache.org/jira/browse/AMBARI-16278 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > We have observed extended cluster downtime due to HBase system tables not > being assigned at cluster start up. > The default values for the following two parameters are too low: > hbase.regionserver.executor.openregion.threads (default: 3) > hbase.master.namespace.init.timeout (default: 30) > We set hbase.regionserver.executor.openregion.threads=200 and > hbase.master.namespace.init.timeout=240 in some case to work around > HBASE-14190. > Ambari can use 20 for hbase.regionserver.executor.openregion.threads and > 240 for hbase.master.namespace.init.timeout as default value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17346) Dependent components should be shutdown before stopping hdfs
[ https://issues.apache.org/jira/browse/AMBARI-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-17346: Description: Sometimes admin shuts down hdfs first, then hbase. By the time hbase is shutdown, no data can be persisted (including metadata). This results in large number of inconsistencies when hbase cluster is brought back up. Before hdfs is shutdown, the components dependent on hdfs should be shutdown first. was: Sometimes admin shuts down hdfs first, then hbase. By the time hbase is shutdown, no data can be persisted (including metadata). This results in large number of inconsistencies when hbase cluster is brought back up. Before hdfs is shutdown, the components dependent on hdfs should be shutdown first. > Dependent components should be shutdown before stopping hdfs > > > Key: AMBARI-17346 > URL: https://issues.apache.org/jira/browse/AMBARI-17346 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > Sometimes admin shuts down hdfs first, then hbase. > By the time hbase is shutdown, no data can be persisted (including metadata). > This results in large number of inconsistencies when hbase cluster is brought > back up. > Before hdfs is shutdown, the components dependent on hdfs should be shutdown > first. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17311) Modify HTTP headers to follow best security practices
[ https://issues.apache.org/jira/browse/AMBARI-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-17311: Attachment: AMBARI-17311.patch Patch updated based on latest code. > Modify HTTP headers to follow best security practices > - > > Key: AMBARI-17311 > URL: https://issues.apache.org/jira/browse/AMBARI-17311 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: trunk > > Attachments: AMBARI-17311.patch, AMBARI-17311.patch > > > Add the following HTTP headers to follow security best practices. > X-Content-Type-Options: nosniff > Cache-control: no-store > Pragma: no-cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17311) Modify HTTP headers to follow best security practices
[ https://issues.apache.org/jira/browse/AMBARI-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-17311: Status: Patch Available (was: Open) > Modify HTTP headers to follow best security practices > - > > Key: AMBARI-17311 > URL: https://issues.apache.org/jira/browse/AMBARI-17311 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: trunk > > Attachments: AMBARI-17311.patch, AMBARI-17311.patch > > > Add the following HTTP headers to follow security best practices. > X-Content-Type-Options: nosniff > Cache-control: no-store > Pragma: no-cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17311) Modify HTTP headers to follow best security practices
[ https://issues.apache.org/jira/browse/AMBARI-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeeta Ravindran updated AMBARI-17311: Status: Open (was: Patch Available) > Modify HTTP headers to follow best security practices > - > > Key: AMBARI-17311 > URL: https://issues.apache.org/jira/browse/AMBARI-17311 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Affects Versions: trunk >Reporter: Sangeeta Ravindran >Assignee: Sangeeta Ravindran > Fix For: trunk > > Attachments: AMBARI-17311.patch > > > Add the following HTTP headers to follow security best practices. > X-Content-Type-Options: nosniff > Cache-control: no-store > Pragma: no-cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18492) Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
[
https://issues.apache.org/jira/browse/AMBARI-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536251#comment-15536251
]
Hudson commented on AMBARI-18492:
-
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5748 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5748/])
AMBARI-18492 Clusters With Many Hosts Can Create Alerts With Text Too (dsen:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=324107d1b5783ac971a14a8f1fe920a98aaff298])
* (add)
ambari-server/src/test/java/org/apache/ambari/server/state/AlertTest.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Alert.java
> Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
> ---
>
> Key: AMBARI-18492
> URL: https://issues.apache.org/jira/browse/AMBARI-18492
> Project: Ambari
> Issue Type: Bug
> Components: alerts
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18492_2.patch
>
>
> When running alerts in a large cluster (for example a cluster with 1300
> hosts), some alerts like the Stale Alert may create text too large to store
> in the database.
> On MySQL, for example, the size of a {{TEXT}} field is {{65k}} (less if UTF-8
> is used). Normally, this is plenty of space. However, some clusters
> experience:
> {code}
> ERROR [alert-event-bus-1] AmbariJpaLocalTxnInterceptor:188 - [DETAILED ERROR]
> Internal exception (1) :
> com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column
> 'alert_text' at row 1
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4185)
> {code}
> The quick solution to fix this problem is to increase the field to the
> {{MEDIUMTEXT}} size which allows for {{16MB}} of data (way overkill):
> {code}
> ALTER TABLE alert_history MODIFY alert_text MEDIUMTEXT;
> ALTER TABLE alert_current MODIFY latest_text MEDIUMTEXT;
> {code}
> Alert text should be middle-ellipsized
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18473) Scope and Services need to be used for orchestration
[ https://issues.apache.org/jira/browse/AMBARI-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18473: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Scope and Services need to be used for orchestration > > > Key: AMBARI-18473 > URL: https://issues.apache.org/jira/browse/AMBARI-18473 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18473.patch > > > Includes the following: > * The desired version for components should be limited to those components in > the VDF. > * Scope needs to be passed to UpgradeContext > * Supported services need to be passed to UpgradeContext -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18492) Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
[
https://issues.apache.org/jira/browse/AMBARI-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536130#comment-15536130
]
Hudson commented on AMBARI-18492:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #98 (See
[https://builds.apache.org/job/Ambari-branch-2.5/98/])
AMBARI-18492 Clusters With Many Hosts Can Create Alerts With Text Too (dsen:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=df9854cf9a573651508cc20e09e30c602f981e5c])
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Alert.java
* (add)
ambari-server/src/test/java/org/apache/ambari/server/state/AlertTest.java
> Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
> ---
>
> Key: AMBARI-18492
> URL: https://issues.apache.org/jira/browse/AMBARI-18492
> Project: Ambari
> Issue Type: Bug
> Components: alerts
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18492_2.patch
>
>
> When running alerts in a large cluster (for example a cluster with 1300
> hosts), some alerts like the Stale Alert may create text too large to store
> in the database.
> On MySQL, for example, the size of a {{TEXT}} field is {{65k}} (less if UTF-8
> is used). Normally, this is plenty of space. However, some clusters
> experience:
> {code}
> ERROR [alert-event-bus-1] AmbariJpaLocalTxnInterceptor:188 - [DETAILED ERROR]
> Internal exception (1) :
> com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column
> 'alert_text' at row 1
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4185)
> {code}
> The quick solution to fix this problem is to increase the field to the
> {{MEDIUMTEXT}} size which allows for {{16MB}} of data (way overkill):
> {code}
> ALTER TABLE alert_history MODIFY alert_text MEDIUMTEXT;
> ALTER TABLE alert_current MODIFY latest_text MEDIUMTEXT;
> {code}
> Alert text should be middle-ellipsized
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18506) Ambari should present message if stack upgrade path is not available
[ https://issues.apache.org/jira/browse/AMBARI-18506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536107#comment-15536107 ] Aleksandr Kovalenko commented on AMBARI-18506: -- +1 for the patch > Ambari should present message if stack upgrade path is not available > > > Key: AMBARI-18506 > URL: https://issues.apache.org/jira/browse/AMBARI-18506 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.2 > > Attachments: AMBARI-18506.patch > > > After adding a new stack version to Ambari and selecting it to be installed > on a specific cluster, the UI changes to the cluster versions page. If the > upgrade path (aka the upgrade pack) is not available for the transition from > the current stack version to the new stack version then the selected version > is not seen on that next screen. This transition is silent leaving the user > confused as to where the version went. > For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18506) Ambari should present message if stack upgrade path is not available
[ https://issues.apache.org/jira/browse/AMBARI-18506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-18506: -- Status: Patch Available (was: Open) > Ambari should present message if stack upgrade path is not available > > > Key: AMBARI-18506 > URL: https://issues.apache.org/jira/browse/AMBARI-18506 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.2 > > Attachments: AMBARI-18506.patch > > > After adding a new stack version to Ambari and selecting it to be installed > on a specific cluster, the UI changes to the cluster versions page. If the > upgrade path (aka the upgrade pack) is not available for the transition from > the current stack version to the new stack version then the selected version > is not seen on that next screen. This transition is silent leaving the user > confused as to where the version went. > For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18506) Ambari should present message if stack upgrade path is not available
[ https://issues.apache.org/jira/browse/AMBARI-18506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536095#comment-15536095 ] Andrii Tkach commented on AMBARI-18506: --- 30374 tests complete (31 seconds) 151 tests pending > Ambari should present message if stack upgrade path is not available > > > Key: AMBARI-18506 > URL: https://issues.apache.org/jira/browse/AMBARI-18506 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.2 > > Attachments: AMBARI-18506.patch > > > After adding a new stack version to Ambari and selecting it to be installed > on a specific cluster, the UI changes to the cluster versions page. If the > upgrade path (aka the upgrade pack) is not available for the transition from > the current stack version to the new stack version then the selected version > is not seen on that next screen. This transition is silent leaving the user > confused as to where the version went. > For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18506) Ambari should present message if stack upgrade path is not available
[ https://issues.apache.org/jira/browse/AMBARI-18506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Tkach updated AMBARI-18506: -- Attachment: AMBARI-18506.patch > Ambari should present message if stack upgrade path is not available > > > Key: AMBARI-18506 > URL: https://issues.apache.org/jira/browse/AMBARI-18506 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach > Fix For: 2.4.2 > > Attachments: AMBARI-18506.patch > > > After adding a new stack version to Ambari and selecting it to be installed > on a specific cluster, the UI changes to the cluster versions page. If the > upgrade path (aka the upgrade pack) is not available for the transition from > the current stack version to the new stack version then the selected version > is not seen on that next screen. This transition is silent leaving the user > confused as to where the version went. > For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18506) Ambari should present message if stack upgrade path is not available
Andrii Tkach created AMBARI-18506: - Summary: Ambari should present message if stack upgrade path is not available Key: AMBARI-18506 URL: https://issues.apache.org/jira/browse/AMBARI-18506 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.4.0 Reporter: Andrii Tkach Assignee: Andrii Tkach Fix For: 2.4.2 After adding a new stack version to Ambari and selecting it to be installed on a specific cluster, the UI changes to the cluster versions page. If the upgrade path (aka the upgrade pack) is not available for the transition from the current stack version to the new stack version then the selected version is not seen on that next screen. This transition is silent leaving the user confused as to where the version went. For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18362) Update sinks to read multiple collector hostnames from configs
[ https://issues.apache.org/jira/browse/AMBARI-18362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536017#comment-15536017 ] Hudson commented on AMBARI-18362: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5747 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5747/]) AMBARI-18362 Update sinks to read multiple collector hostnames from (dsen: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=113d51e15ab0cbd6d342023a0a0d470e51dc1a62]) * (edit) ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/params.py * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/templates/hadoop-metrics2-hiveserver2.properties.j2 * (edit) ambari-metrics/ambari-metrics-kafka-sink/src/main/java/org/apache/hadoop/metrics2/sink/kafka/KafkaTimelineMetricsReporter.java * (edit) ambari-server/src/main/java/org/apache/ambari/server/metrics/system/impl/AmbariMetricSinkImpl.java * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/templates/hadoop-metrics2-hivemetastore.properties.j2 * (edit) ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java * (edit) ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-metrics2.properties.xml * (edit) ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/params.py * (edit) ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java * (edit) ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/availability/MetricCollectorHATest.java * (edit) ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/cache/HandleConnectExceptionTest.java * (edit) ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/package/templates/hadoop-metrics2-accumulo.properties.j2 * (edit) ambari-server/src/main/resources/common-services/STORM/0.9.1/package/templates/config.yaml.j2 * (edit) ambari-server/src/main/resources/common-services/STORM/0.9.1/package/templates/storm-metrics2.properties.j2 * (edit) ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/kafka.py * (edit) ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsSink.java * (edit) ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/templates/hadoop-metrics2-hbase.properties-GANGLIA-MASTER.j2 * (edit) ambari-metrics/ambari-metrics-storm-sink-legacy/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsReporter.java * (edit) ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/package/scripts/params.py * (edit) ambari-server/src/main/resources/common-services/KAFKA/0.8.1/configuration/kafka-broker.xml * (edit) ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/params_linux.py * (edit) ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/scripts/flume.py * (edit) ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/LogFeederAMSClient.java * (edit) ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py * (edit) ambari-metrics/ambari-metrics-hadoop-sink/src/test/java/org/apache/hadoop/metrics2/sink/timeline/HadoopTimelineMetricsSinkTest.java * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/templates/hadoop-metrics2-llaptaskscheduler.j2 * (edit) ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/templates/hadoop-metrics2-hbase.properties-GANGLIA-RS.j2 * (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-START/scripts/params.py * (edit) ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/solr/metrics/SolrAmsClient.java * (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py * (edit) ambari-metrics/ambari-metrics-hadoop-sink/src/main/java/org/apache/hadoop/metrics2/sink/timeline/HadoopTimelineMetricsSink.java * (edit) ambari-metrics/ambari-metrics-storm-sink/src/main/java/org/apache/hadoop/metrics2/sink/storm/StormTimelineMetricsReporter.java * (edit) ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/package/templates/flume-metrics2.properties.j2 * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/templates/hadoop-metrics2-llapdaemon.j2 * (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-START/templates/hadoop-metrics2.properties.j2 * (edit) ambari-metrics/ambari-metrics-storm-sink-legacy/src/main/java/or
[jira] [Updated] (AMBARI-18492) Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
[
https://issues.apache.org/jira/browse/AMBARI-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmytro Sen updated AMBARI-18492:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk, branch-2.5, branch-2.4
> Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
> ---
>
> Key: AMBARI-18492
> URL: https://issues.apache.org/jira/browse/AMBARI-18492
> Project: Ambari
> Issue Type: Bug
> Components: alerts
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18492_2.patch
>
>
> When running alerts in a large cluster (for example a cluster with 1300
> hosts), some alerts like the Stale Alert may create text too large to store
> in the database.
> On MySQL, for example, the size of a {{TEXT}} field is {{65k}} (less if UTF-8
> is used). Normally, this is plenty of space. However, some clusters
> experience:
> {code}
> ERROR [alert-event-bus-1] AmbariJpaLocalTxnInterceptor:188 - [DETAILED ERROR]
> Internal exception (1) :
> com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column
> 'alert_text' at row 1
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4185)
> {code}
> The quick solution to fix this problem is to increase the field to the
> {{MEDIUMTEXT}} size which allows for {{16MB}} of data (way overkill):
> {code}
> ALTER TABLE alert_history MODIFY alert_text MEDIUMTEXT;
> ALTER TABLE alert_current MODIFY latest_text MEDIUMTEXT;
> {code}
> Alert text should be middle-ellipsized
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18492) Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
[
https://issues.apache.org/jira/browse/AMBARI-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmytro Sen updated AMBARI-18492:
Fix Version/s: (was: 2.5.0)
2.4.2
> Clusters With Many Hosts Can Create Alerts With Text Too Large To Be Stored
> ---
>
> Key: AMBARI-18492
> URL: https://issues.apache.org/jira/browse/AMBARI-18492
> Project: Ambari
> Issue Type: Bug
> Components: alerts
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18492_2.patch
>
>
> When running alerts in a large cluster (for example a cluster with 1300
> hosts), some alerts like the Stale Alert may create text too large to store
> in the database.
> On MySQL, for example, the size of a {{TEXT}} field is {{65k}} (less if UTF-8
> is used). Normally, this is plenty of space. However, some clusters
> experience:
> {code}
> ERROR [alert-event-bus-1] AmbariJpaLocalTxnInterceptor:188 - [DETAILED ERROR]
> Internal exception (1) :
> com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column
> 'alert_text' at row 1
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4185)
> {code}
> The quick solution to fix this problem is to increase the field to the
> {{MEDIUMTEXT}} size which allows for {{16MB}} of data (way overkill):
> {code}
> ALTER TABLE alert_history MODIFY alert_text MEDIUMTEXT;
> ALTER TABLE alert_current MODIFY latest_text MEDIUMTEXT;
> {code}
> Alert text should be middle-ellipsized
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18505) Ambari Status commands should enforce a timeout < heartbeat interval
[
https://issues.apache.org/jira/browse/AMBARI-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535850#comment-15535850
]
Hadoop QA commented on AMBARI-18505:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12831086/AMBARI-18505.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8777//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8777//console
This message is automatically generated.
> Ambari Status commands should enforce a timeout < heartbeat interval
>
>
> Key: AMBARI-18505
> URL: https://issues.apache.org/jira/browse/AMBARI-18505
> Project: Ambari
> Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.2
>
> Attachments: AMBARI-18505.patch
>
>
> SmartSense status command does an http call without timeout in 1.2 version of
> SS.
> Ambari agent queues STATUS commands until we end up with HB lost state with
> ton of commands queued up.
> This should just never happen is commands are getting queued by by the agent
> every HB.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18501) If ambari-server fails to start, appropriate error message should be displayed.
[
https://issues.apache.org/jira/browse/AMBARI-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535815#comment-15535815
]
Hadoop QA commented on AMBARI-18501:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12831094/AMBARI-18501.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8776//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8776//console
This message is automatically generated.
> If ambari-server fails to start, appropriate error message should be
> displayed.
> ---
>
> Key: AMBARI-18501
> URL: https://issues.apache.org/jira/browse/AMBARI-18501
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
> Fix For: 3.0.0
>
> Attachments: AMBARI-18501.patch
>
>
> If due to some error, ambari-server JAR exits with -1, we still display
> “Ambari Server ‘start’ completed successfully”
> In AmbariServer.java::main(), if an exception occurs, the program exits with
> -1. Howerver, the caller ambari-server.py::main() displays the status message
> as "Ambari Server 'start' completed successfully".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18493) Error on manage group popup
[ https://issues.apache.org/jira/browse/AMBARI-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535780#comment-15535780 ] Hudson commented on AMBARI-18493: - ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #5746 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5746/]) AMBARI-18493 Error on manage group popup. (ababiichuk) (ababiichuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=013b7bd08117abc082400279f7b24d33a9819e34]) * (edit) ambari-web/app/controllers/main/service/manage_config_groups_controller.js > Error on manage group popup > --- > > Key: AMBARI-18493 > URL: https://issues.apache.org/jira/browse/AMBARI-18493 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-18493.patch > > > 1. Open manage config group popup. > 2. Create new config group and assing some host to it > 3. Create duplicate from new group > 4. Click save > ER: > groups are saved and popup is closed > AR: > groups are saved but popup is shown and sometimes it shows red labe '[Object > object]' where error whould be shown. (There were not any errors though) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18494) Js error when changing config group via dropdown
[ https://issues.apache.org/jira/browse/AMBARI-18494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535781#comment-15535781 ] Hudson commented on AMBARI-18494: - ABORTED: Integrated in Jenkins build Ambari-trunk-Commit #5746 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5746/]) AMBARI-18494 Js error when changing config group via dropdown. (ababiichuk: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=120505f9a2b4da35604564f0ab066ad67fecd86a]) * (edit) ambari-web/app/mixins/common/configs/config_recommendation_parser.js * (edit) ambari-web/test/mixins/common/configs/config_recommendation_parser_test.js > Js error when changing config group via dropdown > > > Key: AMBARI-18494 > URL: https://issues.apache.org/jira/browse/AMBARI-18494 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-18494.patch > > > Install cluster go to service configs and create config group. > try to change selected config group via dropdown - js error rise and page is > not loading -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18355) Introduce conditional dependencies in stack defition to handle blueprint validation gracefully
[
https://issues.apache.org/jira/browse/AMBARI-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535770#comment-15535770
]
Hadoop QA commented on AMBARI-18355:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12831026/AMBARI-18355_v4.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
ambari-server:
org.apache.ambari.server.agent.AgentResourceTest
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8775//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8775//console
This message is automatically generated.
> Introduce conditional dependencies in stack defition to handle blueprint
> validation gracefully
> --
>
> Key: AMBARI-18355
> URL: https://issues.apache.org/jira/browse/AMBARI-18355
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Affects Versions: trunk
>Reporter: Amruta Borkar
>Assignee: Amruta Borkar
> Fix For: trunk
>
> Attachments: AMBARI-18355.patch, AMBARI-18355_v1.patch,
> AMBARI-18355_v2.patch, AMBARI-18355_v3.patch, AMBARI-18355_v4.patch, Adding
> Conditional Dependencies.pdf
>
>
> Currently stack definitions do not list conditional dependencies, adding
> those to the stack definitions would make it easy to validate errors in case
> of blueprint deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18501) If ambari-server fails to start, appropriate error message should be displayed.
[ https://issues.apache.org/jira/browse/AMBARI-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18501: --- Attachment: (was: AMBARI-18501.patch) > If ambari-server fails to start, appropriate error message should be > displayed. > --- > > Key: AMBARI-18501 > URL: https://issues.apache.org/jira/browse/AMBARI-18501 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 3.0.0 > > Attachments: AMBARI-18501.patch > > > If due to some error, ambari-server JAR exits with -1, we still display > “Ambari Server ‘start’ completed successfully” > In AmbariServer.java::main(), if an exception occurs, the program exits with > -1. Howerver, the caller ambari-server.py::main() displays the status message > as "Ambari Server 'start' completed successfully". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18501) If ambari-server fails to start, appropriate error message should be displayed.
[ https://issues.apache.org/jira/browse/AMBARI-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Brodetskyi updated AMBARI-18501: --- Attachment: AMBARI-18501.patch > If ambari-server fails to start, appropriate error message should be > displayed. > --- > > Key: AMBARI-18501 > URL: https://issues.apache.org/jira/browse/AMBARI-18501 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.5.0 >Reporter: Vitaly Brodetskyi >Assignee: Vitaly Brodetskyi > Fix For: 3.0.0 > > Attachments: AMBARI-18501.patch > > > If due to some error, ambari-server JAR exits with -1, we still display > “Ambari Server ‘start’ completed successfully” > In AmbariServer.java::main(), if an exception occurs, the program exits with > -1. Howerver, the caller ambari-server.py::main() displays the status message > as "Ambari Server 'start' completed successfully". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18362) Update sinks to read multiple collector hostnames from configs
[ https://issues.apache.org/jira/browse/AMBARI-18362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Sen updated AMBARI-18362: Resolution: Fixed Status: Resolved (was: Patch Available) Committed to trunk > Update sinks to read multiple collector hostnames from configs > -- > > Key: AMBARI-18362 > URL: https://issues.apache.org/jira/browse/AMBARI-18362 > Project: Ambari > Issue Type: Task >Reporter: Dmytro Sen >Assignee: Dmytro Sen >Priority: Critical > Fix For: trunk > > Attachments: AMBARI-18362.patch, AMBARI-18362_2.patch, > AMBARI-18362_3.patch > > > Update sinks to read multiple collector hostnames from configs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18431) Storm Ambari view - Fixes to DAG, kafka offset info , Misc fixes.
[
https://issues.apache.org/jira/browse/AMBARI-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535560#comment-15535560
]
Hadoop QA commented on AMBARI-18431:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12831053/0001-Changed-topology-DAG-Fixed-Kafka-Spout-Lag-data-form.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
contrib/views/storm.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8774//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8774//console
This message is automatically generated.
> Storm Ambari view - Fixes to DAG, kafka offset info , Misc fixes.
> -
>
> Key: AMBARI-18431
> URL: https://issues.apache.org/jira/browse/AMBARI-18431
> Project: Ambari
> Issue Type: Improvement
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
> Attachments:
> 0001-Changed-topology-DAG-Fixed-Kafka-Spout-Lag-data-form.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18503) MapReduce is showing incorrect component version in HDP 2.6
[
https://issues.apache.org/jira/browse/AMBARI-18503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535522#comment-15535522
]
Hadoop QA commented on AMBARI-18503:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12831069/AMBARI-18503.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8773//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8773//console
This message is automatically generated.
> MapReduce is showing incorrect component version in HDP 2.6
> ---
>
> Key: AMBARI-18503
> URL: https://issues.apache.org/jira/browse/AMBARI-18503
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: trunk, 2.5.0
>Reporter: Dmytro Grinenko
> Fix For: trunk, 2.5.0
>
> Attachments: AMBARI-18503.patch
>
>
> MR2 has 2.7.1.2.5 as the version in the HDP-2.6 stack. Should be 2.7.1.2.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18505) Ambari Status commands should enforce a timeout < heartbeat interval
Andrew Onischuk created AMBARI-18505: Summary: Ambari Status commands should enforce a timeout < heartbeat interval Key: AMBARI-18505 URL: https://issues.apache.org/jira/browse/AMBARI-18505 Project: Ambari Issue Type: Bug Reporter: Andrew Onischuk Assignee: Andrew Onischuk Fix For: 2.4.2 Attachments: AMBARI-18505.patch SmartSense status command does an http call without timeout in 1.2 version of SS. Ambari agent queues STATUS commands until we end up with HB lost state with ton of commands queued up. This should just never happen is commands are getting queued by by the agent every HB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18505) Ambari Status commands should enforce a timeout < heartbeat interval
[ https://issues.apache.org/jira/browse/AMBARI-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-18505: - Status: Patch Available (was: Open) > Ambari Status commands should enforce a timeout < heartbeat interval > > > Key: AMBARI-18505 > URL: https://issues.apache.org/jira/browse/AMBARI-18505 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 2.4.2 > > Attachments: AMBARI-18505.patch > > > SmartSense status command does an http call without timeout in 1.2 version of > SS. > Ambari agent queues STATUS commands until we end up with HB lost state with > ton of commands queued up. > This should just never happen is commands are getting queued by by the agent > every HB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18505) Ambari Status commands should enforce a timeout < heartbeat interval
[ https://issues.apache.org/jira/browse/AMBARI-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Onischuk updated AMBARI-18505: - Attachment: AMBARI-18505.patch > Ambari Status commands should enforce a timeout < heartbeat interval > > > Key: AMBARI-18505 > URL: https://issues.apache.org/jira/browse/AMBARI-18505 > Project: Ambari > Issue Type: Bug >Reporter: Andrew Onischuk >Assignee: Andrew Onischuk > Fix For: 2.4.2 > > Attachments: AMBARI-18505.patch > > > SmartSense status command does an http call without timeout in 1.2 version of > SS. > Ambari agent queues STATUS commands until we end up with HB lost state with > ton of commands queued up. > This should just never happen is commands are getting queued by by the agent > every HB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18504) Build fails at verify step due to leftover findbugs html file
[
https://issues.apache.org/jira/browse/AMBARI-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535470#comment-15535470
]
Hadoop QA commented on AMBARI-18504:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12831074/AMBARI-18504.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8772//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8772//console
This message is automatically generated.
> Build fails at verify step due to leftover findbugs html file
> -
>
> Key: AMBARI-18504
> URL: https://issues.apache.org/jira/browse/AMBARI-18504
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18504.patch
>
>
> Maven build fails at the {{verify}} step if run without {{clean}} due to
> leftover {{findbugsXml.html}} file. The problem is that the XML to HTML
> transformation is applied to the leftover HTML, too, which is not valid XML.
> Steps to reproduce:
> {noformat}
> $ mvn -pl ambari-server -DskipTests clean verify
> ...
> [INFO] BUILD SUCCESS
> ...
> $ mvn -pl ambari-server -DskipTests verify
> ...
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.codehaus.mojo:xml-maven-plugin:1.0:transform (default) on project
> ambari-server: Failed to transform input file
> .../ambari-server/target/findbugs/findbugsXml.html
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18504) Build fails at verify step due to leftover findbugs html file
[
https://issues.apache.org/jira/browse/AMBARI-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18504:
---
Status: Patch Available (was: Open)
> Build fails at verify step due to leftover findbugs html file
> -
>
> Key: AMBARI-18504
> URL: https://issues.apache.org/jira/browse/AMBARI-18504
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18504.patch
>
>
> Maven build fails at the {{verify}} step if run without {{clean}} due to
> leftover {{findbugsXml.html}} file. The problem is that the XML to HTML
> transformation is applied to the leftover HTML, too, which is not valid XML.
> Steps to reproduce:
> {noformat}
> $ mvn -pl ambari-server -DskipTests clean verify
> ...
> [INFO] BUILD SUCCESS
> ...
> $ mvn -pl ambari-server -DskipTests verify
> ...
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.codehaus.mojo:xml-maven-plugin:1.0:transform (default) on project
> ambari-server: Failed to transform input file
> .../ambari-server/target/findbugs/findbugsXml.html
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18504) Build fails at verify step due to leftover findbugs html file
[
https://issues.apache.org/jira/browse/AMBARI-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18504:
---
Attachment: AMBARI-18504.patch
> Build fails at verify step due to leftover findbugs html file
> -
>
> Key: AMBARI-18504
> URL: https://issues.apache.org/jira/browse/AMBARI-18504
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18504.patch
>
>
> Maven build fails at the {{verify}} step if run without {{clean}} due to
> leftover {{findbugsXml.html}} file. The problem is that the XML to HTML
> transformation is applied to the leftover HTML, too, which is not valid XML.
> Steps to reproduce:
> {noformat}
> $ mvn -pl ambari-server -DskipTests clean verify
> ...
> [INFO] BUILD SUCCESS
> ...
> $ mvn -pl ambari-server -DskipTests verify
> ...
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.codehaus.mojo:xml-maven-plugin:1.0:transform (default) on project
> ambari-server: Failed to transform input file
> .../ambari-server/target/findbugs/findbugsXml.html
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18504) Build fails at verify step due to leftover findbugs html file
[
https://issues.apache.org/jira/browse/AMBARI-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18504:
---
Attachment: (was: AMBARI-18504.patch)
> Build fails at verify step due to leftover findbugs html file
> -
>
> Key: AMBARI-18504
> URL: https://issues.apache.org/jira/browse/AMBARI-18504
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
>
> Maven build fails at the {{verify}} step if run without {{clean}} due to
> leftover {{findbugsXml.html}} file. The problem is that the XML to HTML
> transformation is applied to the leftover HTML, too, which is not valid XML.
> Steps to reproduce:
> {noformat}
> $ mvn -pl ambari-server -DskipTests clean verify
> ...
> [INFO] BUILD SUCCESS
> ...
> $ mvn -pl ambari-server -DskipTests verify
> ...
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.codehaus.mojo:xml-maven-plugin:1.0:transform (default) on project
> ambari-server: Failed to transform input file
> .../ambari-server/target/findbugs/findbugsXml.html
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18504) Build fails at verify step due to leftover findbugs html file
[
https://issues.apache.org/jira/browse/AMBARI-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18504:
---
Attachment: AMBARI-18504.patch
> Build fails at verify step due to leftover findbugs html file
> -
>
> Key: AMBARI-18504
> URL: https://issues.apache.org/jira/browse/AMBARI-18504
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: AMBARI-18504.patch
>
>
> Maven build fails at the {{verify}} step if run without {{clean}} due to
> leftover {{findbugsXml.html}} file. The problem is that the XML to HTML
> transformation is applied to the leftover HTML, too, which is not valid XML.
> Steps to reproduce:
> {noformat}
> $ mvn -pl ambari-server -DskipTests clean verify
> ...
> [INFO] BUILD SUCCESS
> ...
> $ mvn -pl ambari-server -DskipTests verify
> ...
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.codehaus.mojo:xml-maven-plugin:1.0:transform (default) on project
> ambari-server: Failed to transform input file
> .../ambari-server/target/findbugs/findbugsXml.html
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18504) Build fails at verify step due to leftover findbugs html file
Doroszlai, Attila created AMBARI-18504:
--
Summary: Build fails at verify step due to leftover findbugs html
file
Key: AMBARI-18504
URL: https://issues.apache.org/jira/browse/AMBARI-18504
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Doroszlai, Attila
Assignee: Doroszlai, Attila
Priority: Minor
Fix For: 3.0.0
Maven build fails at the {{verify}} step if run without {{clean}} due to
leftover {{findbugsXml.html}} file. The problem is that the XML to HTML
transformation is applied to the leftover HTML, too, which is not valid XML.
Steps to reproduce:
{noformat}
$ mvn -pl ambari-server -DskipTests clean verify
...
[INFO] BUILD SUCCESS
...
$ mvn -pl ambari-server -DskipTests verify
...
[INFO] BUILD FAILURE
[ERROR] Failed to execute goal org.codehaus.mojo:xml-maven-plugin:1.0:transform
(default) on project ambari-server: Failed to transform input file
.../ambari-server/target/findbugs/findbugsXml.html
...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18503) MapReduce is showing incorrect component version in HDP 2.6
[ https://issues.apache.org/jira/browse/AMBARI-18503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Grinenko updated AMBARI-18503: - Status: Patch Available (was: Open) > MapReduce is showing incorrect component version in HDP 2.6 > --- > > Key: AMBARI-18503 > URL: https://issues.apache.org/jira/browse/AMBARI-18503 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Dmytro Grinenko > Fix For: trunk, 2.5.0 > > Attachments: AMBARI-18503.patch > > > MR2 has 2.7.1.2.5 as the version in the HDP-2.6 stack. Should be 2.7.1.2.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18503) MapReduce is showing incorrect component version in HDP 2.6
[ https://issues.apache.org/jira/browse/AMBARI-18503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Grinenko updated AMBARI-18503: - Attachment: AMBARI-18503.patch > MapReduce is showing incorrect component version in HDP 2.6 > --- > > Key: AMBARI-18503 > URL: https://issues.apache.org/jira/browse/AMBARI-18503 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Dmytro Grinenko > Fix For: trunk, 2.5.0 > > Attachments: AMBARI-18503.patch > > > MR2 has 2.7.1.2.5 as the version in the HDP-2.6 stack. Should be 2.7.1.2.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18503) MapReduce is showing incorrect component version in HDP 2.6
Dmytro Grinenko created AMBARI-18503: Summary: MapReduce is showing incorrect component version in HDP 2.6 Key: AMBARI-18503 URL: https://issues.apache.org/jira/browse/AMBARI-18503 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: trunk, 2.5.0 Reporter: Dmytro Grinenko Fix For: trunk, 2.5.0 MR2 has 2.7.1.2.5 as the version in the HDP-2.6 stack. Should be 2.7.1.2.6. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18494) Js error when changing config group via dropdown
[ https://issues.apache.org/jira/browse/AMBARI-18494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-18494: -- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk > Js error when changing config group via dropdown > > > Key: AMBARI-18494 > URL: https://issues.apache.org/jira/browse/AMBARI-18494 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-18494.patch > > > Install cluster go to service configs and create config group. > try to change selected config group via dropdown - js error rise and page is > not loading -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18493) Error on manage group popup
[ https://issues.apache.org/jira/browse/AMBARI-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrii Babiichuk updated AMBARI-18493: -- Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk > Error on manage group popup > --- > > Key: AMBARI-18493 > URL: https://issues.apache.org/jira/browse/AMBARI-18493 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Andrii Babiichuk >Assignee: Andrii Babiichuk > Fix For: 3.0.0 > > Attachments: AMBARI-18493.patch > > > 1. Open manage config group popup. > 2. Create new config group and assing some host to it > 3. Create duplicate from new group > 4. Click save > ER: > groups are saved and popup is closed > AR: > groups are saved but popup is shown and sometimes it shows red labe '[Object > object]' where error whould be shown. (There were not any errors though) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
