> On July 12, 2017, 9:11 a.m., Sebastian Toader wrote:
> > A few observations regarding the *trunk* patch:
> > - HDP/2.6/services/KAFKA/metainfo.xml 
> > ```<extends>common-services/KAFKA/0.10.0</extends>```. This is not needed 
> > as HDP/2.6 already extends HDP/2.5 (see HDP/2.6/metainfo.xml) thus 
> > HDP/2.6/services/KAFKA/metainfo.xml inherits from 
> > HDP/2.5/services/KAFKA/metainfo.xml which in turn 
> > ```<extends>common-services/KAFKA/0.10.0</extends>```
> > - HDP/3.0/services/KAFKA doesn't seem to have the rack awarness 
> > implementation.  Note HDP 3.0 doesn't derive from HDP2.6 thus the rack 
> > awarness code has to be added to ommon-services/KAFKA/0.10.0.3.0 as well.

Fixed


- Ambud


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


On July 13, 2017, 5:15 p.m., Ambud Sharma wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60249/
> -----------------------------------------------------------
> 
> (Updated July 13, 2017, 5:15 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Sriharsha Chintalapani.
> 
> 
> Bugs: AMBARI-21234
>     https://issues.apache.org/jira/browse/AMBARI-21234
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> Ambari rack awareness for Kafka. 
> https://issues.apache.org/jira/browse/AMBARI-21234
> 
> As an operations person it would be nice to manage Kafka rack awareness via 
> Ambari. Ambari allows node rack information to be configured and this 
> information can then be pulled in the Kafka stack and populated in the 
> server.properties file for Kafka.
> Design:
> This stack change uses the /clusterHostInfo/all_hosts and 
> /clusterHostInfo/all_racks paths and materializes them to a variable. Then it 
> uses linear search to find this node in the list of all hosts and it's 
> corresponding rack id. This information is then stored in a variable called 
> rack and which is materialized during the configure method of the broker 
> scripts.
> This stack change relies on the node rack information stored in Ambari 
> therefore will enable both Ambari UI and Blueprints to be used for setting up 
> Kafka broker rack information.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.10.0/configuration/ranger-kafka-audit.xml
>  PRE-CREATION 
>   ambari-server/src/main/resources/common-services/KAFKA/0.10.0/kerberos.json 
> PRE-CREATION 
>   ambari-server/src/main/resources/common-services/KAFKA/0.10.0/metainfo.xml 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/kafka.py
>  1327090aa7 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/params.py
>  c36a10ff28 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/KAFKA/metainfo.xml 
> 12f6c45396 
> 
> 
> Diff: https://reviews.apache.org/r/60249/diff/8/
> 
> 
> Testing
> -------
> 
> Manually deployed Kafka cluster and verified the broker.rack property is 
> correctly populated.
> 
> 
> File Attachments
> ----------------
> 
> trunk
>   
> https://reviews.apache.org/media/uploaded/files/2017/07/13/3828ee0b-0bae-4ebe-ba1d-667e23f8deab__AMBARI-21234-trunk.diff
> 
> 
> Thanks,
> 
> Ambud Sharma
> 
>

Reply via email to