Re: Review Request 48569: On Enabling HS Interactive default queue shown for llap is 'default' queue

[Zhe (Joe) Wang]

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


Ship it!




Ship It!

- Zhe (Joe) Wang


On June 11, 2016, 12:07 a.m., Jaimin Jetly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48569/
> ---
> 
> (Updated June 11, 2016, 12:07 a.m.)
> 
> 
> Review request for Ambari, Zhe (Joe) Wang, Srimanth Gunturi, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-17175
> https://issues.apache.org/jira/browse/AMBARI-17175
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> 1. Deploy ambari secure cluster
> 2. Enable HSI
> Expected: llap queue is created by ambari and is set as default for llap
> Actual: ldap queue is not created and default queue is set for ldap
> 
> 
> Diffs
> -
> 
>   ambari-web/app/views/common/configs/widgets/combo_config_widget_view.js 
> 0bf05f6 
> 
> Diff: https://reviews.apache.org/r/48569/diff/
> 
> 
> Testing
> ---
> 
> Verified that the patch fixes the issue on a cluster
> ambari-web unit tests passes successfully with the patch:
> 28668 tests complete (28 seconds)
> 154 tests pending
> 
> 
> Thanks,
> 
> Jaimin Jetly
> 
>

Review Request 48569: On Enabling HS Interactive default queue shown for llap is 'default' queue

[Jaimin Jetly]

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

Review request for Ambari, Zhe (Joe) Wang, Srimanth Gunturi, and Yusaku Sako.


Bugs: AMBARI-17175
https://issues.apache.org/jira/browse/AMBARI-17175


Repository: ambari


Description
---

1. Deploy ambari secure cluster
2. Enable HSI
Expected: llap queue is created by ambari and is set as default for llap
Actual: ldap queue is not created and default queue is set for ldap


Diffs
-

  ambari-web/app/views/common/configs/widgets/combo_config_widget_view.js 
0bf05f6 

Diff: https://reviews.apache.org/r/48569/diff/


Testing
---

Verified that the patch fixes the issue on a cluster
ambari-web unit tests passes successfully with the patch:
28668 tests complete (28 seconds)
154 tests pending


Thanks,

Jaimin Jetly

Review Request 48568: AMBARI-17176 VDF: include default version definition in list, even if Internet Access is available

[Zhe (Joe) Wang]

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

Review request for Ambari, Jaimin Jetly, Richard Zang, Xi Wang, and Yusaku Sako.


Bugs: AMBARI-17176
https://issues.apache.org/jira/browse/AMBARI-17176


Repository: ambari


Description
---

We need to include the Default Version Definition in the list of dropdown 
Versions along with the discovered versions.
Current experience: we only include Default if we believe we do not have 
internet access
New experience: include Default in the list regardless of internet or not.
This is for backwards compatibility, and in the case where the user "just does 
not know" their version (and therefore, needs Ambari to just figure it out best 
it can).


Diffs
-

  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/stackVersions/StackVersionsCreateCtrl.js
 5433bd6 
  ambari-web/app/controllers/wizard/step1_controller.js 3af28de 
  ambari-web/app/templates/wizard/step1.hbs 59ff21b 

Diff: https://reviews.apache.org/r/48568/diff/


Testing
---

ambari-web:
28670 tests complete (24 seconds)
154 tests pending
ambari-admin:
Executed 71 of 71 SUCCESS (0.142 secs / 0.356 secs)
Manual testing done.


Thanks,

Zhe (Joe) Wang

Re: Review Request 48395: AMBARI-17027: Metrics Collector API: Introduce basic series aggregation functions

[Aravindan Vijayan]

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




ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
 (line 256)


Just throwing out a question here. 

Does it make any difference to do SUM(M1,M2) before or after applying post 
processing (rate/diff)? 

Ideally, these operations should be commutative (Order should not matter). 

Rate of Sum and Sum or Rate should be the same.



ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/AbstractTimelineMetricsSeriesAggregateFunction.java
 (line 73)


When the data is not timestamp aligned, this will lead to "difficult to 
comprehend" graphs.

For example, let's take Sum of Metrics M1,M2,M3 where
M1 - t1 - 5.0
M1 - t2 - 5.0
M2 - t2 - 5.0
M3 - t3 - 5.0

The graph will show up like 
(t1, 5.0) -> (t2,10.0) -> (t3,5.0)

That is why we do some "interpolation" while we aggregate data.


- Aravindan Vijayan


On June 10, 2016, 12:50 a.m., Jungtaek Lim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48395/
> ---
> 
> (Updated June 10, 2016, 12:50 a.m.)
> 
> 
> Review request for Ambari, Aravindan Vijayan, Dmytro Sen, Prajwal Rao, 
> Sriharsha Chintalapani, Sid Wagle, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-17027
> https://issues.apache.org/jira/browse/AMBARI-17027
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> AMS doesn't provide tag so metric is identified by appId, metric name, 
> hostname, instanceId. In this situation metric name is normally consist of 
> origin metric name and tag values, like graphite, but unlike Graphite, AMS 
> also doesn't provide series aggregation functions so aggregation should be 
> done from caller side.
> 
> It would be great if Ambari Metrics Collector provides series aggregation 
> functions, like sumSeries / 
> averageSeries / minSeries / maxSeries on Graphite.
> 
> Query outputs: 
> https://gist.github.com/HeartSaVioR/f4f28b5b8b7bf2e5477e59d7fd56090f
> 
> Attached Grafana screenshots to AMBARI-17027. Please refer 
> https://issues.apache.org/jira/browse/AMBARI-17027 for details.
> 
> 
> Diffs
> -
> 
>   ambari-metrics/ambari-metrics-grafana/ambari-metrics/datasource.js 7390aa8 
>   
> ambari-metrics/ambari-metrics-grafana/ambari-metrics/partials/query.editor.html
>  b034c03 
>   ambari-metrics/ambari-metrics-grafana/ambari-metrics/queryCtrl.js 2eb3613 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/HBaseTimelineMetricStore.java
>  1b2d02f 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  e37bc4d 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStoreWatcher.java
>  7d49070 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/AbstractTimelineMetricsSeriesAggregateFunction.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/SeriesAggregateFunction.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/TimelineMetricsSeriesAggregateFunction.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/TimelineMetricsSeriesAggregateFunctionFactory.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/TimelineMetricsSeriesAvgAggregateFunction.java
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/function/TimelineMetricsSeriesMaxAggregateFunction.java
>  PRE-CREATION 
>   
> 

Re: Review Request 48532: AMBARI-17157 Storm 1.0 log4j config update

[Alejandro Fernandez]

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


Ship it!




Ship It!

- Alejandro Fernandez


