You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by John Speidel <js...@hortonworks.com> on 2014/11/19 16:51:23 UTC
trunk build failing due to ambari-web test failure
Has been failing since:
AMBARI-8382 <https://issues.apache.org/jira/browse/AMBARI-8382> Configs:
Dashboard > Config History custom date option issues. (atkach)
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: trunk build failing due to ambari-web test failure
Posted by Yusaku Sako <yu...@hortonworks.com>.
UT tests are green now:
https://builds.apache.org/job/Ambari-trunk-Commit/987/.
Yusaku
On Wed, Nov 19, 2014 at 11:41 AM, Yusaku Sako <yu...@hortonworks.com>
wrote:
> Thanks for reporting the issue.
> Unit tests should always pass; no questions about it.
>
> This particular UT failure doesn't seem like it was based on neglect on
> the developer's part.
> The commit that introduced this UT failure is
> https://issues.apache.org/jira/browse/AMBARI-8382.
> If you look at the JIRA, the standard process was followed, including
> submitting the patch and waiting for Hadoop QA to post the results on unit
> tests (which reported everything was OK). However, this Hadoop QA didn't
> really run ambari-web unit tests, which is another issue.
> However, the post-commit job reported that UT failed, so that's when we
> should have caught this and reverted the patch (after verifying it is
> indeed an issue).
>
> By looking at the unit test results, this seems to be a OS timezone
> related issue, where the UT in question passes if the machine is in a
> certain timezone while not on other machines in different timezones; unit
> tests should not be dependent on timezones and it should be fixed.
>
> We need to clarify the process around handling the post-commit UT failures.
>
> At any rate, we'll fix this UT issue ASAP.
>
> Yusaku
>
>
> On Wed, Nov 19, 2014 at 10:03 AM, Robert Levas <rl...@hortonworks.com>
> wrote:
>
>> Team…
>>
>> It would be nice if this can be fixed quickly. This type of situation is
>> holding me ( and I assume a lot of other developers) up.
>>
>> In the future can we try to be more vigilant about running the tests
>> before merging into the trunk? With approaching deadlines, no one can
>> afford to be waiting around for issues like this to be fixed… especially
>> when they could have been prevented in the first place.
>>
>> I am not a committer but I can’t imagine that this preventative measure
>> would take that much time away from your other tasks. On that note, by
>> failing to take the time and run the tests and then causing this issue, you
>> most likely have created additional work for yourself - assuming you are
>> involved in fixing the issue.
>>
>> Rob
>>
>>
>>
>>
>>
>> On Nov 19, 2014, at 10:51 AM, John Speidel <js...@hortonworks.com>
>> wrote:
>>
>> > Has been failing since:
>> > AMBARI-8382 <https://issues.apache.org/jira/browse/AMBARI-8382>
>> Configs:
>> > Dashboard > Config History custom date option issues. (atkach)
>> >
>> > --
>> > CONFIDENTIALITY NOTICE
>> > NOTICE: This message is intended for the use of the individual or
>> entity to
>> > which it is addressed and may contain information that is confidential,
>> > privileged and exempt from disclosure under applicable law. If the
>> reader
>> > of this message is not the intended recipient, you are hereby notified
>> that
>> > any printing, copying, dissemination, distribution, disclosure or
>> > forwarding of this communication is strictly prohibited. If you have
>> > received this communication in error, please contact the sender
>> immediately
>> > and delete it from your system. Thank You.
>>
>>
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity
>> to
>> which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified
>> that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender
>> immediately
>> and delete it from your system. Thank You.
>>
>
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: trunk build failing due to ambari-web test failure
Posted by Yusaku Sako <yu...@hortonworks.com>.
Thanks for reporting the issue.
Unit tests should always pass; no questions about it.
This particular UT failure doesn't seem like it was based on neglect on the
developer's part.
The commit that introduced this UT failure is
https://issues.apache.org/jira/browse/AMBARI-8382.
If you look at the JIRA, the standard process was followed, including
submitting the patch and waiting for Hadoop QA to post the results on unit
tests (which reported everything was OK). However, this Hadoop QA didn't
really run ambari-web unit tests, which is another issue.
However, the post-commit job reported that UT failed, so that's when we
should have caught this and reverted the patch (after verifying it is
indeed an issue).
By looking at the unit test results, this seems to be a OS timezone related
issue, where the UT in question passes if the machine is in a certain
timezone while not on other machines in different timezones; unit tests
should not be dependent on timezones and it should be fixed.
We need to clarify the process around handling the post-commit UT failures.
At any rate, we'll fix this UT issue ASAP.
Yusaku
On Wed, Nov 19, 2014 at 10:03 AM, Robert Levas <rl...@hortonworks.com>
wrote:
> Team…
>
> It would be nice if this can be fixed quickly. This type of situation is
> holding me ( and I assume a lot of other developers) up.
>
> In the future can we try to be more vigilant about running the tests
> before merging into the trunk? With approaching deadlines, no one can
> afford to be waiting around for issues like this to be fixed… especially
> when they could have been prevented in the first place.
>
> I am not a committer but I can’t imagine that this preventative measure
> would take that much time away from your other tasks. On that note, by
> failing to take the time and run the tests and then causing this issue, you
> most likely have created additional work for yourself - assuming you are
> involved in fixing the issue.
>
> Rob
>
>
>
>
>
> On Nov 19, 2014, at 10:51 AM, John Speidel <js...@hortonworks.com>
> wrote:
>
> > Has been failing since:
> > AMBARI-8382 <https://issues.apache.org/jira/browse/AMBARI-8382> Configs:
> > Dashboard > Config History custom date option issues. (atkach)
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: trunk build failing due to ambari-web test failure
Posted by Robert Levas <rl...@hortonworks.com>.
Team…
It would be nice if this can be fixed quickly. This type of situation is holding me ( and I assume a lot of other developers) up.
In the future can we try to be more vigilant about running the tests before merging into the trunk? With approaching deadlines, no one can afford to be waiting around for issues like this to be fixed… especially when they could have been prevented in the first place.
I am not a committer but I can’t imagine that this preventative measure would take that much time away from your other tasks. On that note, by failing to take the time and run the tests and then causing this issue, you most likely have created additional work for yourself - assuming you are involved in fixing the issue.
Rob
On Nov 19, 2014, at 10:51 AM, John Speidel <js...@hortonworks.com> wrote:
> Has been failing since:
> AMBARI-8382 <https://issues.apache.org/jira/browse/AMBARI-8382> Configs:
> Dashboard > Config History custom date option issues. (atkach)
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.