ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srimanth Gunturi" <srima...@hortonworks.com>
Subject Re: Review Request 26526: Stack version must start with 2. to be considered Hadoop-2.x compatible
Date Fri, 10 Oct 2014 00:46:02 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26526/#review56088
-----------------------------------------------------------

Ship it!


Ship It!

- Srimanth Gunturi


On Oct. 9, 2014, 9:47 p.m., Jaimin Jetly wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26526/
> -----------------------------------------------------------
> 
> (Updated Oct. 9, 2014, 9:47 p.m.)
> 
> 
> Review request for Ambari, Srimanth Gunturi and Yusaku Sako.
> 
> 
> Bugs: AMBARI-7229
>     https://issues.apache.org/jira/browse/AMBARI-7229
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> Looking at JavaScript logic is seems these properties are processed only for Hadoop 2.x
compatible stacks and App.js checks if the stack version starts with 2 to consider it Hadoop
2.x compatible, which is not the case with 0.8 version of BIGTOP stack.
> PROPOSAL: the fact that a given stack is Hadoop 2.x compatible should not be tied to
the vendor stack version number, but rather explicitly defined as a property either in the
stack definition or the service definition. Alternatively, looking at the actual version of
the HDFS service included in the stack will be able to reveal if the stack is Hadoop 2.x compliant.
> 
> 
> Diffs
> -----
> 
>   ambari-web/app/app.js e057814 
>   ambari-web/app/mappers/stack_service_mapper.js 1732549 
>   ambari-web/test/app_test.js a8f5151 
> 
> Diff: https://reviews.apache.org/r/26526/diff/
> 
> 
> Testing
> -------
> 
> tested e2e
> 
> 
> Thanks,
> 
> Jaimin Jetly
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message