On June 10, 2016, 2:45 a.m., Sriharsha Chintalapani wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48532/
> ---
> 
> (Updated June 10, 2016, 2:45 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17157
> https://issues.apache.org/jira/browse/AMBARI-17157
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> AMBARI-17157  Storm 1.0 log4j config update
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-cluster-log4j.xml
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-worker-log4j.xml
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/48532/diff/
> 
> 
> Testing
> ---
> 
> Installed storm 1.0 using Ambari. Tested if the logs are being written in new 
> format.
> 
> 
> Thanks,
> 
> Sriharsha Chintalapani
> 
>

Re: Review Request 48547: AMBARI-17164 Handle Ranger upgrade scenario in Kerberized env

[Srimanth Gunturi]

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


Ship it!




Ship It!

- Srimanth Gunturi


On June 10, 2016, 12:50 p.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48547/
> ---
> 
> (Updated June 10, 2016, 12:50 p.m.)
> 
> 
> Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
> Gunturi, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-17164
> https://issues.apache.org/jira/browse/AMBARI-17164
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Add this property to ranger-admin-site.xml:
> ranger.plugins.{component}.serviceuser=service_user
> 
> Add spnego principal and keytab if cluster is kerberized to below properties:
> ranger.spnego.kerberos.principal
> ranger.spnego.kerberos.keytab
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculation.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-admin-site.xml
>  35910ee 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
>  f40f760 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
> ea5ff5a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
>  7fb03dc 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
> 7f988e3 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> df6c65c 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculationTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/48547/diff/
> 
> 
> Testing
> ---
> 
> Tested upgrade scenario from stack 2.4 to 2.5
> 
> 
> ---
>  T E S T S
> ---
> Picked up _JAVA_OPTIONS: -Xmx2048m -XX:MaxPermSize=512m 
> -Djava.awt.headless=true
> Running 
> org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.586 sec - 
> in 
> org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest
> 
> Results :
> 
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 48561: Falcon to create data-mirroring directory in HDFS if extensions is supported

[Alejandro Fernandez]

> On June 10, 2016, 8:07 p.m., Sowmya Ramesh wrote:
> > ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py,
> >  line 147
> > 
> >
> > I think path before was "/apps/data-mirroring/" and not 
> > "/apps/falcon/data-mirroring/" ?

My mistake, code was correct but comment was not.


- Alejandro


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


On June 10, 2016, 9 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48561/
> ---
> 
> (Updated June 10, 2016, 9 p.m.)
> 
> 
> Review request for Ambari, Di Li, Dmitro Lisnichenko, Jonathan Hurley, Jayush 
> Luniya, Nate Cole, and Tim Thorpe.
> 
> 
> Bugs: AMBARI-17171
> https://issues.apache.org/jira/browse/AMBARI-17171
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If Falcon extensions is supported, Ambari still needs to create the 
> /apps/data-mirroring directory in HDFS.
> Also, RU/EU does not need to explicitly create the extensions directory in 
> the pre_upgrade_restart function since the start function will create it.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
>  b5b3a34 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
>  0d2cd8e 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
>  41954a5 
> 
> Diff: https://reviews.apache.org/r/48561/diff/
> 
> 
> Testing
> ---
> 
> Ran python unit tests,
> 
> Total run:1055
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

Re: Review Request 48561: Falcon to create data-mirroring directory in HDFS if extensions is supported

[Alejandro Fernandez]

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

(Updated June 10, 2016, 9 p.m.)


Review request for Ambari, Di Li, Dmitro Lisnichenko, Jonathan Hurley, Jayush 
Luniya, Nate Cole, and Tim Thorpe.


Bugs: AMBARI-17171
https://issues.apache.org/jira/browse/AMBARI-17171


Repository: ambari


Description (updated)
---

If Falcon extensions is supported, Ambari still needs to create the 
/apps/data-mirroring directory in HDFS.
Also, RU/EU does not need to explicitly create the extensions directory in the 
pre_upgrade_restart function since the start function will create it.


Diffs
-

  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
 b5b3a34 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
 0d2cd8e 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
 41954a5 

Diff: https://reviews.apache.org/r/48561/diff/


Testing
---

Ran python unit tests,

Total run:1055
Total errors:0
Total failures:0
OK


Thanks,

Alejandro Fernandez

Re: Review Request 48561: Falcon to create data-mirroring directory in HDFS if extensions is supported

[Sowmya Ramesh]

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




ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
 (line 147)


I think path before was "/apps/data-mirroring/" and not 
"/apps/falcon/data-mirroring/" ?


- Sowmya Ramesh


On June 10, 2016, 6:13 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48561/
> ---
> 
> (Updated June 10, 2016, 6:13 p.m.)
> 
> 
> Review request for Ambari, Di Li, Dmitro Lisnichenko, Jonathan Hurley, Jayush 
> Luniya, Nate Cole, and Tim Thorpe.
> 
> 
> Bugs: AMBARI-17171
> https://issues.apache.org/jira/browse/AMBARI-17171
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If Falcon extensions is supported, Ambari still needs to create the 
> /apps/falcon/data-mirroring directory in HDFS.
> Also, RU/EU does not need to explicitly create the extensions directory in 
> the pre_upgrade_restart function since the start function will create it.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
>  b5b3a34 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
>  0d2cd8e 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
>  41954a5 
> 
> Diff: https://reviews.apache.org/r/48561/diff/
> 
> 
> Testing
> ---
> 
> Ran python unit tests,
> 
> Total run:1055
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

Re: Review Request 48561: Falcon to create data-mirroring directory in HDFS if extensions is supported

[Tim Thorpe]

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


Ship it!




Ship It!

- Tim Thorpe


On June 10, 2016, 6:13 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48561/
> ---
> 
> (Updated June 10, 2016, 6:13 p.m.)
> 
> 
> Review request for Ambari, Di Li, Dmitro Lisnichenko, Jonathan Hurley, Jayush 
> Luniya, Nate Cole, and Tim Thorpe.
> 
> 
> Bugs: AMBARI-17171
> https://issues.apache.org/jira/browse/AMBARI-17171
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If Falcon extensions is supported, Ambari still needs to create the 
> /apps/falcon/data-mirroring directory in HDFS.
> Also, RU/EU does not need to explicitly create the extensions directory in 
> the pre_upgrade_restart function since the start function will create it.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
>  b5b3a34 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
>  0d2cd8e 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
>  41954a5 
> 
> Diff: https://reviews.apache.org/r/48561/diff/
> 
> 
> Testing
> ---
> 
> Ran python unit tests,
> 
> Total run:1055
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

Re: Review Request 48486: AMBARI-17136: If Solr is down or not ready, then LogFeeder to should retry

[Don Bosco Durai]

> On June 10, 2016, 6:08 p.m., Miklos Gergely wrote:
> >

Good feedback. Let me do this before we commit.


- Don Bosco


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


On June 10, 2016, 7:39 p.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48486/
> ---
> 
> (Updated June 10, 2016, 7:39 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17136
> https://issues.apache.org/jira/browse/AMBARI-17136
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> In addition to IOException, now also considering SolrException also has 
> transient errors. In addition, now not relying on Ping to check whether Solr 
> is up. The reason being, Solr might be up, but the collection/shard might not 
> be available.
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
>  6fb0b0e 
> 
> Diff: https://reviews.apache.org/r/48486/diff/
> 
> 
> Testing
> ---
> 
> Created 3 node hadoop cluster and tested this patch
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Re: Review Request 48486: AMBARI-17136: If Solr is down or not ready, then LogFeeder to should retry

[Don Bosco Durai]

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

(Updated June 10, 2016, 7:39 p.m.)


Review request for Ambari, Oliver Szabo and Sumit Mohanty.


Bugs: AMBARI-17136
https://issues.apache.org/jira/browse/AMBARI-17136


Repository: ambari


Description
---

In addition to IOException, now also considering SolrException also has 
transient errors. In addition, now not relying on Ping to check whether Solr is 
up. The reason being, Solr might be up, but the collection/shard might not be 
available.


Diffs
-

  
ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
 6fb0b0e 

Diff: https://reviews.apache.org/r/48486/diff/


Testing
---

Created 3 node hadoop cluster and tested this patch


Thanks,

Don Bosco Durai

Re: Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment

[Sumit Mohanty]

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


Ship it!




In the context of this issue the fix looks good. As the config it self is an 
excluded config it shoudl be ok to ignore that it is not associated with any 
service type.

- Sumit Mohanty


On June 10, 2016, 7:09 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48553/
> ---
> 
> (Updated June 10, 2016, 7:09 p.m.)
> 
> 
> Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Robert 
> Levas, Sandor Magyari, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17151
> https://issues.apache.org/jira/browse/AMBARI-17151
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-17151. 
> 
> As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing 
> during the configuration resolution phase.  This particular failure will only 
> occur when a user has removed a set of services from the Ambari Stack 
> definitions after the ambari-server install, and a component in the specified 
> Blueprint for this deployment includes an "excluded" configuration type 
> reference to a removed service.
> 
> In the past, the Blueprint processor operated under the assumption that the 
> stacks were static in nature.  This patch allows the Blueprint configuration 
> processor to be more lenient when changes like this are made to the stacks in 
> a custom environment.  
> 
> This patch implements the following:
> 
> 1. Updates the "addExcludedConfigProperties" method in the 
> BlueprintConfigurationProcessor to detect the case where an excluded 
> configuration type exists for a service that the stack definitions do not 
> include.  Currently, this can only occur if custom changes (removal of 
> service(s)) are made to the stack definitions. 
> 2. When this exceptional case is encountered, the 
> BlueprintConfigurationProcessor will now log a message, indicating that no 
> matching service is found for the given excluded configuration type, and that 
> this is likely caused by a change in the stack definitions.  The logged 
> message will probably also be useful in the future to debug errors in new 
> stack definitions. 
> 3. Implements a unit test to verify this change.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  de70a2c 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  9ec0a09 
> 
> Diff: https://reviews.apache.org/r/48553/diff/
> 
> 
> Testing
> ---
> 
> 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster 
> will work properly, even after manually removing the "STORM" service from all 
> stacks in the ambari-server install.  Since Metrics has an excluded 
> configuration reference to Storm, this verifies the original problem. With 
> this patch applied, the cluster deploys properly, without the configuration 
> exception mentioned in the associated bug JIRA. 
> 
> 2. Ran "mvn clean test" with my patch applied to trunk:
> 
> 
> "
> Results :
> 
> Tests in error:
>   AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice 
> pro...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at 
> '/...
>   StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari 
> Stack ...
>   StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari 
> Sta...
> 
> Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34
> "
> 
> Note:  There were 7 errors during this run, but I verified that these 
> failures occur on trunk without my patch applied, so these failures are not 
> caused by this current patch.
> 
> 3. Ran "mvn clean test" with this morning's latest trunk src, with this patch 
> applied, and the full suite passed:
> 
> "Results :
> 
> Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34"
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>

Re: Review Request 48561: Falcon to create data-mirroring directory in HDFS if extensions is supported

[Jonathan Hurley]

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


Fix it, then Ship it!





ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
 (lines 146 - 149)


Instead of executing this under "supports_falcon_extensions" should it be 
under an 

`if not params.supports_data_mirroring:`


- Jonathan Hurley


On June 10, 2016, 2:13 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48561/
> ---
> 
> (Updated June 10, 2016, 2:13 p.m.)
> 
> 
> Review request for Ambari, Di Li, Dmitro Lisnichenko, Jonathan Hurley, Jayush 
> Luniya, Nate Cole, and Tim Thorpe.
> 
> 
> Bugs: AMBARI-17171
> https://issues.apache.org/jira/browse/AMBARI-17171
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If Falcon extensions is supported, Ambari still needs to create the 
> /apps/falcon/data-mirroring directory in HDFS.
> Also, RU/EU does not need to explicitly create the extensions directory in 
> the pre_upgrade_restart function since the start function will create it.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
>  b5b3a34 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
>  0d2cd8e 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
>  41954a5 
> 
> Diff: https://reviews.apache.org/r/48561/diff/
> 
> 
> Testing
> ---
> 
> Ran python unit tests,
> 
> Total run:1055
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

Re: Review Request 48562: Allow option to skip duplicate URL checking when creating VDF

[Nate Cole]

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

(Updated June 10, 2016, 3:14 p.m.)


Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.


Bugs: AMBARI-17173
https://issues.apache.org/jira/browse/AMBARI-17173


Repository: ambari


Description
---

When creating a VDF, it may be desirable to skip duplicate base URL checking. 
This is implemented as a Create Directive.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/api/resources/VersionDefinitionResourceDefinition.java
 30afa69 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProvider.java
 fae279d 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
 c18d722 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
 e0ff2b3 

Diff: https://reviews.apache.org/r/48562/diff/


Testing (updated)
---

Manual.  Automated:

Tests run: 4466, Failures: 0, Errors: 0, Skipped: 34

[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 42:39.911s
[INFO] Finished at: Fri Jun 10 15:09:35 EDT 2016
[INFO] Final Memory: 35M/661M
[INFO] 


Thanks,

Nate Cole

Re: Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment

[Robert Levas]

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


Ship it!




Ship It!

- Robert Levas


On June 10, 2016, 3:09 p.m., Robert Nettleton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48553/
> ---
> 
> (Updated June 10, 2016, 3:09 p.m.)
> 
> 
> Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Robert 
> Levas, Sandor Magyari, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17151
> https://issues.apache.org/jira/browse/AMBARI-17151
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch resolves AMBARI-17151. 
> 
> As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing 
> during the configuration resolution phase.  This particular failure will only 
> occur when a user has removed a set of services from the Ambari Stack 
> definitions after the ambari-server install, and a component in the specified 
> Blueprint for this deployment includes an "excluded" configuration type 
> reference to a removed service.
> 
> In the past, the Blueprint processor operated under the assumption that the 
> stacks were static in nature.  This patch allows the Blueprint configuration 
> processor to be more lenient when changes like this are made to the stacks in 
> a custom environment.  
> 
> This patch implements the following:
> 
> 1. Updates the "addExcludedConfigProperties" method in the 
> BlueprintConfigurationProcessor to detect the case where an excluded 
> configuration type exists for a service that the stack definitions do not 
> include.  Currently, this can only occur if custom changes (removal of 
> service(s)) are made to the stack definitions. 
> 2. When this exceptional case is encountered, the 
> BlueprintConfigurationProcessor will now log a message, indicating that no 
> matching service is found for the given excluded configuration type, and that 
> this is likely caused by a change in the stack definitions.  The logged 
> message will probably also be useful in the future to debug errors in new 
> stack definitions. 
> 3. Implements a unit test to verify this change.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  de70a2c 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  9ec0a09 
> 
> Diff: https://reviews.apache.org/r/48553/diff/
> 
> 
> Testing
> ---
> 
> 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster 
> will work properly, even after manually removing the "STORM" service from all 
> stacks in the ambari-server install.  Since Metrics has an excluded 
> configuration reference to Storm, this verifies the original problem. With 
> this patch applied, the cluster deploys properly, without the configuration 
> exception mentioned in the associated bug JIRA. 
> 
> 2. Ran "mvn clean test" with my patch applied to trunk:
> 
> 
> "
> Results :
> 
> Tests in error:
>   AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice 
> pro...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at 
> '/...
>   StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari 
> Stack ...
>   StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari 
> Sta...
> 
> Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34
> "
> 
> Note:  There were 7 errors during this run, but I verified that these 
> failures occur on trunk without my patch applied, so these failures are not 
> caused by this current patch.
> 
> 3. Ran "mvn clean test" with this morning's latest trunk src, with this patch 
> applied, and the full suite passed:
> 
> "Results :
> 
> Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34"
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>

Re: Review Request 48562: Allow option to skip duplicate URL checking when creating VDF

[Jonathan Hurley]

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


Ship it!




Ship It!

- Jonathan Hurley


On June 10, 2016, 2:26 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48562/
> ---
> 
> (Updated June 10, 2016, 2:26 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-17173
> https://issues.apache.org/jira/browse/AMBARI-17173
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When creating a VDF, it may be desirable to skip duplicate base URL checking. 
> This is implemented as a Create Directive.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/VersionDefinitionResourceDefinition.java
>  30afa69 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProvider.java
>  fae279d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
>  c18d722 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
>  e0ff2b3 
> 
> Diff: https://reviews.apache.org/r/48562/diff/
> 
> 
> Testing
> ---
> 
> Manual.  Automated pending
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 48562: Allow option to skip duplicate URL checking when creating VDF

[Alejandro Fernandez]

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


Ship it!




Ship It!

- Alejandro Fernandez


On June 10, 2016, 6:26 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48562/
> ---
> 
> (Updated June 10, 2016, 6:26 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-17173
> https://issues.apache.org/jira/browse/AMBARI-17173
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When creating a VDF, it may be desirable to skip duplicate base URL checking. 
> This is implemented as a Create Directive.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/VersionDefinitionResourceDefinition.java
>  30afa69 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProvider.java
>  fae279d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
>  c18d722 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
>  e0ff2b3 
> 
> Diff: https://reviews.apache.org/r/48562/diff/
> 
> 
> Testing
> ---
> 
> Manual.  Automated pending
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Review Request 48562: Allow option to skip duplicate URL checking when creating VDF

[Nate Cole]

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

Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.


Bugs: AMBARI-17173
https://issues.apache.org/jira/browse/AMBARI-17173


Repository: ambari


Description
---

When creating a VDF, it may be desirable to skip duplicate base URL checking. 
This is implemented as a Create Directive.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/api/resources/VersionDefinitionResourceDefinition.java
 30afa69 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/RepositoryVersionResourceProvider.java
 fae279d 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProvider.java
 c18d722 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/VersionDefinitionResourceProviderTest.java
 e0ff2b3 

Diff: https://reviews.apache.org/r/48562/diff/


Testing
---

Manual.  Automated pending


Thanks,

Nate Cole

Re: Review Request 48485: AMBARI-17044 Optimize LogSearch Solr for cache setting and default values

[Oliver Szabo]

> On June 9, 2016, 6:14 p.m., Oliver Szabo wrote:
> > ambari-logsearch/ambari-logsearch-portal/src/main/configsets/hadoop_logs/conf/solrconfig.xml.j2,
> >  line 661
> > 
> >
> > can you add these changes to the stack definition too (there are some 
> > solrconfig.xml too)?
> > 
> > or if you want to let this be configurable on ambari I can add it as a 
> > property

yeah, but the files are on ambari-server .j2 files (like: 
https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/properties/service_logs-solrconfig.xml.j2),
 if you dont use these files for anything, then we do not need the files on the 
ambari-logsearch code


- Oliver


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


On June 9, 2016, 10:15 a.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48485/
> ---
> 
> (Updated June 9, 2016, 10:15 a.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17044
> https://issues.apache.org/jira/browse/AMBARI-17044
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Changed default settings to not to wait for cache to be fully build before 
> addressing request
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/audit_logs/conf/solrconfig.xml
>  7af91df 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/audit_logs/conf/solrconfig.xml.j2
>  c0d8b2f 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/hadoop_logs/conf/solrconfig.xml
>  59f778f 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/hadoop_logs/conf/solrconfig.xml.j2
>  0152880 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/history/conf/solrconfig.xml
>  8244a08 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/dao/SolrDaoBase.java
>  147e148 
> 
> Diff: https://reviews.apache.org/r/48485/diff/
> 
> 
> Testing
> ---
> 
> Create 3 node Hadoop cluster and tested the change
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Review Request 48561: Falcon to create data-mirroring directory in HDFS if extensions is supported

[Alejandro Fernandez]

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

Review request for Ambari, Di Li, Dmitro Lisnichenko, Jonathan Hurley, Jayush 
Luniya, Nate Cole, and Tim Thorpe.


Bugs: AMBARI-17171
https://issues.apache.org/jira/browse/AMBARI-17171


Repository: ambari


Description
---

If Falcon extensions is supported, Ambari still needs to create the 
/apps/falcon/data-mirroring directory in HDFS.
Also, RU/EU does not need to explicitly create the extensions directory in the 
pre_upgrade_restart function since the start function will create it.


Diffs
-

  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
 b5b3a34 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon_server.py
 0d2cd8e 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
 41954a5 

Diff: https://reviews.apache.org/r/48561/diff/


Testing
---

Ran python unit tests,

Total run:1055
Total errors:0
Total failures:0
OK


Thanks,

Alejandro Fernandez

Re: Review Request 48405: [Log Search portal ]Date range on comparison tab are different from date range of selected logs for comparison

[Miklos Gergely]

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


Ship it!




Ship It!

- Miklos Gergely


On June 8, 2016, 10:27 a.m., Dharmesh Makwana wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48405/
> ---
> 
> (Updated June 8, 2016, 10:27 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Andrew Onischuk, Don Bosco 
> Durai, Jaimin Jetly, Oliver Szabo, Robert Nettleton, Sandor Magyari, Sumit 
> Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-17110
> https://issues.apache.org/jira/browse/AMBARI-17110
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Dates in comparison tab should be carry forwarded from Service logs tab.
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/webapp/scripts/views/dashboard/MainLayoutView.js
>  5b69650 
>   ambari-logsearch/ambari-logsearch-portal/src/main/webapp/styles/style.css 
> 4837e5f 
> 
> Diff: https://reviews.apache.org/r/48405/diff/
> 
> 
> Testing
> ---
> 
> Setup Logsearch on 1 node cluster and tested the above feature.
> 
> 
> Thanks,
> 
> Dharmesh Makwana
> 
>

Re: Review Request 48486: AMBARI-17136: If Solr is down or not ready, then LogFeeder to should retry

[Miklos Gergely]

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




ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
 (line 305)


What I meant was the java labeling, like this:

mainCycle: while (true)
...
writeCycle: while (!isDrain())
...
continue writeCycle
...
break mainCycle

see https://docs.oracle.com/javase/tutorial/java/nutsandbolts/branch.html


- Miklos Gergely


On June 10, 2016, 5:53 p.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48486/
> ---
> 
> (Updated June 10, 2016, 5:53 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17136
> https://issues.apache.org/jira/browse/AMBARI-17136
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> In addition to IOException, now also considering SolrException also has 
> transient errors. In addition, now not relying on Ping to check whether Solr 
> is up. The reason being, Solr might be up, but the collection/shard might not 
> be available.
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
>  6fb0b0e 
> 
> Diff: https://reviews.apache.org/r/48486/diff/
> 
> 
> Testing
> ---
> 
> Created 3 node hadoop cluster and tested this patch
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Re: Review Request 48549: AMBARI-17165 Handle Java patches execution during Ranger upgrade

[Nate Cole]

> On June 10, 2016, 1:40 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml,
> >  line 889
> > 
> >
> > hosts="all" is the default, you can remove it.
> > sequential="true" isn't needed since it is only useful when two 
> > consecutive tasks need to run one after the other even though they are on 
> > different hosts.
> > 
> > Why is there a stop and start in post-upgrade?
> > What are you trying to achieve here?
> > 
> > Pre-upgrade is any steps to execute before restarting the component, 
> > Post-upgrade is after restarting. So if there are any other stop-start 
> > steps, it means the component is being restarted twice!

I agree with Alejandro here, it looks like you're stopping all admins, 
java-patching only one, then starting them all.  They should all need patching, 
no?  And if that's the case that can all be handled on the python side with 
nothing but restart for the component in the UP.


- Nate


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


On June 10, 2016, 8:47 a.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48549/
> ---
> 
> (Updated June 10, 2016, 8:47 a.m.)
> 
> 
> Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
> Gunturi, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-17165
> https://issues.apache.org/jira/browse/AMBARI-17165
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Revisiting execution of java patches during upgrade for Ranger Service
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  4fd5801 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
>  272a3cc 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> b0cff68 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.4.xml 
> 0b72254 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  111b432 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
>  9365646 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
>  f40f760 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> 712241b 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.4.xml 
> 4187d64 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
> ea5ff5a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
>  e83b54b 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
>  7fb03dc 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.4.xml 
> 4065e87 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
> 7f988e3 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
>  460e6b3 
>   ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml 
> 6ce4c81 
> 
> Diff: https://reviews.apache.org/r/48549/diff/
> 
> 
> Testing
> ---
> 
> Tested Ranger upgrade from stack 2.4 to 2.5
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 48486: AMBARI-17136: If Solr is down or not ready, then LogFeeder to should retry

[Don Bosco Durai]

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

(Updated June 10, 2016, 5:53 p.m.)


Review request for Ambari, Oliver Szabo and Sumit Mohanty.


Changes
---

Aded more comments


Bugs: AMBARI-17136
https://issues.apache.org/jira/browse/AMBARI-17136


Repository: ambari


Description
---

In addition to IOException, now also considering SolrException also has 
transient errors. In addition, now not relying on Ping to check whether Solr is 
up. The reason being, Solr might be up, but the collection/shard might not be 
available.


Diffs (updated)
-

  
ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
 6fb0b0e 

Diff: https://reviews.apache.org/r/48486/diff/


Testing
---

Created 3 node hadoop cluster and tested this patch


Thanks,

Don Bosco Durai

Re: Review Request 48485: AMBARI-17044 Optimize LogSearch Solr for cache setting and default values

[Don Bosco Durai]

> On June 9, 2016, 6:14 p.m., Oliver Szabo wrote:
> >

I think, we don't need this to be configurable. Also, do I need to modify any 
other file other than the .j2? I thought, we were reusing the same files


- Don Bosco


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


On June 9, 2016, 10:15 a.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48485/
> ---
> 
> (Updated June 9, 2016, 10:15 a.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17044
> https://issues.apache.org/jira/browse/AMBARI-17044
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Changed default settings to not to wait for cache to be fully build before 
> addressing request
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/audit_logs/conf/solrconfig.xml
>  7af91df 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/audit_logs/conf/solrconfig.xml.j2
>  c0d8b2f 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/hadoop_logs/conf/solrconfig.xml
>  59f778f 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/hadoop_logs/conf/solrconfig.xml.j2
>  0152880 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/configsets/history/conf/solrconfig.xml
>  8244a08 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/dao/SolrDaoBase.java
>  147e148 
> 
> Diff: https://reviews.apache.org/r/48485/diff/
> 
> 
> Testing
> ---
> 
> Create 3 node Hadoop cluster and tested the change
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Re: Review Request 48557: Fixed implementation of on-ambari-upgrade support. Patch 2: add logic for ambari-upgrade

[Nate Cole]

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



There should be some java tests for this new functionality.

- Nate Cole


On June 10, 2016, 1:10 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48557/
> ---
> 
> (Updated June 10, 2016, 1:10 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, 
> and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17112
> https://issues.apache.org/jira/browse/AMBARI-17112
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Patch implements logic for on-ambari-upgrade attributes: add, update, delete
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/PropertyInfo.java 
> c570ab3 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
>  3ee8bba 
>   
> ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-site.xml
>  6793e4e 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/application-properties.xml
>  fd68ae0 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-startup.properties.xml
>  aacf10a 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-site.xml
>  4e56084 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/core-site.xml
>  7f67b8a 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
>  274163e 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  b0f36e7 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-site.xml
>  444b8b4 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1/configuration/kafka-broker.xml
>  cfdd989 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.9.0/configuration/kafka-broker.xml
>  7f474f6 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.9.0/configuration/ranger-kafka-plugin-properties.xml
>  f3a6bcf 
>   
> ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/ranger-knox-plugin-properties.xml
>  47c900e 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/configuration/oozie-site.xml
>  a309fa4 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.2.0.2.3/configuration/oozie-site.xml
>  2d0047c 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.4.0/configuration/ranger-env.xml
>  5082277 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/admin-properties.xml
>  121a797 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/ranger-env.xml
>  ae56f8b 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/ranger-site.xml
>  4317cfa 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/usersync-properties.xml
>  7eb78e5 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/admin-properties.xml
>  a747dde 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-admin-site.xml
>  35910ee 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-env.xml
>  6eb312f 
>   
> ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-site.xml
>  9870b8b 
>   
> ambari-server/src/main/resources/common-services/SPARK/1.6.0/configuration/spark-defaults.xml
>  633cbda 
>   
> ambari-server/src/main/resources/common-services/SPARK/1.6.0/configuration/spark-thrift-sparkconf.xml
>  daacdee 
>   
> ambari-server/src/main/resources/common-services/STORM/0.10.0/configuration/ranger-storm-plugin-properties.xml
>  21cd096 
>   
> ambari-server/src/main/resources/common-services/STORM/0.10.0/configuration/storm-site.xml
>  a8f1584 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml
>  d7c87e9 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.3/configuration/ranger-storm-plugin-properties.xml
>  7aa18cc 
>   
> ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/ranger-storm-audit.xml
>  fcaecaa 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration-mapred/mapred-site.xml
>  85a1eba 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/capacity-scheduler.xml
>  b4fedd8 
>   
> 

Re: Review Request 48549: AMBARI-17165 Handle Java patches execution during Ranger upgrade

[Alejandro Fernandez]

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




ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
 (line 889)


hosts="all" is the default, you can remove it.
sequential="true" isn't needed since it is only useful when two consecutive 
tasks need to run one after the other even though they are on different hosts.

Why is there a stop and start in post-upgrade?
What are you trying to achieve here?

Pre-upgrade is any steps to execute before restarting the component, 
Post-upgrade is after restarting. So if there are any other stop-start steps, 
it means the component is being restarted twice!


- Alejandro Fernandez


On June 10, 2016, 12:47 p.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48549/
> ---
> 
> (Updated June 10, 2016, 12:47 p.m.)
> 
> 
> Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
> Gunturi, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-17165
> https://issues.apache.org/jira/browse/AMBARI-17165
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Revisiting execution of java patches during upgrade for Ranger Service
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  4fd5801 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
>  272a3cc 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> b0cff68 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.4.xml 
> 0b72254 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  111b432 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
>  9365646 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
>  f40f760 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> 712241b 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.4.xml 
> 4187d64 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
> ea5ff5a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
>  e83b54b 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
>  7fb03dc 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.4.xml 
> 4065e87 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
> 7f988e3 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
>  460e6b3 
>   ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml 
> 6ce4c81 
> 
> Diff: https://reviews.apache.org/r/48549/diff/
> 
> 
> Testing
> ---
> 
> Tested Ranger upgrade from stack 2.4 to 2.5
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Review Request 48557: Fixed implementation of on-ambari-upgrade support. Patch 2: add logic for ambari-upgrade

[Dmitro Lisnichenko]

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

Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, and 
Sumit Mohanty.


Bugs: AMBARI-17112
https://issues.apache.org/jira/browse/AMBARI-17112


Repository: ambari


Description
---

Patch implements logic for on-ambari-upgrade attributes: add, update, delete


Diffs
-

  ambari-server/src/main/java/org/apache/ambari/server/state/PropertyInfo.java 
c570ab3 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
 3ee8bba 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-site.xml
 6793e4e 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/application-properties.xml
 fd68ae0 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-startup.properties.xml
 aacf10a 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-site.xml
 4e56084 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/core-site.xml
 7f67b8a 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
 274163e 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
 b0f36e7 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-site.xml
 444b8b4 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1/configuration/kafka-broker.xml
 cfdd989 
  
ambari-server/src/main/resources/common-services/KAFKA/0.9.0/configuration/kafka-broker.xml
 7f474f6 
  
ambari-server/src/main/resources/common-services/KAFKA/0.9.0/configuration/ranger-kafka-plugin-properties.xml
 f3a6bcf 
  
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/ranger-knox-plugin-properties.xml
 47c900e 
  
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/configuration/oozie-site.xml
 a309fa4 
  
ambari-server/src/main/resources/common-services/OOZIE/4.2.0.2.3/configuration/oozie-site.xml
 2d0047c 
  
ambari-server/src/main/resources/common-services/RANGER/0.4.0/configuration/ranger-env.xml
 5082277 
  
ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/admin-properties.xml
 121a797 
  
ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/ranger-env.xml
 ae56f8b 
  
ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/ranger-site.xml
 4317cfa 
  
ambari-server/src/main/resources/common-services/RANGER/0.5.0/configuration/usersync-properties.xml
 7eb78e5 
  
ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/admin-properties.xml
 a747dde 
  
ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-admin-site.xml
 35910ee 
  
ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-env.xml
 6eb312f 
  
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/configuration/kms-site.xml
 9870b8b 
  
ambari-server/src/main/resources/common-services/SPARK/1.6.0/configuration/spark-defaults.xml
 633cbda 
  
ambari-server/src/main/resources/common-services/SPARK/1.6.0/configuration/spark-thrift-sparkconf.xml
 daacdee 
  
ambari-server/src/main/resources/common-services/STORM/0.10.0/configuration/ranger-storm-plugin-properties.xml
 21cd096 
  
ambari-server/src/main/resources/common-services/STORM/0.10.0/configuration/storm-site.xml
 a8f1584 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1/configuration/storm-site.xml
 d7c87e9 
  
ambari-server/src/main/resources/common-services/STORM/0.9.3/configuration/ranger-storm-plugin-properties.xml
 7aa18cc 
  
ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/ranger-storm-audit.xml
 fcaecaa 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration-mapred/mapred-site.xml
 85a1eba 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/capacity-scheduler.xml
 b4fedd8 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/yarn-site.xml
 b1b30aa 
  ambari-server/src/main/resources/configuration-schema.xsd 6716dd5 
  
ambari-server/src/main/resources/stacks/HDP/2.1/services/HIVE/configuration/hive-site.xml
 8dc02c5 
  
ambari-server/src/main/resources/stacks/HDP/2.1/services/OOZIE/configuration/oozie-site.xml
 7e746c0 
  
ambari-server/src/main/resources/stacks/HDP/2.1/services/YARN/configuration/yarn-site.xml
 463dd6b 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HBASE/configuration/hbase-site.xml
 f92bc1a 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HBASE/configuration/ranger-hbase-plugin-properties.xml
 ca50414 
  

Re: Review Request 48348: AMBARI-17089: HDFS logs not picked by log feeder with umask 0027

[Sebastian Toader]

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


Ship it!




Ship It!

- Sebastian Toader


On June 10, 2016, 5:08 p.m., Oliver Szabo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48348/
> ---
> 
> (Updated June 10, 2016, 5:08 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Don Bosco Durai, Miklos Gergely, 
> Robert Nettleton, Sumit Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-17089
> https://issues.apache.org/jira/browse/AMBARI-17089
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> - Change logfeeder process/files to use sudo user instead of 
> logfeeder/logfeeder user/group (to make sure logfeeder can read any kind of 
> the logs).
> - solr and logsearch user both moved to hadoop group
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
>  73619a3 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
>  2525d9f 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
>  09a86f2 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml
>  0b6e7ab 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-env.xml
>  93cf30d 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
>  56ce721 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-solr-env.xml
>  ff048b4 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logfeeder.py
>  c0689f3 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
>  7acdec2 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py
>  5ca2bd5 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
>  890e8c6 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch_solr.py
>  6e71334 
>   ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py 
> bfd07b2 
>   ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py 
> 981319c 
>   ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py 
> bfe6921 
>   ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_solr.py 0590dca 
>   ambari-server/src/test/python/stacks/2.5/ATLAS/test_atlas_server.py 7127451 
>   ambari-server/src/test/python/stacks/2.5/configs/default.json 1015593 
>   ambari-web/app/data/HDP2/site_properties.js 794da25 
> 
> Diff: https://reviews.apache.org/r/48348/diff/
> 
> 
> Testing
> ---
> 
> FT: tested locally with 4 node cluster with umask 0027.
> 
> 
> Thanks,
> 
> Oliver Szabo
> 
>

Re: Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment

[Robert Nettleton]

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

(Updated June 10, 2016, 3:39 p.m.)


Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Sandor 
Magyari, and Sumit Mohanty.


Bugs: AMBARI-17151
https://issues.apache.org/jira/browse/AMBARI-17151


Repository: ambari


Description
---

This patch resolves AMBARI-17151. 

As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing 
during the configuration resolution phase.  This particular failure will only 
occur when a user has removed a set of services from the Ambari Stack 
definitions after the ambari-server install, and a component in the specified 
Blueprint for this deployment includes an "excluded" configuration type 
reference to a removed service.

In the past, the Blueprint processor operated under the assumption that the 
stacks were static in nature.  This patch allows the Blueprint configuration 
processor to be more lenient when changes like this are made to the stacks in a 
custom environment.  

This patch implements the following:

1. Updates the "addExcludedConfigProperties" method in the 
BlueprintConfigurationProcessor to detect the case where an excluded 
configuration type exists for a service that the stack definitions do not 
include.  Currently, this can only occur if custom changes (removal of 
service(s)) are made to the stack definitions. 
2. When this exceptional case is encountered, the 
BlueprintConfigurationProcessor will now log a message, indicating that no 
matching service is found for the given excluded configuration type, and that 
this is likely caused by a change in the stack definitions.  The logged message 
will probably also be useful in the future to debug errors in new stack 
definitions. 
3. Implements a unit test to verify this change.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
 de70a2c 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
 9ec0a09 

Diff: https://reviews.apache.org/r/48553/diff/


Testing (updated)
---

1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster will 
work properly, even after manually removing the "STORM" service from all stacks 
in the ambari-server install.  Since Metrics has an excluded configuration 
reference to Storm, this verifies the original problem. With this patch 
applied, the cluster deploys properly, without the configuration exception 
mentioned in the associated bug JIRA. 

2. Ran "mvn clean test" with my patch applied to trunk:


"
Results :

Tests in error:
  AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice 
pro...
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
G...
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
G...
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
G...
  StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at 
'/...
  StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari Stack 
...
  StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari 
Sta...

Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34
"

Note:  There were 7 errors during this run, but I verified that these failures 
occur on trunk without my patch applied, so these failures are not caused by 
this current patch.

3. Ran "mvn clean test" with this morning's latest trunk src, with this patch 
applied, and the full suite passed:

"Results :

Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34"


Thanks,

Robert Nettleton

Re: Review Request 48555: Kerberization of a cluster deletes ATS service

[Robert Nettleton]

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


Ship it!




Ship It!

- Robert Nettleton


On June 10, 2016, 2:51 p.m., Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48555/
> ---
> 
> (Updated June 10, 2016, 2:51 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Vitalyi 
> Brodetskyi.
> 
> 
> Bugs: AMBARI-17168
> https://issues.apache.org/jira/browse/AMBARI-17168
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Its likely because APP_TIMELINE_SERVER component (due to AMBARI-17111) become 
> an optional component.
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/metainfo.xml 
> 2c3afb0 
> 
> Diff: https://reviews.apache.org/r/48555/diff/
> 
> 
> Testing
> ---
> 
> Unit tests passed
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

Re: Review Request 48348: AMBARI-17089: HDFS logs not picked by log feeder with umask 0027

[Robert Nettleton]

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


Ship it!




Ship It!

- Robert Nettleton


On June 10, 2016, 3:08 p.m., Oliver Szabo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48348/
> ---
> 
> (Updated June 10, 2016, 3:08 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Don Bosco Durai, Miklos Gergely, 
> Robert Nettleton, Sumit Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-17089
> https://issues.apache.org/jira/browse/AMBARI-17089
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> - Change logfeeder process/files to use sudo user instead of 
> logfeeder/logfeeder user/group (to make sure logfeeder can read any kind of 
> the logs).
> - solr and logsearch user both moved to hadoop group
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
>  73619a3 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
>  2525d9f 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
>  09a86f2 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml
>  0b6e7ab 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-env.xml
>  93cf30d 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
>  56ce721 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-solr-env.xml
>  ff048b4 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logfeeder.py
>  c0689f3 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
>  7acdec2 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py
>  5ca2bd5 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
>  890e8c6 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch_solr.py
>  6e71334 
>   ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py 
> bfd07b2 
>   ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py 
> 981319c 
>   ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py 
> bfe6921 
>   ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_solr.py 0590dca 
>   ambari-server/src/test/python/stacks/2.5/ATLAS/test_atlas_server.py 7127451 
>   ambari-server/src/test/python/stacks/2.5/configs/default.json 1015593 
>   ambari-web/app/data/HDP2/site_properties.js 794da25 
> 
> Diff: https://reviews.apache.org/r/48348/diff/
> 
> 
> Testing
> ---
> 
> FT: tested locally with 4 node cluster with umask 0027.
> 
> 
> Thanks,
> 
> Oliver Szabo
> 
>

Re: Review Request 48414: AMBARI-17118 Incorrect formated external url in ranger configuration - causes Namenode startup failure

[Velmurugan Periasamy]

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


Ship it!




Ship It!

- Velmurugan Periasamy


On June 10, 2016, 1:30 p.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48414/
> ---
> 
> (Updated June 10, 2016, 1:30 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Gautam Borad, Srimanth 
> Gunturi, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-17118
> https://issues.apache.org/jira/browse/AMBARI-17118
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ranger Admin url when configured with trailing slash causes Namenode startup 
> failure
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions.py
>  48ae225 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
>  cfdd6f7 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin.py
>  260f018 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin_xml.py
>  e5faf4b 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
>  05bad1c 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
>  9af87d4 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  fea0635 
>   
> ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/params.py
>  09878ba 
>   
> ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
>  4d30f55 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
>  29ac561 
>   
> ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/kms.py
>  cbe2a31 
>   
> ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/params.py
>  17f71fb 
>   
> ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/params_linux.py
>  978ad92 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
>  29fb3c1 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> 36fe066 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HDFS/configuration/ranger-hdfs-plugin-properties.xml
>  PRE-CREATION 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> df6c65c 
> 
> Diff: https://reviews.apache.org/r/48414/diff/
> 
> 
> Testing
> ---
> 
> Tested Ranger Installation on centos6
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 48490: Last button in the log search pagination panel does not take the user to the last page and few more fixes

[Oliver Szabo]

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




ambari-logsearch/ambari-logsearch-portal/src/main/resources/default.properties 
(line 48)


use logsearch.solr.* prefix here


- Oliver Szabo


On June 9, 2016, 12:51 p.m., Dharmesh Makwana wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48490/
> ---
> 
> (Updated June 9, 2016, 12:51 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Andrew Onischuk, Don Bosco 
> Durai, Jaimin Jetly, Oliver Szabo, Robert Nettleton, Sandor Magyari, Sumit 
> Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-17140
> https://issues.apache.org/jira/browse/AMBARI-17140
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Patch contains
> 1) Last button in the log search pagination panel does not take the user to 
> the last page.
> 2) Solr warming feature added.
> 3) Suffix in columns mapping issue fixed.
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/common/LogSearchConstants.java
>  917956f 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/dao/SolrDaoBase.java
>  147e148 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/manager/AuditMgr.java
>  53e386e 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/manager/LogsMgr.java
>  ca63671 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/manager/MgrBase.java
>  1d069d3 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/manager/UserConfigMgr.java
>  3b23f2a 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/query/QueryGeneration.java
>  4647c7b 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/rest/AuditREST.java
>  92bfb01 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/rest/DashboardREST.java
>  1e107ed 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/util/ConfigUtil.java
>  44d184d 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/view/VUserConfig.java
>  55ec1c0 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/resources/default.properties
>  25b4f1a 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/webapp/META-INF/applicationContext.xml
>  6a73d60 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/webapp/scripts/collections/BaseCollection.js
>  24b6974 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/webapp/scripts/utils/Intro.js
>  869a1d4 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/webapp/scripts/views/audit/AuditTabLayoutView.js
>  5f93c5a 
>   
> ambari-logsearch/ambari-logsearch-portal/src/main/webapp/scripts/views/dialog/ApplySearchFilterView.js
>  4babebc 
> 
> Diff: https://reviews.apache.org/r/48490/diff/
> 
> 
> Testing
> ---
> 
> Setup Logsearch on 2 node cluster and tested the above feature.
> 
> 
> Thanks,
> 
> Dharmesh Makwana
> 
>

Re: Review Request 48547: AMBARI-17164 Handle Ranger upgrade scenario in Kerberized env

[Velmurugan Periasamy]

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


Ship it!




Ship It!

- Velmurugan Periasamy


On June 10, 2016, 12:50 p.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48547/
> ---
> 
> (Updated June 10, 2016, 12:50 p.m.)
> 
> 
> Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
> Gunturi, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-17164
> https://issues.apache.org/jira/browse/AMBARI-17164
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Add this property to ranger-admin-site.xml:
> ranger.plugins.{component}.serviceuser=service_user
> 
> Add spnego principal and keytab if cluster is kerberized to below properties:
> ranger.spnego.kerberos.principal
> ranger.spnego.kerberos.keytab
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculation.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-admin-site.xml
>  35910ee 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
>  f40f760 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
> ea5ff5a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
>  7fb03dc 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
> 7f988e3 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> df6c65c 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculationTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/48547/diff/
> 
> 
> Testing
> ---
> 
> Tested upgrade scenario from stack 2.4 to 2.5
> 
> 
> ---
>  T E S T S
> ---
> Picked up _JAVA_OPTIONS: -Xmx2048m -XX:MaxPermSize=512m 
> -Djava.awt.headless=true
> Running 
> org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.586 sec - 
> in 
> org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest
> 
> Results :
> 
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 48549: AMBARI-17165 Handle Java patches execution during Ranger upgrade

[Velmurugan Periasamy]

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


Ship it!




Ship It!

- Velmurugan Periasamy


On June 10, 2016, 12:47 p.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48549/
> ---
> 
> (Updated June 10, 2016, 12:47 p.m.)
> 
> 
> Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
> Gunturi, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-17165
> https://issues.apache.org/jira/browse/AMBARI-17165
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Revisiting execution of java patches during upgrade for Ranger Service
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
>  4fd5801 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
>  272a3cc 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> b0cff68 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.4.xml 
> 0b72254 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
>  111b432 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
>  9365646 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
>  f40f760 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> 712241b 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.4.xml 
> 4187d64 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
> ea5ff5a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
>  e83b54b 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
>  7fb03dc 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.4.xml 
> 4065e87 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
> 7f988e3 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
>  460e6b3 
>   ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml 
> 6ce4c81 
> 
> Diff: https://reviews.apache.org/r/48549/diff/
> 
> 
> Testing
> ---
> 
> Tested Ranger upgrade from stack 2.4 to 2.5
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 48348: AMBARI-17089: HDFS logs not picked by log feeder with umask 0027

[Oliver Szabo]

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

(Updated June 10, 2016, 3:08 p.m.)


Review request for Ambari, Andrew Onischuk, Don Bosco Durai, Miklos Gergely, 
Robert Nettleton, Sumit Mohanty, and Sebastian Toader.


Changes
---

remove hard-coded logfeeder user


Bugs: AMBARI-17089
https://issues.apache.org/jira/browse/AMBARI-17089


Repository: ambari


Description
---

- Change logfeeder process/files to use sudo user instead of 
logfeeder/logfeeder user/group (to make sure logfeeder can read any kind of the 
logs).
- solr and logsearch user both moved to hadoop group


Diffs (updated)
-

  
ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
 73619a3 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
 2525d9f 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
 09a86f2 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml
 0b6e7ab 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-env.xml
 93cf30d 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
 56ce721 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-solr-env.xml
 ff048b4 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logfeeder.py
 c0689f3 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
 7acdec2 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py
 5ca2bd5 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
 890e8c6 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch_solr.py
 6e71334 
  ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py 
bfd07b2 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py 981319c 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py bfe6921 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_solr.py 0590dca 
  ambari-server/src/test/python/stacks/2.5/ATLAS/test_atlas_server.py 7127451 
  ambari-server/src/test/python/stacks/2.5/configs/default.json 1015593 
  ambari-web/app/data/HDP2/site_properties.js 794da25 

Diff: https://reviews.apache.org/r/48348/diff/


Testing
---

FT: tested locally with 4 node cluster with umask 0027.


Thanks,

Oliver Szabo

Re: Review Request 48348: AMBARI-17089: HDFS logs not picked by log feeder with umask 0027

[Oliver Szabo]

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

(Updated June 10, 2016, 3 p.m.)


Review request for Ambari, Andrew Onischuk, Don Bosco Durai, Miklos Gergely, 
Robert Nettleton, Sumit Mohanty, and Sebastian Toader.


Changes
---

- add logfeeder user to ambari-agent group
- the same with ambari-server is not that obvious, so that one will be 
continued in AMBARI-17170


Bugs: AMBARI-17089
https://issues.apache.org/jira/browse/AMBARI-17089


Repository: ambari


Description
---

- Change logfeeder process/files to use sudo user instead of 
logfeeder/logfeeder user/group (to make sure logfeeder can read any kind of the 
logs).
- solr and logsearch user both moved to hadoop group


Diffs (updated)
-

  
ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
 73619a3 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
 2525d9f 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
 09a86f2 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-env.xml
 0b6e7ab 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-env.xml
 93cf30d 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
 56ce721 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-solr-env.xml
 ff048b4 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logfeeder.py
 c0689f3 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
 7acdec2 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py
 5ca2bd5 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
 890e8c6 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch_solr.py
 6e71334 
  ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py 
bfd07b2 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py 981319c 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logsearch.py bfe6921 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_solr.py 0590dca 
  ambari-server/src/test/python/stacks/2.5/ATLAS/test_atlas_server.py 7127451 
  ambari-server/src/test/python/stacks/2.5/configs/default.json 1015593 
  ambari-web/app/data/HDP2/site_properties.js 794da25 

Diff: https://reviews.apache.org/r/48348/diff/


Testing
---

FT: tested locally with 4 node cluster with umask 0027.


Thanks,

Oliver Szabo

Re: Review Request 48555: Kerberization of a cluster deletes ATS service

[Sumit Mohanty]

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


Ship it!




Ship It!

- Sumit Mohanty


On June 10, 2016, 2:51 p.m., Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48555/
> ---
> 
> (Updated June 10, 2016, 2:51 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Vitalyi 
> Brodetskyi.
> 
> 
> Bugs: AMBARI-17168
> https://issues.apache.org/jira/browse/AMBARI-17168
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Its likely because APP_TIMELINE_SERVER component (due to AMBARI-17111) become 
> an optional component.
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/metainfo.xml 
> 2c3afb0 
> 
> Diff: https://reviews.apache.org/r/48555/diff/
> 
> 
> Testing
> ---
> 
> Unit tests passed
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

Review Request 48555: Kerberization of a cluster deletes ATS service

[Dmytro Sen]

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

Review request for Ambari, Andrew Onischuk, Dmitro Lisnichenko, and Vitalyi 
Brodetskyi.


Bugs: AMBARI-17168
https://issues.apache.org/jira/browse/AMBARI-17168


Repository: ambari


Description
---

Its likely because APP_TIMELINE_SERVER component (due to AMBARI-17111) become 
an optional component.


Diffs
-

  ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/metainfo.xml 
2c3afb0 

Diff: https://reviews.apache.org/r/48555/diff/


Testing
---

Unit tests passed


Thanks,

Dmytro Sen

Re: Review Request 48480: View Config- views created for 2nd remote cluster points to 1st remote cluster

[Nitiraj Rathore]

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


Ship it!




Ship It!

- Nitiraj Rathore


On June 9, 2016, 8:43 a.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48480/
> ---
> 
> (Updated June 9, 2016, 8:43 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Nitiraj Rathore, Pallav 
> Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-17139
> https://issues.apache.org/jira/browse/AMBARI-17139
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Change the remoteClusterMap to clusterId from remote ambari cluster name.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariClusterRegistry.java
>  c0c887f 
> 
> Diff: https://reviews.apache.org/r/48480/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> Gaurav Nagar
> 
>

Review Request 48553: Blueprint processor should handle manual stack definition changes without failing deployment

[Robert Nettleton]

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

Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Sandor 
Magyari, and Sumit Mohanty.


Bugs: AMBARI-17151
https://issues.apache.org/jira/browse/AMBARI-17151


Repository: ambari


Description
---

This patch resolves AMBARI-17151. 

As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing 
during the configuration resolution phase.  This particular failure will only 
occur when a user has removed a set of services from the Ambari Stack 
definitions after the ambari-server install, and a component in the specified 
Blueprint for this deployment includes an "excluded" configuration type 
reference to a removed service.

In the past, the Blueprint processor operated under the assumption that the 
stacks were static in nature.  This patch allows the Blueprint configuration 
processor to be more lenient when changes like this are made to the stacks in a 
custom environment.  

This patch implements the following:

1. Updates the "addExcludedConfigProperties" method in the 
BlueprintConfigurationProcessor to detect the case where an excluded 
configuration type exists for a service that the stack definitions do not 
include.  Currently, this can only occur if custom changes (removal of 
service(s)) are made to the stack definitions. 
2. When this exceptional case is encountered, the 
BlueprintConfigurationProcessor will now log a message, indicating that no 
matching service is found for the given excluded configuration type, and that 
this is likely caused by a change in the stack definitions.  The logged message 
will probably also be useful in the future to debug errors in new stack 
definitions. 
3. Implements a unit test to verify this change.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
 de70a2c 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
 9ec0a09 

Diff: https://reviews.apache.org/r/48553/diff/


Testing
---

1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster will 
work properly, even after manually removing the "STORM" service from all stacks 
in the ambari-server install.  Since Metrics has an excluded configuration 
reference to Storm, this verifies the original problem. With this patch 
applied, the cluster deploys properly, without the configuration exception 
mentioned in the associated bug JIRA. 

2. Ran "mvn clean test" with my patch applied to trunk:


"
Results :

Tests in error:
  AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice 
pro...
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
G...
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
G...
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
G...
  StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at 
'/...
  StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari Stack 
...
  StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari 
Sta...

Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34
"

Note:  There were 7 errors during this run, but I verified that these failures 
occur on trunk without my patch applied, so these failures are not caused by 
this current patch.


Thanks,

Robert Nettleton

Re: Review Request 48414: AMBARI-17118 Incorrect formated external url in ranger configuration - causes Namenode startup failure

[Mugdha Varadkar]

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

(Updated June 10, 2016, 1:30 p.m.)


Review request for Ambari, Alejandro Fernandez, Gautam Borad, Srimanth Gunturi, 
and Velmurugan Periasamy.


Bugs: AMBARI-17118
https://issues.apache.org/jira/browse/AMBARI-17118


Repository: ambari


Description
---

Ranger Admin url when configured with trailing slash causes Namenode startup 
failure


Diffs (updated)
-

  
ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions.py
 48ae225 
  
ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
 cfdd6f7 
  
ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin.py
 260f018 
  
ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin_xml.py
 e5faf4b 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
 05bad1c 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
 9af87d4 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 fea0635 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/params.py
 09878ba 
  
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
 4d30f55 
  
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
 29ac561 
  
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/kms.py
 cbe2a31 
  
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/params.py
 17f71fb 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/params_linux.py
 978ad92 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
 29fb3c1 
  ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
36fe066 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HDFS/configuration/ranger-hdfs-plugin-properties.xml
 PRE-CREATION 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
df6c65c 

Diff: https://reviews.apache.org/r/48414/diff/


Testing
---

Tested Ranger Installation on centos6


Thanks,

Mugdha Varadkar

Re: Review Request 48486: AMBARI-17136: If Solr is down or not ready, then LogFeeder to should retry

[Miklos Gergely]

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




ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
 (line 303)


Having two cycles, and having a break and a continue command in this 
function the cycles should be labeled for better readability.


- Miklos Gergely


On June 9, 2016, 10:47 a.m., Don Bosco Durai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48486/
> ---
> 
> (Updated June 9, 2016, 10:47 a.m.)
> 
> 
> Review request for Ambari, Oliver Szabo and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17136
> https://issues.apache.org/jira/browse/AMBARI-17136
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> In addition to IOException, now also considering SolrException also has 
> transient errors. In addition, now not relying on Ping to check whether Solr 
> is up. The reason being, Solr might be up, but the collection/shard might not 
> be available.
> 
> 
> Diffs
> -
> 
>   
> ambari-logsearch/ambari-logsearch-logfeeder/src/main/java/org/apache/ambari/logfeeder/output/OutputSolr.java
>  6fb0b0e 
> 
> Diff: https://reviews.apache.org/r/48486/diff/
> 
> 
> Testing
> ---
> 
> Created 3 node hadoop cluster and tested this patch
> 
> 
> Thanks,
> 
> Don Bosco Durai
> 
>

Re: Review Request 48547: AMBARI-17164 Handle Ranger upgrade scenario in Kerberized env

[Mugdha Varadkar]

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

(Updated June 10, 2016, 12:50 p.m.)


Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
Gunturi, and Velmurugan Periasamy.


Summary (updated)
-

AMBARI-17164 Handle Ranger upgrade scenario in Kerberized env


Bugs: AMBARI-17164
https://issues.apache.org/jira/browse/AMBARI-17164


Repository: ambari


Description
---

Add this property to ranger-admin-site.xml:
ranger.plugins.{component}.serviceuser=service_user

Add spnego principal and keytab if cluster is kerberized to below properties:
ranger.spnego.kerberos.principal
ranger.spnego.kerberos.keytab


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculation.java
 PRE-CREATION 
  
ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-admin-site.xml
 35910ee 
  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
 f40f760 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
ea5ff5a 
  
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
 7fb03dc 
  ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
7f988e3 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
df6c65c 
  
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculationTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/48547/diff/


Testing
---

Tested upgrade scenario from stack 2.4 to 2.5


---
 T E S T S
---
Picked up _JAVA_OPTIONS: -Xmx2048m -XX:MaxPermSize=512m -Djava.awt.headless=true
Running 
org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.586 sec - in 
org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0


Thanks,

Mugdha Varadkar

Review Request 48549: AMBARI-17165 Handle Java patches execution during Ranger upgrade

[Mugdha Varadkar]

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

Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
Gunturi, and Velmurugan Periasamy.


Bugs: AMBARI-17165
https://issues.apache.org/jira/browse/AMBARI-17165


Repository: ambari


Description
---

Revisiting execution of java patches during upgrade for Ranger Service


Diffs
-

  
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.3.xml
 4fd5801 
  
ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.4.xml
 272a3cc 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
b0cff68 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.4.xml 
0b72254 
  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.3.xml
 111b432 
  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.4.xml
 9365646 
  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
 f40f760 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
712241b 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.4.xml 
4187d64 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
ea5ff5a 
  
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.4.xml
 e83b54b 
  
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
 7fb03dc 
  ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.4.xml 
4065e87 
  ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
7f988e3 
  
ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/nonrolling-upgrade-2.5.xml
 460e6b3 
  ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/upgrade-2.5.xml 
6ce4c81 

Diff: https://reviews.apache.org/r/48549/diff/


Testing
---

Tested Ranger upgrade from stack 2.4 to 2.5


Thanks,

Mugdha Varadkar

Review Request 48547: Handle Ranger upgrade scenario in Kerberized env

[Mugdha Varadkar]

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

Review request for Ambari, Gautam Borad, Jonathan Hurley, Nate Cole, Srimanth 
Gunturi, and Velmurugan Periasamy.


Bugs: AMBARI-17164
https://issues.apache.org/jira/browse/AMBARI-17164


Repository: ambari


Description
---

Add this property to ranger-admin-site.xml:
ranger.plugins.{component}.serviceuser=service_user

Add spnego principal and keytab if cluster is kerberized to below properties:
ranger.spnego.kerberos.principal
ranger.spnego.kerberos.keytab


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculation.java
 PRE-CREATION 
  
ambari-server/src/main/resources/common-services/RANGER/0.6.0/configuration/ranger-admin-site.xml
 35910ee 
  
ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
 f40f760 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
ea5ff5a 
  
ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
 7fb03dc 
  ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
7f988e3 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
df6c65c 
  
ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/RangerKerberosConfigCalculationTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/48547/diff/


Testing
---

Tested upgrade scenario from stack 2.4 to 2.5


---
 T E S T S
---
Picked up _JAVA_OPTIONS: -Xmx2048m -XX:MaxPermSize=512m -Djava.awt.headless=true
Running 
org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.586 sec - in 
org.apache.ambari.server.serveraction.upgrades.RangerKerberosConfigCalculationTest

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0


Thanks,

Mugdha Varadkar

Re: Review Request 48404: Add user home directory verification as part of Service Check

[Pallav Kulshreshtha]

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

(Updated June 10, 2016, 12:39 p.m.)


Review request for Ambari, DIPAYAN BHOWMICK, Gaurav Nagar, Nitiraj Rathore, and 
Rohit Choudhary.


Bugs: AMBARI-17113
https://issues.apache.org/jira/browse/AMBARI-17113


Repository: ambari


Description
---

- Leaverage the UserService of common to check the user's home directory.
- Changed few labels


Diffs (updated)
-

  contrib/views/files/src/main/resources/ui/app/templates/splash.hbs 4a45366 
  contrib/views/hive/pom.xml 1c92f74 
  contrib/views/hive/src/main/java/org/apache/ambari/view/hive/HelpService.java 
3a7f823 
  
contrib/views/hive/src/main/java/org/apache/ambari/view/hive/resources/files/FileService.java
 ab2b933 
  contrib/views/hive/src/main/resources/ui/hive-web/app/controllers/splash.js 
5db93f7 
  contrib/views/hive/src/main/resources/ui/hive-web/app/routes/splash.js 
05bcbcf 
  contrib/views/hive/src/main/resources/ui/hive-web/app/templates/splash.hbs 
84c7a71 
  contrib/views/pig/pom.xml 36fb59e 
  
contrib/views/pig/src/main/java/org/apache/ambari/view/pig/resources/files/FileService.java
 40bc9a7 
  
contrib/views/pig/src/main/java/org/apache/ambari/view/pig/services/HelpService.java
 eb363a0 
  contrib/views/pig/src/main/resources/ui/pig-web/app/controllers/splash.js 
f58d437 
  contrib/views/pig/src/main/resources/ui/pig-web/app/routes/splash.js 1d848e3 
  contrib/views/pig/src/main/resources/ui/pig-web/app/templates/splash.hbs 
d635a91 
  contrib/views/pig/src/main/resources/ui/pig-web/app/translations.js 072b5c7 

Diff: https://reviews.apache.org/r/48404/diff/


Testing
---

manually tested


Thanks,

Pallav Kulshreshtha

Re: Review Request 48516: SPNEGO keytab and principal configuration for HBase web UIs

[Robert Levas]

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


Ship it!




Ship It!

- Robert Levas


On June 9, 2016, 7 p.m., Josh Elser wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48516/
> ---
> 
> (Updated June 9, 2016, 7 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Robert Levas.
> 
> 
> Bugs: AMBARI-17129
> https://issues.apache.org/jira/browse/AMBARI-17129
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adds the SPNEGO principal and keytab to hbase-site.xml to make it simple for 
> users to enable SPNEGO authentication for HBase web UIs
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  5016325 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/alerts.json 
> 50a7ceb 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json 
> 8be8bda 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  c221138 
> 
> Diff: https://reviews.apache.org/r/48516/diff/
> 
> 
> Testing
> ---
> 
> Java unit tests and a simple virtual-machine installation of 2.4.0. Verified 
> that expected configuration properties are present.
> 
> 
> Thanks,
> 
> Josh Elser
> 
>

Review Request 48545: View config- Allows remote cluster creation using a user having no permissions on the cluster

[Gaurav Nagar]

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

Review request for Ambari, DIPAYAN BHOWMICK, Nitiraj Rathore, Pallav 
Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.


Bugs: AMBARI-17162
https://issues.apache.org/jira/browse/AMBARI-17162


Repository: ambari


Description
---

Added permission check for user (ambari/cluster admin) before save/update of 
remote cluster.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariCluster.java
 1135424 
  
ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariClusterRegistry.java
 c0c887f 
  ambari-server/src/main/java/org/apache/ambari/server/view/ViewRegistry.java 
90144e2 
  
ambari-server/src/test/java/org/apache/ambari/server/view/RemoteAmbariClusterTest.java
 2b6e014 

Diff: https://reviews.apache.org/r/48545/diff/


Testing
---

Manually Tested


Thanks,

Gaurav Nagar

Re: Review Request 48546: Wildcards shouldn't be used for package installation

[Dmitro Lisnichenko]

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


Ship it!




Ship It!

- Dmitro Lisnichenko


On June 10, 2016, 3:13 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48546/
> ---
> 
> (Updated June 10, 2016, 3:13 p.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-17163
> https://issues.apache.org/jira/browse/AMBARI-17163
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
>  line 112, in 
> Supervisor().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 257, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
>  line 43, in install
> self.configure(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
>  line 48, in configure
> storm("supervisor")
>   File 
> "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", line 89, 
> in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/storm.py",
>  line 76, in storm
> cd_access="a",
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 
> 155, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 185, in action_create
> sudo.makedirs(path, self.resource.mode or 0755)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/sudo.py", line 
> 174, in makedirs
> shell.checked_call(["mkdir", "-p", path], sudo=True)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 70, in inner
> result = function(command, **kwargs)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 92, in checked_call
> tries=tries, try_sleep=try_sleep)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 
> 293, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'mkdir -p 
> /usr/hdp/current/storm-supervisor/conf' returned 1. mkdir: cannot create 
> directory `/usr/hdp/current/storm-supervisor': File exists
> 
> 
> **Reason:**  
> The problem happens because we install packages with *  
> Which causes a skip for storm-* because storm-*-slider is installed
> 
> 
> 
> 2016-06-09 10:10:43,490 - Package['storm_2_5_0_0_*'] 
> {'retry_on_repo_unavailability': False, 'retry_count': 5}
> 2016-06-09 10:10:43,864 - Skipping installation of existing package 
> storm_2_5_0_0_*
> 
> 
> 
> # rpm -qa | grep storm
> storm_2_5_0_0_688-slider-client-1.0.1.2.5.0.0-688.el6.x86_6
> 
> 
> **Solution**:  
> RE should do the change in manifests. To not propagate wildcards in package-
> version.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/script/script.py 
> d11fb13 
> 
> Diff: https://reviews.apache.org/r/48546/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

Re: Review Request 48546: Wildcards shouldn't be used for package installation

[Andrew Onischuk]

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

(Updated June 10, 2016, 12:13 p.m.)


Review request for Ambari and Dmitro Lisnichenko.


Summary (updated)
-

Wildcards shouldn't be used for package installation


Bugs: AMBARI-17163
https://issues.apache.org/jira/browse/AMBARI-17163


Repository: ambari


Description
---

Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
 line 112, in 
Supervisor().execute()
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 257, in execute
method(env)
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
 line 43, in install
self.configure(env)
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
 line 48, in configure
storm("supervisor")
  File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
line 89, in thunk
return fn(*args, **kwargs)
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/storm.py",
 line 76, in storm
cd_access="a",
  File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
line 155, in __init__
self.env.run()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
 line 185, in action_create
sudo.makedirs(path, self.resource.mode or 0755)
  File "/usr/lib/python2.6/site-packages/resource_management/core/sudo.py", 
line 174, in makedirs
shell.checked_call(["mkdir", "-p", path], sudo=True)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 70, 
in inner
result = function(command, **kwargs)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 92, 
in checked_call
tries=tries, try_sleep=try_sleep)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 140, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 293, 
in _call
raise Fail(err_msg)
resource_management.core.exceptions.Fail: Execution of 'mkdir -p 
/usr/hdp/current/storm-supervisor/conf' returned 1. mkdir: cannot create 
directory `/usr/hdp/current/storm-supervisor': File exists


**Reason:**  
The problem happens because we install packages with *  
Which causes a skip for storm-* because storm-*-slider is installed



2016-06-09 10:10:43,490 - Package['storm_2_5_0_0_*'] 
{'retry_on_repo_unavailability': False, 'retry_count': 5}
2016-06-09 10:10:43,864 - Skipping installation of existing package 
storm_2_5_0_0_*



# rpm -qa | grep storm
storm_2_5_0_0_688-slider-client-1.0.1.2.5.0.0-688.el6.x86_6


**Solution**:  
RE should do the change in manifests. To not propagate wildcards in package-
version.


Diffs
-

  ambari-common/src/main/python/resource_management/libraries/script/script.py 
d11fb13 

Diff: https://reviews.apache.org/r/48546/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Review Request 48546: Xml manifests should not include wildcards but full versions for package-version

[Andrew Onischuk]

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

Review request for Ambari and Dmitro Lisnichenko.


Bugs: AMBARI-17163
https://issues.apache.org/jira/browse/AMBARI-17163


Repository: ambari


Description
---

Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
 line 112, in 
Supervisor().execute()
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 257, in execute
method(env)
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
 line 43, in install
self.configure(env)
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/supervisor.py",
 line 48, in configure
storm("supervisor")
  File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
line 89, in thunk
return fn(*args, **kwargs)
  File 
"/var/lib/ambari-agent/cache/common-services/STORM/0.9.1/package/scripts/storm.py",
 line 76, in storm
cd_access="a",
  File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
line 155, in __init__
self.env.run()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
 line 185, in action_create
sudo.makedirs(path, self.resource.mode or 0755)
  File "/usr/lib/python2.6/site-packages/resource_management/core/sudo.py", 
line 174, in makedirs
shell.checked_call(["mkdir", "-p", path], sudo=True)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 70, 
in inner
result = function(command, **kwargs)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 92, 
in checked_call
tries=tries, try_sleep=try_sleep)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 140, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File 
"/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 293, 
in _call
raise Fail(err_msg)
resource_management.core.exceptions.Fail: Execution of 'mkdir -p 
/usr/hdp/current/storm-supervisor/conf' returned 1. mkdir: cannot create 
directory `/usr/hdp/current/storm-supervisor': File exists


**Reason:**  
The problem happens because we install packages with *  
Which causes a skip for storm-* because storm-*-slider is installed



2016-06-09 10:10:43,490 - Package['storm_2_5_0_0_*'] 
{'retry_on_repo_unavailability': False, 'retry_count': 5}
2016-06-09 10:10:43,864 - Skipping installation of existing package 
storm_2_5_0_0_*



# rpm -qa | grep storm
storm_2_5_0_0_688-slider-client-1.0.1.2.5.0.0-688.el6.x86_6


**Solution**:  
RE should do the change in manifests. To not propagate wildcards in package-
version.


Diffs
-

  ambari-common/src/main/python/resource_management/libraries/script/script.py 
d11fb13 

Diff: https://reviews.apache.org/r/48546/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Re: Review Request 48516: SPNEGO keytab and principal configuration for HBase web UIs

[Nate Cole]

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


Ship it!




Ship It!

- Nate Cole


On June 9, 2016, 7 p.m., Josh Elser wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48516/
> ---
> 
> (Updated June 9, 2016, 7 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Robert Levas.
> 
> 
> Bugs: AMBARI-17129
> https://issues.apache.org/jira/browse/AMBARI-17129
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Adds the SPNEGO principal and keytab to hbase-site.xml to make it simple for 
> users to enable SPNEGO authentication for HBase web UIs
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  5016325 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/alerts.json 
> 50a7ceb 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/services/HBASE/kerberos.json 
> 8be8bda 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  c221138 
> 
> Diff: https://reviews.apache.org/r/48516/diff/
> 
> 
> Testing
> ---
> 
> Java unit tests and a simple virtual-machine installation of 2.4.0. Verified 
> that expected configuration properties are present.
> 
> 
> Thanks,
> 
> Josh Elser
> 
>

Re: Review Request 48398: Capacity scheduler view - problem with queue percent rounding

[Sreenath Somarajapuram]

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


Ship it!




Ship It!

- Sreenath Somarajapuram


On June 10, 2016, 9:58 a.m., Akhil PB wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48398/
> ---
> 
> (Updated June 10, 2016, 9:58 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Pallav Kulshreshtha, and 
> Sreenath Somarajapuram.
> 
> 
> Bugs: AMBARI-17109
> https://issues.apache.org/jira/browse/AMBARI-17109
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Capacity scheduler view - problem with queue percent rounding
> 
> 
> Diffs
> -
> 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/components/totalCapacity.js
>  c36839c 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queues.js
>  4aeb442 
> 
> Diff: https://reviews.apache.org/r/48398/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Akhil PB
> 
>

Review Request 48540: Ubuntu 16, Hive Metastore Start failed

[Andrew Onischuk]

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

Review request for Ambari and Myroslav Papirkovskyy.


Bugs: AMBARI-17161
https://issues.apache.org/jira/browse/AMBARI-17161


Repository: ambari


Description
---

/var/lib/ambari-agent/tmp/addMysqlUser.sh didn't add mysql user.



+ echo 'Adding user hive@% and removing users with empty name'
Adding user hive@% and removing users with empty name
+ /var/lib/ambari-agent/ambari-sudo.sh su mysql -s /bin/bash - -c 'mysql -u 
root -e "CREATE USER '\''hive'\''@'\''%'\'' IDENTIFIED BY '\''h'\'';"'
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
+ /var/lib/ambari-agent/ambari-sudo.sh su mysql -s /bin/bash - -c 'mysql -u 
root -e "GRANT ALL PRIVILEGES ON *.* TO '\''hive'\''@'\''%'\'';"'
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
+ /var/lib/ambari-agent/ambari-sudo.sh su mysql -s /bin/bash - -c 'mysql -u 
root -e "DELETE FROM mysql.user WHERE user='\'''\'';"'
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
+ /var/lib/ambari-agent/ambari-sudo.sh su mysql -s /bin/bash - -c 'mysql -u 
root -e "flush privileges;"'
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
+ /var/lib/ambari-agent/ambari-sudo.sh service mysql stop


Diffs
-

  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/files/addMysqlUser.sh
 36ed58f 

Diff: https://reviews.apache.org/r/48540/diff/


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Re: Review Request 48398: Capacity scheduler view - problem with queue percent rounding

[Akhil PB]

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

(Updated June 10, 2016, 9:58 a.m.)


Review request for Ambari, DIPAYAN BHOWMICK, Pallav Kulshreshtha, and Sreenath 
Somarajapuram.


Changes
---

Review comments added


Bugs: AMBARI-17109
https://issues.apache.org/jira/browse/AMBARI-17109


Repository: ambari


Description
---

Capacity scheduler view - problem with queue percent rounding


Diffs (updated)
-

  
contrib/views/capacity-scheduler/src/main/resources/ui/app/components/totalCapacity.js
 c36839c 
  
contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queues.js
 4aeb442 

Diff: https://reviews.apache.org/r/48398/diff/


Testing
---


Thanks,

Akhil PB

Re: Review Request 48494: Implement config values trimming for deployment via blueprint

[Dmytro Sen]

> On Июнь 9, 2016, 4:05 п.п., Daniel Gergely wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java,
> >  line 343
> > 
> >
> > Please consider cyclomatic complexity in this method.
> 
> Dmytro Sen wrote:
> What is wrong with it ? The loop body is executed only once for every 
> property. 
> Moreover, this method is executed only once during ambari server 
> lifecycle, when the server is least loaded.
> 
> Daniel Gergely wrote:
> Loops have no relations with cyclomatic complexity. I think you wrote 
> about computational complexity (more specifically time complexity). 
> Cyclomatic complexity is a measure to show how many possible execution paths 
> are there in a specific block (eg in a method body or in a class). Each of 
> the **if** statements increases this number, since there are always 2 
> options: true or false.
> I counted 11 levels of deepness here, most of them are if statements, 
> which means a high cyclomatic complexity. 
> My review was only about avoiding it, because it makes the code less 
> maintainable and readable. Computational complexity won't be less, business 
> logic won't be changed, what you gain is maintainibility and in some cases it 
> can be easier to test.
> There are many ways how to reduce it, usually some code can be simplified 
> or a new method can be introduced. (if you google it up, you will find many 
> examples. First I would extract methods.)
> This is only suggestion, to avoid bad moments for the developer who may 
> need to change the code in the future.

Thanks for detailed clarification. 
I'll update the patch.


- Dmytro


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


On Июнь 9, 2016, 3:23 п.п., Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48494/
> ---
> 
> (Updated Июнь 9, 2016, 3:23 п.п.)
> 
> 
> Review request for Ambari, Robert Nettleton, Sebastian Toader, and Vitalyi 
> Brodetskyi.
> 
> 
> Bugs: AMBARI-17146
> https://issues.apache.org/jira/browse/AMBARI-17146
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Implement config values trimming for deployment via blueprint as we do in UI
> 
>   trimProperty: function (property) {
> var displayType = Em.get(property, 'displayType');
> var value = Em.get(property, 'value');
> var name = Em.get(property, 'name');
> var rez;
> switch (displayType) {
>   case 'directories':
>   case 'directory':
> rez = value.replace(/,/g, ' ').trim().split(/\s+/g).join(',');
> break;
>   case 'host':
> rez = value.trim();
> break;
>   case 'password':
> break;
>   default:
> if (name == 'javax.jdo.option.ConnectionURL' || name == 
> 'oozie.service.JPAService.jdbc.url') {
>   rez = value.trim();
> }
> rez = (typeof value == 'string') ? value.replace(/(\s+$)/g, '') : 
> value;
> }
> return ((rez == '') || (rez == undefined)) ? value : rez;
>   },
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  de70a2c 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/Stack.java
>  ad8d4f9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  9ec0a09 
> 
> Diff: https://reviews.apache.org/r/48494/diff/
> 
> 
> Testing
> ---
> 
> Unit tests and manual tests passed
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

Review Request 48414: AMBARI-17118 Incorrect formated external url in ranger configuration - causes Namenode startup failure

[Mugdha Varadkar]

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

Review request for Ambari, Alejandro Fernandez, Gautam Borad, Srimanth Gunturi, 
and Velmurugan Periasamy.


Bugs: AMBARI-17118
https://issues.apache.org/jira/browse/AMBARI-17118


Repository: ambari


Description
---

Ranger Admin url when configured with trailing slash causes Namenode startup 
failure


Diffs
-

  
ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions.py
 48ae225 
  
ambari-common/src/main/python/resource_management/libraries/functions/ranger_functions_v2.py
 cfdd6f7 
  
ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin.py
 260f018 
  
ambari-common/src/main/python/resource_management/libraries/functions/setup_ranger_plugin_xml.py
 e5faf4b 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
 05bad1c 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
 9af87d4 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
 fea0635 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1/package/scripts/params.py
 09878ba 
  
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/package/scripts/params_linux.py
 4d30f55 
  
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
 29ac561 
  
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/kms.py
 cbe2a31 
  
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/package/scripts/params.py
 17f71fb 
  
ambari-server/src/main/resources/common-services/STORM/0.9.1/package/scripts/params_linux.py
 978ad92 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
 4d281a8 
  ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
36fe066 
  
ambari-server/src/main/resources/stacks/HDP/2.5/services/HDFS/configuration/ranger-hdfs-plugin-properties.xml
 PRE-CREATION 

Diff: https://reviews.apache.org/r/48414/diff/


Testing
---

Tested Ranger Installation on centos6


Thanks,

Mugdha Varadkar

Re: Review Request 48501: AMBARI-17147: OSError: [Errno 1] Operation not permitted with non-root ambari agent user

[Sebastian Toader]

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


Ship it!




Ship It!

- Sebastian Toader


On June 9, 2016, 8:56 p.m., Oliver Szabo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48501/
> ---
> 
> (Updated June 9, 2016, 8:56 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Miklos Gergely, Sumit Mohanty, 
> and Sebastian Toader.
> 
> 
> Bugs: AMBARI-17147
> https://issues.apache.org/jira/browse/AMBARI-17147
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Tested on cluster with non-root ambari user and umask 0077, the changes fixed 
> the issues.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/solr_cloud_util.py
>  b099a1e 
>   
> ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata.py
>  5799288 
>   
> ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logsearch.py
>  58239c7 
>   
> ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
>  30f9527 
> 
> Diff: https://reviews.apache.org/r/48501/diff/
> 
> 
> Testing
> ---
> 
> Total run:1055
> Total errors:0
> Total failures:0
> 
> FT: tested on 4 node cluster
> 
> 
> Thanks,
> 
> Oliver Szabo
> 
>

Re: Review Request 48480: View Config- views created for 2nd remote cluster points to 1st remote cluster

[Pallav Kulshreshtha]

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


Ship it!




Ship It!

- Pallav Kulshreshtha


On June 9, 2016, 8:43 a.m., Gaurav Nagar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48480/
> ---
> 
> (Updated June 9, 2016, 8:43 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Nitiraj Rathore, Pallav 
> Kulshreshtha, Rohit Choudhary, and Ashwin Rajeev.
> 
> 
> Bugs: AMBARI-17139
> https://issues.apache.org/jira/browse/AMBARI-17139
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Change the remoteClusterMap to clusterId from remote ambari cluster name.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/view/RemoteAmbariClusterRegistry.java
>  c0c887f 
> 
> Diff: https://reviews.apache.org/r/48480/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> Gaurav Nagar
> 
>

Re: Review Request 48494: Implement config values trimming for deployment via blueprint

[Daniel Gergely]

> On jún. 9, 2016, 4:05 du, Daniel Gergely wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java,
> >  line 343
> > 
> >
> > Please consider cyclomatic complexity in this method.
> 
> Dmytro Sen wrote:
> What is wrong with it ? The loop body is executed only once for every 
> property. 
> Moreover, this method is executed only once during ambari server 
> lifecycle, when the server is least loaded.

Loops have no relations with cyclomatic complexity. I think you wrote about 
computational complexity (more specifically time complexity). Cyclomatic 
complexity is a measure to show how many possible execution paths are there in 
a specific block (eg in a method body or in a class). Each of the **if** 
statements increases this number, since there are always 2 options: true or 
false.
I counted 11 levels of deepness here, most of them are if statements, which 
means a high cyclomatic complexity. 
My review was only about avoiding it, because it makes the code less 
maintainable and readable. Computational complexity won't be less, business 
logic won't be changed, what you gain is maintainibility and in some cases it 
can be easier to test.
There are many ways how to reduce it, usually some code can be simplified or a 
new method can be introduced. (if you google it up, you will find many 
examples. First I would extract methods.)
This is only suggestion, to avoid bad moments for the developer who may need to 
change the code in the future.


- Daniel


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


On jún. 9, 2016, 3:23 du, Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48494/
> ---
> 
> (Updated jún. 9, 2016, 3:23 du)
> 
> 
> Review request for Ambari, Robert Nettleton, Sebastian Toader, and Vitalyi 
> Brodetskyi.
> 
> 
> Bugs: AMBARI-17146
> https://issues.apache.org/jira/browse/AMBARI-17146
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Implement config values trimming for deployment via blueprint as we do in UI
> 
>   trimProperty: function (property) {
> var displayType = Em.get(property, 'displayType');
> var value = Em.get(property, 'value');
> var name = Em.get(property, 'name');
> var rez;
> switch (displayType) {
>   case 'directories':
>   case 'directory':
> rez = value.replace(/,/g, ' ').trim().split(/\s+/g).join(',');
> break;
>   case 'host':
> rez = value.trim();
> break;
>   case 'password':
> break;
>   default:
> if (name == 'javax.jdo.option.ConnectionURL' || name == 
> 'oozie.service.JPAService.jdbc.url') {
>   rez = value.trim();
> }
> rez = (typeof value == 'string') ? value.replace(/(\s+$)/g, '') : 
> value;
> }
> return ((rez == '') || (rez == undefined)) ? value : rez;
>   },
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  de70a2c 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/Stack.java
>  ad8d4f9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  9ec0a09 
> 
> Diff: https://reviews.apache.org/r/48494/diff/
> 
> 
> Testing
> ---
> 
> Unit tests and manual tests passed
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

Re: Review Request 48508: AMBARI-17149 : HadoopTimelineMetricsSink from AMS prevents HBase RS process shutdown

[Dmytro Sen]

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


Ship it!




Ship It!

- Dmytro Sen


On Июнь 10, 2016, полночь, Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48508/
> ---
> 
> (Updated Июнь 10, 2016, полночь)
> 
> 
> Review request for Ambari, Dmytro Sen, enis, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17149
> https://issues.apache.org/jira/browse/AMBARI-17149
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> HadoopTimelineMetricsSink has an ExecutorService thread which is not a daemon 
> thread. 
> 
> The executor is not shutdown, and thread is not interrupted while the sink 
> stops. This causes region server process to hang although the rest of the 
> threads have all exited. The new thread should be marked as a daemon thread, 
> and also call shutdown() or shutdownNow() on the executor in sink close.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-hadoop-sink/src/main/java/org/apache/hadoop/metrics2/sink/timeline/HadoopTimelineMetricsSink.java
>  0580088 
> 
> Diff: https://reviews.apache.org/r/48508/diff/
> 
> 
> Testing
> ---
> 
> Manually tested. Unit tests pass.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>