Team...
It looks like we have one more unit test failure to handle. This one seems to
be intermittent and not reproducible by me, locally...
1455539 [ERROR]
testComponents(org.apache.ambari.server.agent.TestHeartbeatHandler) Time
elapsed: 1.116 s <<< ERROR!
java.lang.NullPointerException
at
org.apache.ambari.server.agent.TestHeartbeatHandler.testComponents(TestHeartbeatHandler.java:1351)
The code in question looks like
ComponentsResponse actual = handler.handleComponents(DummyCluster);
Anyone have any insight on this?
Rob
On 4/3/18, 2:57 PM, "Robert Levas" <[email protected]> wrote:
Thanks Aravindan...
Keep in mind, these are just the _latest_ issues. I spent a lot of this
past weekend fixing other issues that were introduced previously.
Rob
On 4/3/18, 2:53 PM, "Aravindan Vijayan" <[email protected]> wrote:
Hi Rob,
Most of these unit test failures have been introduced by the AMS perf
branch merge which I did this weekend. I will submit a pull request to @Ignore
these tests for now, but will have the blocker jira (AMBARI-23438) open for
fixing them in the near future.
--
Thanks and Regards,
Aravindan Vijayan
On 4/3/18, 11:00 AM, "Robert Levas" <[email protected]> wrote:
Team…
The amount of patches we are committing to trunk without ensuring
the unit tests run successfully is getting out of control.
I know that we all write flawless code, but sometimes we do mess
up; and the unit tests are there to help us find those mistakes. Can we make
sure that we run the unit tests locally before submitting patches and then
ensure that the unit tests pass before merging into the trunk.
Sometimes, the failure is not related to our patches. However, I
have seen several times where this was the claim, yet in the end the failure
was due to that patch. If there is a unit test failure and you have the time
to track it down, please do and file a JIRA. If you can figure out what patch
caused the error, you can assign the JIRA to the responsible party or you can
attempt to fix the issue yourself. In the event the issue is rather large,
reverting that offending patch is an option. Since this is getting out of
control and I am trying to follow the protocol, I am considering taking it upon
myself to revert patches that cause unit test failures.
We have work to do, and these issues are slowing us down. On top
of the failures, we have a lot of people blindly issuing “retest this please”
requests. The end result is a backup of the Ambari-Github-PullRequest-Builder
queue, only to continue to fail. The last 40 or so test runs have failed and
we currently have a backlog of 5 pending test runs that will probably fail due
to the following failures:
Ambari Metrics Collector
Tests in error:
org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.source.RawMetricsSourceTest.testRawMetricsCachedAndSourced(org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.source.RawMetricsSourceTest)
Run 1: RawMetricsSourceTest.testRawMetricsCachedAndSourced:114 »
Cache java.lang.Runt...
Run 2: PASS
RawMetricsSourceTest.testRawMetricsSourcedAtFlushInterval:72 »
Cache java.lang..
Ambari Server
1980102 [ERROR] Failures:
1980102 [ERROR]
StackDefinedPropertyProviderTest.testStackDefinedPropertyProviderAsAdministrator:243->testPopulateResourcesWithAggregateFunctionMetrics:1235
expected:<4> but was:<3>
1980103 [ERROR]
StackDefinedPropertyProviderTest.testStackDefinedPropertyProviderAsClusterAdministrator:221->testPopulateResourcesWithAggregateFunctionMetrics:1235
expected:<4> but was:<3>
1980103 [ERROR]
StackDefinedPropertyProviderTest.testStackDefinedPropertyProviderAsServiceAdministrator:265->testPopulateResourcesWithAggregateFunctionMetrics:1235
expected:<4> but was:<3>
1980103 [ERROR]
AMSPropertyProviderTest.testFilterOutOfBandMetricData:741 No value for property
metrics/cpu/cpu_user
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForHostComponentMetricsForMultipleHosts:1030
No value for property metrics/dfs/datanode/blocks_removed
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForMultipleHostMetricscPointInTime:307
No value for property metrics/cpu/cpu_user
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForRegexpMetrics:430 No value for
property metrics/yarn/Queue/root/AvailableMB
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForSingleComponentMetric:480 No
value for property metrics/rpc/RpcQueueTime_avg_time
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForSingleHostMetric:207 No value
for property metrics/cpu/cpu_user
1980103 [ERROR]
AMSPropertyProviderTest.testRbacForAMSPropertyProvider:123->testPopulateResourcesForSingleHostMetric:207
No value for property metrics/cpu/cpu_user
1980103 [ERROR] Errors:
1980103 [ERROR] TestHeartbeatHandler.testComponents:1351 »
NullPointer
1980103 [ERROR]
AMSPropertyProviderTest.testAggregateFunctionForComponentMetrics:695 NullPointer
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateMetricsForEmbeddedHBase:614 NullPointer
1980103 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForHostComponentHostMetrics:847
NullPointer
1980104 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForMultipleHostMetrics:373
NullPointer
1980104 [ERROR]
AMSPropertyProviderTest.testPopulateResourcesForSingleHostMetricPointInTime:255
NullPointer
1980104 [ERROR]
AMSReportPropertyProviderTest.testPopulateResourceWithAggregateFunction:146
NullPointer
1980104 [ERROR]
AMSReportPropertyProviderTest.testPopulateResources:103 NullPointer
1980104 [ERROR]
ServicePropertiesTest.validatePropertySchemaOfServiceXMLs:49 » Ambari File
/ho...
We need to get these errors fixed before rerunning any more tests
or merging any more patches.
Rob
