Re: Review Request 53674: AMBARI-18857 : Add Service wizard: Storm site configs related to Ambari metrics service are not displayed on ui

[Dmytro Sen]

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


Ship it!




Ship It!

- Dmytro Sen


On Ноя. 15, 2016, 11:33 п.п., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53674/
> ---
> 
> (Updated Ноя. 15, 2016, 11:33 п.п.)
> 
> 
> Review request for Ambari, Dmytro Sen, Jaimin Jetly, Sumit Mohanty, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-18857
> https://issues.apache.org/jira/browse/AMBARI-18857
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This issue is result of storm site being scattered between Storm service and 
> AMS service. 
> It is highly recommended to avoid such scattering of config sites across 
> services. Doing so requires special handling on FE and generates lots of new 
> flows that needs to be tested. storm site should only belong and be packaged 
> inside Storm service. If there are some configs of storm-site that needs to 
> be added if AMS is present then stack advisor can be leveraged to achieve 
> that objective
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/storm-site.xml
>  7059b90 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/metainfo.xml
>  d2f5862 
>   
> ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-site.xml
>  077590a 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> f9a3a9a 
>   ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 
> 7124307 
> 
> Diff: https://reviews.apache.org/r/53674/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Python unit tests pass.
> Java Unit tests pending.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 53798: AMBARI-18902 Minor typo fix in TimeliveMetricsStore class in AMS

[Attila Doroszlai]

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


Ship it!




BTW there is a typo in the bug title, `TimeliveMetricsStore` is actually 
`TimelineMetricStore` in the code ;)

- Attila Doroszlai


On Nov. 15, 2016, 11:33 p.m., Di Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53798/
> ---
> 
> (Updated Nov. 15, 2016, 11:33 p.m.)
> 
> 
> Review request for Ambari and Tim Thorpe.
> 
> 
> Bugs: AMBARI-18902
> https://issues.apache.org/jira/browse/AMBARI-18902
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Minor typo fix in TimeliveMetricsStore class in AMS
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  15644ed 
> 
> Diff: https://reviews.apache.org/r/53798/diff/
> 
> 
> Testing
> ---
> 
> typo is in javadoc, no unit tests required.
> 
> 
> Thanks,
> 
> Di Li
> 
>

Re: Review Request 52155: ambari server upgrade ambari to 2.1.1 duplicate key error

[wang yaoxin]

> On 九月 27, 2016, 12:39 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java,
> >  lines 225-226
> > 
> >
> > This doesn't guarantee ordering of any kind - the first one which comes 
> > back could have an ID of 9. Since it doesn't match `m_hcsId`, this code 
> > would try to update it to to a value of 1 and possibly cause duplicates.
> > 
> > You can simply skip this whole section of updating if the 
> > `resultSet.getLong("id")` is non-null/non-zero. 
> > 
> > You can then so something like this:
> > `m_hcsId.set(NumberUtils.max(m_hcsId.get(), idKey)`
> 
> wang yaoxin wrote:
> Hi Jonathan ,Thanks for your advice, that is highly appreciated. However, 
> consider the randomness of the value of idKey, my method may avoid this 
> issue. For instance, if the first-time get value of resultSet.getLong("id") 
> is 2, and the second-time get value is 1, then basing on your method, the 
> duplicates error would still occur. Hope we could get further agreement on 
> this case, thanks.
> 
> Jonathan Hurley wrote:
> The problem here is on the 2nd time through, correct? If the first time 
> through it only did half of them (for some reason) then you're left with some 
> rows having an ID and some not. My point is to totally skip rows which have a 
> valid ID - you can sort by ID so you go through all of them first, 
> incrementing m_hceId along the way. This way, you're going to be guaranteed 
> to go through your non-zero IDs first and when you finally hit your first 
> null ID, you're atomic counter is ready to pickup.

Hi Jonathan ,Thanks for? I understand what you mean, and I've made the 
modification basing on your advice in AMBARI-18441-02.patch


- wang


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


On 九月 27, 2016, 12:03 p.m., wang yaoxin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52155/
> ---
> 
> (Updated 九月 27, 2016, 12:03 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Oliver Szabo, Robert Nettleton, 
> and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18441
> https://issues.apache.org/jira/browse/AMBARI-18441
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> My first upgrade test failed due to my environment issue. Since in real 
> production environment this failure would  occur again.
> 
> ambari upgrade to 2.1.1 and later version, if the first time failed , excute 
> ambari-server upgrade again will error duplicate key value violates unique 
> constraint "pk_hostcomponentstate".
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java
>  db13612 
> 
> Diff: https://reviews.apache.org/r/52155/diff/
> 
> 
> Testing
> ---
> 
> the unit test is UpgradeCatalog211Test.java: Process finished with exit code 
> 0.
> done !
> 
> 
> Thanks,
> 
> wang yaoxin
> 
>

Re: Review Request 52155: ambari server upgrade ambari to 2.1.1 duplicate key error

[wang yaoxin]

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

(Updated 十一月 16, 2016, 6:49 a.m.)


Review request for Ambari, Jonathan Hurley, Oliver Szabo, Robert Nettleton, and 
Sebastian Toader.


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


Repository: ambari


Description
---

My first upgrade test failed due to my environment issue. Since in real 
production environment this failure would  occur again.

ambari upgrade to 2.1.1 and later version, if the first time failed , excute 
ambari-server upgrade again will error duplicate key value violates unique 
constraint "pk_hostcomponentstate".


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java
 db13612 

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


Testing
---

the unit test is UpgradeCatalog211Test.java: Process finished with exit code 0.
done !


File Attachments (updated)


AMBARI-18441-02.patch
  
https://reviews.apache.org/media/uploaded/files/2016/11/16/4c6f3d15-96cc-4c22-babe-b45b103a8c30__AMBARI-18441-02.patch


Thanks,

wang yaoxin

Re: Review Request 52455: Ambari UI changes to support PAM authentication

[Sangeeta Ravindran]

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

(Updated Nov. 16, 2016, 5:27 a.m.)


Review request for Ambari, Alejandro Fernandez, Alexandr Antonenko, and Di Li.


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


Repository: ambari


Description
---

AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
Ambari UI/REST. The changes in this review request cover the corresponding 
changes in the amabri-admin code. 
Since a new column groupt_type has been added for groups, the UI will display 
labels for group type and enable/disable group delete/add member functionality 
based on the group_type instead of the ldap_group flag.
Patch includes similar changes for users. The user_type will be used to 
determine if the user can be deleted or if the user's password can be changed.


Diffs
-

  ambari-admin/src/main/resources/ui/admin-web/app/index.html b3f1bd1 
  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsEditCtrl.js
 2e7830b 
  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsListCtrl.js
 1f86393 
  ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
af22d7f 
  ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Group.js 
660306c 
  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/GroupConstants.js
 PRE-CREATION 
  
ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/UserConstants.js
 da63c6d 
  ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html 
8271432 
  ambari-admin/src/main/resources/ui/admin-web/app/views/groups/list.html 
b359ede 
  ambari-admin/src/main/resources/ui/admin-web/app/views/users/show.html 
e576b28 

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


Testing
---

Manual testing. 
Tests in ambari admin project ran clean.
PhantomJS 1.9.7 (Linux): Executed 86 of 86 SUCCESS (0.771 secs / 0.75 secs)


File Attachments (updated)


New patch
  
https://reviews.apache.org/media/uploaded/files/2016/10/03/460d7193-8d55-4ce3-96c6-ad3240502e7b__AMBARI-18476.patch
Final patch
  
https://reviews.apache.org/media/uploaded/files/2016/10/04/3d025c3b-1f60-4a0c-9a49-0802a21c99fd__AMBARI-18476.patch
Patch based on latest code
  
https://reviews.apache.org/media/uploaded/files/2016/11/04/7fa50e96-c66b-4c5e-9321-13b623ab0710__AMBARI-18476.patch
Patch for 2.5
  
https://reviews.apache.org/media/uploaded/files/2016/11/16/0d18da03-21c2-4360-90fa-b144d728ee2d__AMBARI-18476_2.5patch


Thanks,

Sangeeta Ravindran

Re: Review Request 52455: Ambari UI changes to support PAM authentication

[Di Li]

> On Nov. 4, 2016, 3:03 p.m., Di Li wrote:
> > Ship It!
> 
> Sangeeta Ravindran wrote:
> Hi Di,
> 
> Can you please help commit this patch? I haven't pushed changed to trunk 
> before and would appreciate your help. Thanks.

Hello Sangeeta,

Could you rebase and reattach a patch file ? Current one does not apply to 
trunk
error: patch failed: 
ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html:22
error: ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html: 
patch does not apply


- Di


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


On Nov. 4, 2016, 9:23 a.m., Sangeeta Ravindran wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52455/
> ---
> 
> (Updated Nov. 4, 2016, 9:23 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Alexandr Antonenko, and Di Li.
> 
> 
> Bugs: AMBARI-18476
> https://issues.apache.org/jira/browse/AMBARI-18476
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. The changes in this review request cover the corresponding 
> changes in the amabri-admin code. 
> Since a new column groupt_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> Patch includes similar changes for users. The user_type will be used to 
> determine if the user can be deleted or if the user's password can be changed.
> 
> 
> Diffs
> -
> 
>   ambari-admin/src/main/resources/ui/admin-web/app/index.html b3f1bd1 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsEditCtrl.js
>  2e7830b 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsListCtrl.js
>  1f86393 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
> af22d7f 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Group.js 
> 660306c 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/GroupConstants.js
>  PRE-CREATION 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/UserConstants.js
>  da63c6d 
>   ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html 
> 8271432 
>   ambari-admin/src/main/resources/ui/admin-web/app/views/groups/list.html 
> b359ede 
>   ambari-admin/src/main/resources/ui/admin-web/app/views/users/show.html 
> e576b28 
> 
> Diff: https://reviews.apache.org/r/52455/diff/
> 
> 
> Testing
> ---
> 
> Manual testing. 
> Tests in ambari admin project ran clean.
> PhantomJS 1.9.7 (Linux): Executed 86 of 86 SUCCESS (0.771 secs / 0.75 secs)
> 
> 
> File Attachments
> 
> 
> New patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/10/03/460d7193-8d55-4ce3-96c6-ad3240502e7b__AMBARI-18476.patch
> Final patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/10/04/3d025c3b-1f60-4a0c-9a49-0802a21c99fd__AMBARI-18476.patch
> Patch based on latest code
>   
> https://reviews.apache.org/media/uploaded/files/2016/11/04/7fa50e96-c66b-4c5e-9321-13b623ab0710__AMBARI-18476.patch
> 
> 
> Thanks,
> 
> Sangeeta Ravindran
> 
>

Re: Review Request 52155: ambari server upgrade ambari to 2.1.1 duplicate key error

[Jonathan Hurley]

> On Sept. 27, 2016, 8:39 a.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java,
> >  lines 225-226
> > 
> >
> > This doesn't guarantee ordering of any kind - the first one which comes 
> > back could have an ID of 9. Since it doesn't match `m_hcsId`, this code 
> > would try to update it to to a value of 1 and possibly cause duplicates.
> > 
> > You can simply skip this whole section of updating if the 
> > `resultSet.getLong("id")` is non-null/non-zero. 
> > 
> > You can then so something like this:
> > `m_hcsId.set(NumberUtils.max(m_hcsId.get(), idKey)`
> 
> wang yaoxin wrote:
> Hi Jonathan ,Thanks for your advice, that is highly appreciated. However, 
> consider the randomness of the value of idKey, my method may avoid this 
> issue. For instance, if the first-time get value of resultSet.getLong("id") 
> is 2, and the second-time get value is 1, then basing on your method, the 
> duplicates error would still occur. Hope we could get further agreement on 
> this case, thanks.

The problem here is on the 2nd time through, correct? If the first time through 
it only did half of them (for some reason) then you're left with some rows 
having an ID and some not. My point is to totally skip rows which have a valid 
ID - you can sort by ID so you go through all of them first, incrementing 
m_hceId along the way. This way, you're going to be guaranteed to go through 
your non-zero IDs first and when you finally hit your first null ID, you're 
atomic counter is ready to pickup.


- Jonathan


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


On Sept. 27, 2016, 8:03 a.m., wang yaoxin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52155/
> ---
> 
> (Updated Sept. 27, 2016, 8:03 a.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Oliver Szabo, Robert Nettleton, 
> and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18441
> https://issues.apache.org/jira/browse/AMBARI-18441
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> My first upgrade test failed due to my environment issue. Since in real 
> production environment this failure would  occur again.
> 
> ambari upgrade to 2.1.1 and later version, if the first time failed , excute 
> ambari-server upgrade again will error duplicate key value violates unique 
> constraint "pk_hostcomponentstate".
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java
>  db13612 
> 
> Diff: https://reviews.apache.org/r/52155/diff/
> 
> 
> Testing
> ---
> 
> the unit test is UpgradeCatalog211Test.java: Process finished with exit code 
> 0.
> done !
> 
> 
> Thanks,
> 
> wang yaoxin
> 
>

Re: Review Request 52455: Ambari UI changes to support PAM authentication

[Sangeeta Ravindran]

> On Nov. 4, 2016, 3:03 p.m., Di Li wrote:
> > Ship It!

Hi Di,

Can you please help commit this patch? I haven't pushed changed to trunk before 
and would appreciate your help. Thanks.


- Sangeeta


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


On Nov. 4, 2016, 9:23 a.m., Sangeeta Ravindran wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52455/
> ---
> 
> (Updated Nov. 4, 2016, 9:23 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Alexandr Antonenko, and Di Li.
> 
> 
> Bugs: AMBARI-18476
> https://issues.apache.org/jira/browse/AMBARI-18476
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> AMBARI-12263 adds support for PAM as authentication mechanism for accessing 
> Ambari UI/REST. The changes in this review request cover the corresponding 
> changes in the amabri-admin code. 
> Since a new column groupt_type has been added for groups, the UI will display 
> labels for group type and enable/disable group delete/add member 
> functionality based on the group_type instead of the ldap_group flag.
> Patch includes similar changes for users. The user_type will be used to 
> determine if the user can be deleted or if the user's password can be changed.
> 
> 
> Diffs
> -
> 
>   ambari-admin/src/main/resources/ui/admin-web/app/index.html b3f1bd1 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsEditCtrl.js
>  2e7830b 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/controllers/groups/GroupsListCtrl.js
>  1f86393 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/i18n.config.js 
> af22d7f 
>   ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/Group.js 
> 660306c 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/GroupConstants.js
>  PRE-CREATION 
>   
> ambari-admin/src/main/resources/ui/admin-web/app/scripts/services/UserConstants.js
>  da63c6d 
>   ambari-admin/src/main/resources/ui/admin-web/app/views/groups/edit.html 
> 8271432 
>   ambari-admin/src/main/resources/ui/admin-web/app/views/groups/list.html 
> b359ede 
>   ambari-admin/src/main/resources/ui/admin-web/app/views/users/show.html 
> e576b28 
> 
> Diff: https://reviews.apache.org/r/52455/diff/
> 
> 
> Testing
> ---
> 
> Manual testing. 
> Tests in ambari admin project ran clean.
> PhantomJS 1.9.7 (Linux): Executed 86 of 86 SUCCESS (0.771 secs / 0.75 secs)
> 
> 
> File Attachments
> 
> 
> New patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/10/03/460d7193-8d55-4ce3-96c6-ad3240502e7b__AMBARI-18476.patch
> Final patch
>   
> https://reviews.apache.org/media/uploaded/files/2016/10/04/3d025c3b-1f60-4a0c-9a49-0802a21c99fd__AMBARI-18476.patch
> Patch based on latest code
>   
> https://reviews.apache.org/media/uploaded/files/2016/11/04/7fa50e96-c66b-4c5e-9321-13b623ab0710__AMBARI-18476.patch
> 
> 
> Thanks,
> 
> Sangeeta Ravindran
> 
>

Re: Review Request 53771: AMBARI-18890 - Enable "Auto Start" feature for services & components by default

[Xi Wang]

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


Ship it!




Ship It!

- Xi Wang


On Nov. 14, 2016, 7:08 p.m., Richard Zang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53771/
> ---
> 
> (Updated Nov. 14, 2016, 7:08 p.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly and Yusaku Sako.
> 
> 
> Bugs: AMBARI-18890
> https://issues.apache.org/jira/browse/AMBARI-18890
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Emable auto start.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/config.js c3c45b1 
> 
> Diff: https://reviews.apache.org/r/53771/diff/
> 
> 
> Testing
> ---
> 
> Manually tested on live cluster. 
> All unit test passed.
>   25353 tests complete (37 seconds)
>   57 tests pending
> 
> 
> Thanks,
> 
> Richard Zang
> 
>

Re: Review Request 53798: AMBARI-18902 Minor typo fix in TimeliveMetricsStore class in AMS

[Aravindan Vijayan]

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


Ship it!




Ship It!

- Aravindan Vijayan


On Nov. 15, 2016, 10:33 p.m., Di Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53798/
> ---
> 
> (Updated Nov. 15, 2016, 10:33 p.m.)
> 
> 
> Review request for Ambari and Tim Thorpe.
> 
> 
> Bugs: AMBARI-18902
> https://issues.apache.org/jira/browse/AMBARI-18902
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Minor typo fix in TimeliveMetricsStore class in AMS
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
>  15644ed 
> 
> Diff: https://reviews.apache.org/r/53798/diff/
> 
> 
> Testing
> ---
> 
> typo is in javadoc, no unit tests required.
> 
> 
> Thanks,
> 
> Di Li
> 
>

Re: Review Request 53674: AMBARI-18857 : Add Service wizard: Storm site configs related to Ambari metrics service are not displayed on ui

[Aravindan Vijayan]

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

(Updated Nov. 15, 2016, 11:33 p.m.)


Review request for Ambari, Dmytro Sen, Jaimin Jetly, Sumit Mohanty, and Sid 
Wagle.


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


Repository: ambari


Description
---

This issue is result of storm site being scattered between Storm service and 
AMS service. 
It is highly recommended to avoid such scattering of config sites across 
services. Doing so requires special handling on FE and generates lots of new 
flows that needs to be tested. storm site should only belong and be packaged 
inside Storm service. If there are some configs of storm-site that needs to be 
added if AMS is present then stack advisor can be leveraged to achieve that 
objective


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/storm-site.xml
 7059b90 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/metainfo.xml
 d2f5862 
  
ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-site.xml
 077590a 
  ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
f9a3a9a 
  ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 7124307 

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


Testing
---

Manually tested.
Python unit tests pass.
Java Unit tests pending.


Thanks,

Aravindan Vijayan

Review Request 53798: AMBARI-18902 Minor typo fix in TimeliveMetricsStore class in AMS

[Di Li]

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

Review request for Ambari and Tim Thorpe.


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


Repository: ambari


Description
---

Minor typo fix in TimeliveMetricsStore class in AMS


Diffs
-

  
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/TimelineMetricStore.java
 15644ed 

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


Testing
---

typo is in javadoc, no unit tests required.


Thanks,

Di Li

Re: Review Request 53721: Zeppelin notebook execution fails due missing spark dependency

[Alejandro Fernandez]

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


Ship it!




Ship It!

- Alejandro Fernandez


On Nov. 15, 2016, 11:52 a.m., Renjith Kamath wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53721/
> ---
> 
> (Updated Nov. 15, 2016, 11:52 a.m.)
> 
> 
> Review request for Ambari, Attila Doroszlai, Alejandro Fernandez, DIPAYAN 
> BHOWMICK, Jayush Luniya, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18872
> https://issues.apache.org/jira/browse/AMBARI-18872
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> details in the bug description
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py
>  080fcd6 
>   ambari-server/src/main/resources/scripts/Ambaripreupload.py c04424f 
>   
> ambari-server/src/main/resources/stacks/HDP/2.6/services/ZEPPELIN/metainfo.xml
>  0c3aa77 
> 
> Diff: https://reviews.apache.org/r/53721/diff/
> 
> 
> Testing
> ---
> 
> manually tested on CentOS
> 
> 
> Thanks,
> 
> Renjith Kamath
> 
>

Re: Review Request 53663: Add ability to add custom input descriptor to logfeeder

[Miklos Gergely]

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

(Updated Nov. 15, 2016, 10:22 p.m.)


Review request for Ambari, Oliver Szabo, Robert Nettleton, and Sumit Mohanty.


Changes
---

updated to be appliable on the latest branch-2.5


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


Repository: ambari


Description
---

Offer some properties in the logsearch configuration via which the user can set 
up some other input logs in a similar way as the component logs.


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logfeeder-custom-logsearch-conf.xml
 PRE-CREATION 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/logsearch_config_aggregator.py
 ad515ee 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/params.py
 1f5064a 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/scripts/setup_logfeeder.py
 e90d623 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/package/templates/HadoopServiceConfig.json.j2
 7e9153f 
  ambari-server/src/test/python/stacks/2.4/LOGSEARCH/test_logfeeder.py 7a13637 

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


Testing
---

Tested on local cluster.


Thanks,

Miklos Gergely

Re: Review Request 53786: Multiple kerberos name rules can not be set up for Ambari Infra Solr

[Miklos Gergely]

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

(Updated Nov. 15, 2016, 10:13 p.m.)


Review request for Ambari, Oliver Szabo, Robert Nettleton, and Sumit Mohanty.


Changes
---

copy before chmod


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


Repository: ambari


Description
---

If multiple rules are entered into the proprety
Advanced infra-solr-env / Infra Solr Kerberos name rules
There are multiple issues here:
1. The rules should be escaped, the $ characters in them should be handled, so 
that the expressions in the rules like $0, $1 are not replaced with the script 
directory, and the script file name. Currently the user must do this in the 
value entered, which is not even documented.
2. The variable SOLR_KERB_NAME_RULES in infra-solr-env.sh should have quotes 
around it's value, so that the whole string is assigned to it, not only the 
first rule.
3. SOLR_KERB_NAME_RULES can not be the part of SOLR_AUTHENTICATION_OPTS, 
because it is handled incorrectly, if an expression like -Dname="value1 value2" 
is passed to the jvm from a bash variable. Therefore 
/usr/lib/ambari-infra-solr/bin/solr should be updated, and 
-Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES" should be added directly 
into the command script.
Options


Diffs (updated)
-

  ambari-logsearch/ambari-logsearch-assembly/pom.xml 3c18cba 
  ambari-logsearch/ambari-logsearch-assembly/src/main/resources/solr 
PRE-CREATION 
  
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
 8bdf0a9 
  
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-env.sh.j2
 8c24fa4 

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


Testing
---

Tested on local cluster.


Thanks,

Miklos Gergely

Re: Review Request 53721: Zeppelin notebook execution fails due missing spark dependency

[Attila Doroszlai]

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


Ship it!




Ship It!

- Attila Doroszlai


On Nov. 15, 2016, 12:52 p.m., Renjith Kamath wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53721/
> ---
> 
> (Updated Nov. 15, 2016, 12:52 p.m.)
> 
> 
> Review request for Ambari, Attila Doroszlai, Alejandro Fernandez, DIPAYAN 
> BHOWMICK, Jayush Luniya, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18872
> https://issues.apache.org/jira/browse/AMBARI-18872
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> details in the bug description
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/ZEPPELIN/0.6.0.2.5/package/scripts/master.py
>  080fcd6 
>   ambari-server/src/main/resources/scripts/Ambaripreupload.py c04424f 
>   
> ambari-server/src/main/resources/stacks/HDP/2.6/services/ZEPPELIN/metainfo.xml
>  0c3aa77 
> 
> Diff: https://reviews.apache.org/r/53721/diff/
> 
> 
> Testing
> ---
> 
> manually tested on CentOS
> 
> 
> Thanks,
> 
> Renjith Kamath
> 
>

Re: Review Request 53788: HTTP responses needs to have the character encoding specified in the content type header

[Di Li]

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


Ship it!




Ship It!

- Di Li


On Nov. 15, 2016, 5:05 p.m., Anita Jebaraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53788/
> ---
> 
> (Updated Nov. 15, 2016, 5:05 p.m.)
> 
> 
> Review request for Ambari, Di Li, Robert Levas, and Sangeeta Ravindran.
> 
> 
> Bugs: AMBARI-18871
> https://issues.apache.org/jira/browse/AMBARI-18871
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> The charset information(UTF-8) can be added to all the response headers to 
> harden the security for the client. When the charset information is not 
> specified the web browser may choose a different encoding by guessing which 
> encoding is actually being used by the web page.
> 
> This specific issue is mentioned in the section 3.1.1.5 of RFC7231
> 
> 
> Diffs
> -
> 
>   ambari-server/conf/unix/ambari.properties 371653f 
>   ambari-server/conf/windows/ambari.properties e47319e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  15f186b 
>   
> ambari-server/src/main/java/org/apache/ambari/server/security/AbstractSecurityHeaderFilter.java
>  423a013 
>   
> ambari-server/src/main/java/org/apache/ambari/server/security/AmbariServerSecurityHeaderFilter.java
>  aa00ac2 
>   
> ambari-server/src/main/java/org/apache/ambari/server/security/AmbariViewsSecurityHeaderFilter.java
>  d1be8cc 
>   
> ambari-server/src/test/java/org/apache/ambari/server/security/AbstractSecurityHeaderFilterTest.java
>  d812ee6 
> 
> Diff: https://reviews.apache.org/r/53788/diff/
> 
> 
> Testing
> ---
> 
> Ran mvn test.
> 
> The test cases failing in hadoop QA is not related to the patch for this jira
> 
> 
> Thanks,
> 
> Anita Jebaraj
> 
>

Re: Review Request 53786: Multiple kerberos name rules can not be set up for Ambari Infra Solr

[Robert Nettleton]

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


Ship it!




Ship It!

- Robert Nettleton


On Nov. 15, 2016, 4:50 p.m., Miklos Gergely wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53786/
> ---
> 
> (Updated Nov. 15, 2016, 4:50 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo, Robert Nettleton, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18898
> https://issues.apache.org/jira/browse/AMBARI-18898
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If multiple rules are entered into the proprety
> Advanced infra-solr-env / Infra Solr Kerberos name rules
> There are multiple issues here:
> 1. The rules should be escaped, the $ characters in them should be handled, 
> so that the expressions in the rules like $0, $1 are not replaced with the 
> script directory, and the script file name. Currently the user must do this 
> in the value entered, which is not even documented.
> 2. The variable SOLR_KERB_NAME_RULES in infra-solr-env.sh should have quotes 
> around it's value, so that the whole string is assigned to it, not only the 
> first rule.
> 3. SOLR_KERB_NAME_RULES can not be the part of SOLR_AUTHENTICATION_OPTS, 
> because it is handled incorrectly, if an expression like -Dname="value1 
> value2" is passed to the jvm from a bash variable. Therefore 
> /usr/lib/ambari-infra-solr/bin/solr should be updated, and 
> -Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES" should be added directly 
> into the command script.
> Options
> 
> 
> Diffs
> -
> 
>   ambari-logsearch/ambari-logsearch-assembly/pom.xml 3c18cba 
>   ambari-logsearch/ambari-logsearch-assembly/src/main/resources/solr 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
>  8bdf0a9 
>   
> ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-env.sh.j2
>  8c24fa4 
> 
> Diff: https://reviews.apache.org/r/53786/diff/
> 
> 
> Testing
> ---
> 
> Tested on local cluster.
> 
> 
> Thanks,
> 
> Miklos Gergely
> 
>

Re: Review Request 53678: AMBARI-18846 - Custom services should be able to easily specify their own dashboards

[Di Li]

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


Ship it!




Ship It!

- Di Li


On Nov. 15, 2016, 4:16 p.m., Tim Thorpe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53678/
> ---
> 
> (Updated Nov. 15, 2016, 4:16 p.m.)
> 
> 
> Review request for Ambari, Aravindan Vijayan, Di Li, Jayush Luniya, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-18846
> https://issues.apache.org/jira/browse/AMBARI-18846
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Currently all dashboards are added directly in under the AMBARI_METRICS 
> package directory (package/files/grafana-dashboards).
> 
> In order for custom services to add dashboards, they need to add the files 
> directly under that folder. Each time the Ambari server is upgraded, those 
> files will be lost as the AMBARI_METRICS service definition will be replaced.
> 
> This JIRA proposes adding a new directory under the ambari-server/resources. 
> This will contain both the dashboards and metrics for custom services.
> 
> The dashboards here will not be organized by stack. Each service will add a 
> directory containing their dashboards and will add a metrics file.
> 
> resources/dashboards/grafana-dashboards/MY_SERVICE/
> resources/dashboards/service-metrics/MY_SERVICE.txt
> 
> The resources/dashboards directory will need to get sync'd to the agents.
> 
> 
> Diffs
> -
> 
>   ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py 
> 57416a4 
>   ambari-agent/src/main/python/ambari_agent/FileCache.py b7c5dee 
>   ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py 
> c9724b7 
>   ambari-agent/src/test/python/ambari_agent/TestFileCache.py 5933daa 
>   ambari-server/src/main/python/ambari_server/resourceFilesKeeper.py f2a3ebd 
>   ambari-server/src/main/python/ambari_server/serverConfiguration.py 04509cf 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana_util.py
>  b98dc1d 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/params.py
>  b052999 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/split_points.py
>  aa03d197 
>   ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py 
> c7c3b2b 
>   ambari-server/src/test/python/TestResourceFilesKeeper.py 966d3b1 
> 
> Diff: https://reviews.apache.org/r/53678/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test -Dtest=HostResourceProviderTest
> 
> Manually added custom service dashboard and metrics to 
> resources/dashboards/grafana-dashboards and 
> resources/dashboards/service-metrics respectively, verified they were sync'd 
> to the agents and the dashboards appeared on the grafana UI.
> 
> 
> Thanks,
> 
> Tim Thorpe
> 
>

Re: Review Request 53786: Multiple kerberos name rules can not be set up for Ambari Infra Solr

[Oliver Szabo]

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




ambari-logsearch/ambari-logsearch-assembly/pom.xml (line 240)


can you put that line before chmode is called, just becase then we wont 
have the right access for that script


- Oliver Szabo


On Nov. 15, 2016, 4:50 p.m., Miklos Gergely wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53786/
> ---
> 
> (Updated Nov. 15, 2016, 4:50 p.m.)
> 
> 
> Review request for Ambari, Oliver Szabo, Robert Nettleton, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18898
> https://issues.apache.org/jira/browse/AMBARI-18898
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If multiple rules are entered into the proprety
> Advanced infra-solr-env / Infra Solr Kerberos name rules
> There are multiple issues here:
> 1. The rules should be escaped, the $ characters in them should be handled, 
> so that the expressions in the rules like $0, $1 are not replaced with the 
> script directory, and the script file name. Currently the user must do this 
> in the value entered, which is not even documented.
> 2. The variable SOLR_KERB_NAME_RULES in infra-solr-env.sh should have quotes 
> around it's value, so that the whole string is assigned to it, not only the 
> first rule.
> 3. SOLR_KERB_NAME_RULES can not be the part of SOLR_AUTHENTICATION_OPTS, 
> because it is handled incorrectly, if an expression like -Dname="value1 
> value2" is passed to the jvm from a bash variable. Therefore 
> /usr/lib/ambari-infra-solr/bin/solr should be updated, and 
> -Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES" should be added directly 
> into the command script.
> Options
> 
> 
> Diffs
> -
> 
>   ambari-logsearch/ambari-logsearch-assembly/pom.xml 3c18cba 
>   ambari-logsearch/ambari-logsearch-assembly/src/main/resources/solr 
> PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
>  8bdf0a9 
>   
> ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-env.sh.j2
>  8c24fa4 
> 
> Diff: https://reviews.apache.org/r/53786/diff/
> 
> 
> Testing
> ---
> 
> Tested on local cluster.
> 
> 
> Thanks,
> 
> Miklos Gergely
> 
>

Re: Review Request 53728: KNOX/SSO support for Log Search (JWT based)

[Oliver Szabo]

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

(Updated Nov. 15, 2016, 8:19 p.m.)


Review request for Ambari, Miklos Gergely, Robert Nettleton, and Sumit Mohanty.


Changes
---

change label name


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


Repository: ambari


Description
---

added JWT based authentication for Log Search.
Added a new filter with request matchers. Filter is executed after the original 
authentication filter is done wit the filtering, therfore its not needed to 
change anything on ambari server side (REST API)


Diffs (updated)
-

  ambari-logsearch/ambari-logsearch-portal/pom.xml be58732 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/AuthPropsConfig.java
 67ddd1f 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/SecurityConfig.java
 d3db110 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchJWTFilter.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchSecurityContextFormationFilter.java
 1320278 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchUsernamePasswordAuthenticationFilter.java
 85688a2 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/model/JWTAuthenticationToken.java
 PRE-CREATION 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
 febeffd 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/themes/theme.json
 2ed6474 
  ambari-web/app/data/HDP2/site_properties.js 5be3b5a 

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


Testing
---

testing done.


Thanks,

Oliver Szabo

Re: Review Request 53793: Post Upgrade to Ambari 2.4.1 from 2.2.2 --> All stack component prompted for restart

[Dmitro Lisnichenko]

> On Nov. 15, 2016, 9:22 p.m., Jonathan Hurley wrote:
> > You've made sure that we don't reference any of these in Python without 
> > sensible defaults?

looks like we don't


- Dmitro


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


On Nov. 15, 2016, 7:59 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53793/
> ---
> 
> (Updated Nov. 15, 2016, 7:59 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18899
> https://issues.apache.org/jira/browse/AMBARI-18899
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> I think not marking HDFS as restart required when Ambari upgrades is a good 
> goal.
> 
> In general its a difficult to get it right for all services.
> * hadoop.security.key.provider.path
> * dfs.encryption.key.provider.uri
> 
> These two are removed by stack advisor when RANGER KMS does not exist. We 
> should find out why it got added on Ambari upgrade. This seems like a bug to 
> me.
> * namenode_backup_dir
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
>  afaaee8 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/core-site.xml
>  846b09e 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/hdfs-site.xml
>  aad524d 
>   
> ambari-server/src/main/resources/stacks/PHD/3.0/services/HDFS/configuration/core-site.xml
>  4f18611 
>   
> ambari-server/src/main/resources/stacks/PHD/3.0/services/HDFS/configuration/hdfs-site.xml
>  0fed58d 
> 
> Diff: https://reviews.apache.org/r/53793/diff/
> 
> 
> Testing
> ---
> 
> Checked on cluster with Ranger installed. Upgraded Ambari 2.4.2->2.5.0 
> without these properties, services were able to stop/start without issues.
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 53793: Post Upgrade to Ambari 2.4.1 from 2.2.2 --> All stack component prompted for restart

[Jonathan Hurley]

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


Ship it!




You've made sure that we don't reference any of these in Python without 
sensible defaults?

- Jonathan Hurley


On Nov. 15, 2016, 12:59 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53793/
> ---
> 
> (Updated Nov. 15, 2016, 12:59 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18899
> https://issues.apache.org/jira/browse/AMBARI-18899
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> I think not marking HDFS as restart required when Ambari upgrades is a good 
> goal.
> 
> In general its a difficult to get it right for all services.
> * hadoop.security.key.provider.path
> * dfs.encryption.key.provider.uri
> 
> These two are removed by stack advisor when RANGER KMS does not exist. We 
> should find out why it got added on Ambari upgrade. This seems like a bug to 
> me.
> * namenode_backup_dir
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
>  afaaee8 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/core-site.xml
>  846b09e 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/hdfs-site.xml
>  aad524d 
>   
> ambari-server/src/main/resources/stacks/PHD/3.0/services/HDFS/configuration/core-site.xml
>  4f18611 
>   
> ambari-server/src/main/resources/stacks/PHD/3.0/services/HDFS/configuration/hdfs-site.xml
>  0fed58d 
> 
> Diff: https://reviews.apache.org/r/53793/diff/
> 
> 
> Testing
> ---
> 
> Checked on cluster with Ranger installed. Upgraded Ambari 2.4.2->2.5.0 
> without these properties, services were able to stop/start without issues.
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 53684: Fix for limiting the number of recommendations artifacts during stack advisor calls

[Madhuvanthi Radhakrishnan]

> On Nov. 15, 2016, 7:17 p.m., Sumit Mohanty wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelper.java,
> >  line 127
> > 
> >
> > Nit - space after comma

Hi Sumit,
The latest Diff 5 version, will not have this change since from Diff 2 we 
changed the approach of the fix.
Diff 5 will continue to be - 
command = new 
ConfigurationDependenciesRecommendationCommand(recommendationsDir, 
recommendationsArtifactsLifetime, stackAdvisorScript,


- Madhuvanthi


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


On Nov. 15, 2016, 6:28 p.m., Madhuvanthi Radhakrishnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53684/
> ---
> 
> (Updated Nov. 15, 2016, 6:28 p.m.)
> 
> 
> Review request for Ambari, Sumit Mohanty and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-18866
> https://issues.apache.org/jira/browse/AMBARI-18866
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Applied logic for rolling over during creation of recommendations artifacts 
> greater than a certain set limit.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelper.java
>  e175c69 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  6cc4120 
>   
> ambari-server/src/test/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelperTest.java
>  5190dea 
> 
> Diff: https://reviews.apache.org/r/53684/diff/
> 
> 
> Testing
> ---
> 
> 1. Set the recommendations.artifacts.rollovermax = 5
> Expected : Calls to stack advisor > 5 roll over starting from 0 again. Hence 
> at any point of time there will be upto 5 folders only in 
> /var/run/ambari-server/stack-recommendations
> 2. Do not set this value
> Expected : Defaults to 100
> 3. Set the recommendations.artifacts.rollovermax = 0
> Expected : Defaults to 100
> 
> On ambari-server restart, the ids are reset as before.
> 
> 
> Thanks,
> 
> Madhuvanthi Radhakrishnan
> 
>

Re: Review Request 53684: Fix for limiting the number of recommendations artifacts during stack advisor calls

[Sumit Mohanty]

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


Ship it!




Ship It!


ambari-server/src/main/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelper.java
 (line 127)


Nit - space after comma


- Sumit Mohanty


On Nov. 15, 2016, 6:28 p.m., Madhuvanthi Radhakrishnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53684/
> ---
> 
> (Updated Nov. 15, 2016, 6:28 p.m.)
> 
> 
> Review request for Ambari, Sumit Mohanty and Swapan Shridhar.
> 
> 
> Bugs: AMBARI-18866
> https://issues.apache.org/jira/browse/AMBARI-18866
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Applied logic for rolling over during creation of recommendations artifacts 
> greater than a certain set limit.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelper.java
>  e175c69 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  6cc4120 
>   
> ambari-server/src/test/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelperTest.java
>  5190dea 
> 
> Diff: https://reviews.apache.org/r/53684/diff/
> 
> 
> Testing
> ---
> 
> 1. Set the recommendations.artifacts.rollovermax = 5
> Expected : Calls to stack advisor > 5 roll over starting from 0 again. Hence 
> at any point of time there will be upto 5 folders only in 
> /var/run/ambari-server/stack-recommendations
> 2. Do not set this value
> Expected : Defaults to 100
> 3. Set the recommendations.artifacts.rollovermax = 0
> Expected : Defaults to 100
> 
> On ambari-server restart, the ids are reset as before.
> 
> 
> Thanks,
> 
> Madhuvanthi Radhakrishnan
> 
>

Re: Review Request 52155: ambari server upgrade ambari to 2.1.1 duplicate key error

[Alejandro Fernandez]

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


Ship it!




Ship It!

- Alejandro Fernandez


On Sept. 27, 2016, 12:03 p.m., wang yaoxin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52155/
> ---
> 
> (Updated Sept. 27, 2016, 12:03 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Oliver Szabo, Robert Nettleton, 
> and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18441
> https://issues.apache.org/jira/browse/AMBARI-18441
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> My first upgrade test failed due to my environment issue. Since in real 
> production environment this failure would  occur again.
> 
> ambari upgrade to 2.1.1 and later version, if the first time failed , excute 
> ambari-server upgrade again will error duplicate key value violates unique 
> constraint "pk_hostcomponentstate".
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java
>  db13612 
> 
> Diff: https://reviews.apache.org/r/52155/diff/
> 
> 
> Testing
> ---
> 
> the unit test is UpgradeCatalog211Test.java: Process finished with exit code 
> 0.
> done !
> 
> 
> Thanks,
> 
> wang yaoxin
> 
>

Re: Review Request 53783: Suse11 deployment failures due to package issues

[Sid Wagle]

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


Ship it!




Ship It!

- Sid Wagle


On Nov. 15, 2016, 2:23 p.m., Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53783/
> ---
> 
> (Updated Nov. 15, 2016, 2:23 p.m.)
> 
> 
> Review request for Ambari, Aravindan Vijayan, Myroslav Papirkovskyy, Sid 
> Wagle, and Vitalyi Brodetskyi.
> 
> 
> Bugs: AMBARI-18896
> https://issues.apache.org/jira/browse/AMBARI-18896
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Suse 11 deployment failed due to
> 
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 303, in _call
> raise ExecutionFailed(err_msg, code, out, err)
> resource_management.core.exceptions.ExecutionFailed: Execution of 
> '/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm 
> ambari-metrics-monitor' returned 4. Problem: nothing provides python-kerberos 
> needed by ambari-metrics-monitor-2.5.0.0-283.x86_64
>  Solution 1: do not install ambari-metrics-monitor-2.5.0.0-283.x86_64
>  Solution 2: break ambari-metrics-monitor-2.5.0.0-283.x86_64 by ignoring some 
> of its dependencies
> 
> Choose from above solutions by number or cancel [1/2/c] (c): c
> 
> 
> Diffs
> -
> 
>   ambari-metrics/ambari-metrics-assembly/pom.xml cd45d35 
>   ambari-metrics/ambari-metrics-assembly/src/main/package/deb/control/prerm 
> f50d88a 
>   
> ambari-metrics/ambari-metrics-host-monitoring/conf/unix/ambari-metrics-monitor
>  220d533 
>   ambari-metrics/ambari-metrics-host-monitoring/pom.xml d6c1fab 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/package/rpm/preremove.sh
>  9789127 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/__init__.py
>  264a95d 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/MANIFEST.in
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/PKG-INFO
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/README.rst
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/PKG-INFO
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/SOURCES.txt
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/dependency_links.txt
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/top_level.txt
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/pysrc/kerberos.py
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/setup.cfg
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/setup.py
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/base64.h
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/base64.c
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberos.c
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosbasic.h
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosbasic.c
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosgss.h
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosgss.c
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberospw.h
>  PRE-CREATION 
>   
> ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberospw.c
>  PRE-CREATION 
>   ambari-metrics/ambari-metrics-host-monitoring/src/test/python/unitTests.py 
> 4ffaec8 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/ams.py
>  28aba35 
> 
> Diff: https://reviews.apache.org/r/53783/diff/
> 
> 
> Testing
> ---
> 
> Unit tests passed
> 
> [INFO] 
> [INFO] utility ... SUCCESS [1.123s]
> [INFO] ambari-metrics  SUCCESS [0.767s]
> [INFO] Ambari Metrics Common . SUCCESS [7.635s]
> [INFO] Ambari Metrics Hadoop Sink  SUCCESS [6.377s]
> [INFO] Ambari Metrics Flume Sink . SUCCESS [3.584s]
> [INFO] Ambari Metrics Kafka Sink 

Re: Review Request 53684: Fix for limiting the number of recommendations artifacts during stack advisor calls

[Madhuvanthi Radhakrishnan]

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

(Updated Nov. 15, 2016, 6:28 p.m.)


Review request for Ambari, Sumit Mohanty and Swapan Shridhar.


Changes
---

Added a small change to the StackAdvisorHelperTest.java in order to set a value 
for recommendations.artifacts.rollovermax and avoid Arithmetic exception at 
Test time.


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


Repository: ambari


Description
---

Applied logic for rolling over during creation of recommendations artifacts 
greater than a certain set limit.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelper.java
 e175c69 
  
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
 6cc4120 
  
ambari-server/src/test/java/org/apache/ambari/server/api/services/stackadvisor/StackAdvisorHelperTest.java
 5190dea 

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


Testing
---

1. Set the recommendations.artifacts.rollovermax = 5
Expected : Calls to stack advisor > 5 roll over starting from 0 again. Hence at 
any point of time there will be upto 5 folders only in 
/var/run/ambari-server/stack-recommendations
2. Do not set this value
Expected : Defaults to 100
3. Set the recommendations.artifacts.rollovermax = 0
Expected : Defaults to 100

On ambari-server restart, the ids are reset as before.


Thanks,

Madhuvanthi Radhakrishnan

Re: Review Request 53785: HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml

[Dmitro Lisnichenko]

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


Ship it!




Ship It!

- Dmitro Lisnichenko


On Nov. 15, 2016, 6:38 p.m., Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53785/
> ---
> 
> (Updated Nov. 15, 2016, 6:38 p.m.)
> 
> 
> Review request for Ambari, Dmitro Lisnichenko and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-18897
> https://issues.apache.org/jira/browse/AMBARI-18897
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> /etc/hbase/conf/ contains core-site.xml and hdfs-site.xml which should not be 
> needed at all. But more importantly, when we change a setting in Ambari, they 
> do not get reflected in the hdfs-site.xml that is under the hbase conf 
> directory. Since there are more than 1 core-site.xml in the classpath, this 
> obviously causes issues since the changed configs are not picked up.
> 
> 
> Diffs
> -
> 
>   
> ambari-common/src/main/python/resource_management/libraries/functions/constants.py
>  d1428d4 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
>  6f56512 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
>  93e7bdf 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py 
> cbc9066 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py 
> 5b77d3a 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py 
> a0e151f 
>   
> ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py 
> e4f5b2f 
> 
> Diff: https://reviews.apache.org/r/53785/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

Review Request 53793: Post Upgrade to Ambari 2.4.1 from 2.2.2 --> All stack component prompted for restart

[Dmitro Lisnichenko]

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

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


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


Repository: ambari


Description
---

I think not marking HDFS as restart required when Ambari upgrades is a good 
goal.

In general its a difficult to get it right for all services.
* hadoop.security.key.provider.path
* dfs.encryption.key.provider.uri

These two are removed by stack advisor when RANGER KMS does not exist. We 
should find out why it got added on Ambari upgrade. This seems like a bug to me.
* namenode_backup_dir


Diffs
-

  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
 afaaee8 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/core-site.xml
 846b09e 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/hdfs-site.xml
 aad524d 
  
ambari-server/src/main/resources/stacks/PHD/3.0/services/HDFS/configuration/core-site.xml
 4f18611 
  
ambari-server/src/main/resources/stacks/PHD/3.0/services/HDFS/configuration/hdfs-site.xml
 0fed58d 

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


Testing
---

Checked on cluster with Ranger installed. Upgraded Ambari 2.4.2->2.5.0 without 
these properties, services were able to stop/start without issues.


Thanks,

Dmitro Lisnichenko

Review Request 53788: HTTP responses needs to have the character encoding specified in the content type header

[Anita Jebaraj]

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

Review request for Ambari, Di Li, Robert Levas, and Sangeeta Ravindran.


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


Repository: ambari


Description
---

The charset information(UTF-8) can be added to all the response headers to 
harden the security for the client. When the charset information is not 
specified the web browser may choose a different encoding by guessing which 
encoding is actually being used by the web page.

This specific issue is mentioned in the section 3.1.1.5 of RFC7231


Diffs
-

  ambari-server/conf/unix/ambari.properties 371653f 
  ambari-server/conf/windows/ambari.properties e47319e 
  
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
 15f186b 
  
ambari-server/src/main/java/org/apache/ambari/server/security/AbstractSecurityHeaderFilter.java
 423a013 
  
ambari-server/src/main/java/org/apache/ambari/server/security/AmbariServerSecurityHeaderFilter.java
 aa00ac2 
  
ambari-server/src/main/java/org/apache/ambari/server/security/AmbariViewsSecurityHeaderFilter.java
 d1be8cc 
  
ambari-server/src/test/java/org/apache/ambari/server/security/AbstractSecurityHeaderFilterTest.java
 d812ee6 

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


Testing
---

Ran mvn test.

The test cases failing in hadoop QA is not related to the patch for this jira


Thanks,

Anita Jebaraj

Review Request 53786: Multiple kerberos name rules can not be set up for Ambari Infra Solr

[Miklos Gergely]

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

Review request for Ambari, Oliver Szabo, Robert Nettleton, and Sumit Mohanty.


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


Repository: ambari


Description
---

If multiple rules are entered into the proprety
Advanced infra-solr-env / Infra Solr Kerberos name rules
There are multiple issues here:
1. The rules should be escaped, the $ characters in them should be handled, so 
that the expressions in the rules like $0, $1 are not replaced with the script 
directory, and the script file name. Currently the user must do this in the 
value entered, which is not even documented.
2. The variable SOLR_KERB_NAME_RULES in infra-solr-env.sh should have quotes 
around it's value, so that the whole string is assigned to it, not only the 
first rule.
3. SOLR_KERB_NAME_RULES can not be the part of SOLR_AUTHENTICATION_OPTS, 
because it is handled incorrectly, if an expression like -Dname="value1 value2" 
is passed to the jvm from a bash variable. Therefore 
/usr/lib/ambari-infra-solr/bin/solr should be updated, and 
-Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES" should be added directly 
into the command script.
Options


Diffs
-

  ambari-logsearch/ambari-logsearch-assembly/pom.xml 3c18cba 
  ambari-logsearch/ambari-logsearch-assembly/src/main/resources/solr 
PRE-CREATION 
  
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py
 8bdf0a9 
  
ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-env.sh.j2
 8c24fa4 

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


Testing
---

Tested on local cluster.


Thanks,

Miklos Gergely

Review Request 53785: HBase conf directory should not have a copy of core-site.xml and hdfs-site.xml

[Vitalyi Brodetskyi]

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

Review request for Ambari.


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


Repository: ambari


Description
---

/etc/hbase/conf/ contains core-site.xml and hdfs-site.xml which should not be 
needed at all. But more importantly, when we change a setting in Ambari, they 
do not get reflected in the hdfs-site.xml that is under the hbase conf 
directory. Since there are more than 1 core-site.xml in the classpath, this 
obviously causes issues since the changed configs are not picked up.


Diffs
-

  
ambari-common/src/main/python/resource_management/libraries/functions/constants.py
 d1428d4 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
 6f56512 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
 93e7bdf 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py cbc9066 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py 5b77d3a 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py 
a0e151f 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py 
e4f5b2f 

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


Testing
---

mvn clean test


Thanks,

Vitalyi Brodetskyi

Re: Review Request 53678: AMBARI-18846 - Custom services should be able to easily specify their own dashboards

[Tim Thorpe]

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

(Updated Nov. 15, 2016, 4:16 p.m.)


Review request for Ambari, Aravindan Vijayan, Di Li, Jayush Luniya, and Sid 
Wagle.


Changes
---

Fixed problems with TestResourceFilesKeeper.py with 
test_update_directory_archive and test_zip_directory
Fixed problem with resourceFilesKeeper.py to avoid creating a zip if the 
dashboards directory doesn't exist


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


Repository: ambari


Description
---

Currently all dashboards are added directly in under the AMBARI_METRICS package 
directory (package/files/grafana-dashboards).

In order for custom services to add dashboards, they need to add the files 
directly under that folder. Each time the Ambari server is upgraded, those 
files will be lost as the AMBARI_METRICS service definition will be replaced.

This JIRA proposes adding a new directory under the ambari-server/resources. 
This will contain both the dashboards and metrics for custom services.

The dashboards here will not be organized by stack. Each service will add a 
directory containing their dashboards and will add a metrics file.

resources/dashboards/grafana-dashboards/MY_SERVICE/
resources/dashboards/service-metrics/MY_SERVICE.txt

The resources/dashboards directory will need to get sync'd to the agents.


Diffs (updated)
-

  ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py 
57416a4 
  ambari-agent/src/main/python/ambari_agent/FileCache.py b7c5dee 
  ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py 
c9724b7 
  ambari-agent/src/test/python/ambari_agent/TestFileCache.py 5933daa 
  ambari-server/src/main/python/ambari_server/resourceFilesKeeper.py f2a3ebd 
  ambari-server/src/main/python/ambari_server/serverConfiguration.py 04509cf 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana_util.py
 b98dc1d 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/params.py
 b052999 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/split_points.py
 aa03d197 
  ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py 
c7c3b2b 
  ambari-server/src/test/python/TestResourceFilesKeeper.py 966d3b1 

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


Testing
---

mvn clean test -Dtest=HostResourceProviderTest

Manually added custom service dashboard and metrics to 
resources/dashboards/grafana-dashboards and 
resources/dashboards/service-metrics respectively, verified they were sync'd to 
the agents and the dashboards appeared on the grafana UI.


Thanks,

Tim Thorpe

Re: Review Request 53678: AMBARI-18846 - Custom services should be able to easily specify their own dashboards

[Tim Thorpe]

> On Nov. 14, 2016, 7:56 p.m., Sid Wagle wrote:
> > ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/split_points.py,
> >  line 147
> > 
> >
> > Can we avoid code dup here by making it a common datastructure?
> 
> Sid Wagle wrote:
> Sorry for the late review on this, maybe you could address this in some 
> other patch, not a significant issue.
> 
> Tim Thorpe wrote:
> Hi Sid, I'll fix this in a separate JIRA.  Good catch.

Fixed this in the latest patch


- Tim


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


On Nov. 15, 2016, 4:16 p.m., Tim Thorpe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53678/
> ---
> 
> (Updated Nov. 15, 2016, 4:16 p.m.)
> 
> 
> Review request for Ambari, Aravindan Vijayan, Di Li, Jayush Luniya, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-18846
> https://issues.apache.org/jira/browse/AMBARI-18846
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Currently all dashboards are added directly in under the AMBARI_METRICS 
> package directory (package/files/grafana-dashboards).
> 
> In order for custom services to add dashboards, they need to add the files 
> directly under that folder. Each time the Ambari server is upgraded, those 
> files will be lost as the AMBARI_METRICS service definition will be replaced.
> 
> This JIRA proposes adding a new directory under the ambari-server/resources. 
> This will contain both the dashboards and metrics for custom services.
> 
> The dashboards here will not be organized by stack. Each service will add a 
> directory containing their dashboards and will add a metrics file.
> 
> resources/dashboards/grafana-dashboards/MY_SERVICE/
> resources/dashboards/service-metrics/MY_SERVICE.txt
> 
> The resources/dashboards directory will need to get sync'd to the agents.
> 
> 
> Diffs
> -
> 
>   ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py 
> 57416a4 
>   ambari-agent/src/main/python/ambari_agent/FileCache.py b7c5dee 
>   ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py 
> c9724b7 
>   ambari-agent/src/test/python/ambari_agent/TestFileCache.py 5933daa 
>   ambari-server/src/main/python/ambari_server/resourceFilesKeeper.py f2a3ebd 
>   ambari-server/src/main/python/ambari_server/serverConfiguration.py 04509cf 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana_util.py
>  b98dc1d 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/params.py
>  b052999 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/split_points.py
>  aa03d197 
>   ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py 
> c7c3b2b 
>   ambari-server/src/test/python/TestResourceFilesKeeper.py 966d3b1 
> 
> Diff: https://reviews.apache.org/r/53678/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test -Dtest=HostResourceProviderTest
> 
> Manually added custom service dashboard and metrics to 
> resources/dashboards/grafana-dashboards and 
> resources/dashboards/service-metrics respectively, verified they were sync'd 
> to the agents and the dashboards appeared on the grafana UI.
> 
> 
> Thanks,
> 
> Tim Thorpe
> 
>

Re: Review Request 53673: AMBARI-18852 HostCleanup.py to be able to stop processes owned by users or java processes

[Tim Thorpe]

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


Ship it!




Ship It!

- Tim Thorpe


On Nov. 15, 2016, 2:04 p.m., Di Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53673/
> ---
> 
> (Updated Nov. 15, 2016, 2:04 p.m.)
> 
> 
> Review request for Ambari and Tim Thorpe.
> 
> 
> Bugs: AMBARI-18852
> https://issues.apache.org/jira/browse/AMBARI-18852
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> a new feature to support stopping processes owned by users or java processes.
> 
> 
> Diffs
> -
> 
>   ambari-agent/src/main/python/ambari_agent/HostCleanup.py cca79a8 
>   ambari-agent/src/test/python/ambari_agent/TestHostCleanup.py 165c5f0 
> 
> Diff: https://reviews.apache.org/r/53673/diff/
> 
> 
> Testing
> ---
> 
> unit test
> patched a 2.5 cluster with the changes and run host cleanup with two .ini 
> files I created.
> 
> 
> Thanks,
> 
> Di Li
> 
>

Re: Review Request 53779: Post user creation hook takes kinit executable location from system variable

[Robert Levas]

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


Ship it!




Ship It!

- Robert Levas


On Nov. 15, 2016, 6:33 a.m., Laszlo Puskas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53779/
> ---
> 
> (Updated Nov. 15, 2016, 6:33 a.m.)
> 
> 
> Review request for Ambari, Robert Levas, Sandor Magyari, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18894
> https://issues.apache.org/jira/browse/AMBARI-18894
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Kinit executable location may differ from the defaults in various deployments.
> The post user creation hook takes the location from a system variable that 
> makes easy to customize the location.
> (validation of the location availability of the executable is underway)
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/scripts/post-user-creation-hook.sh 34169c1 
> 
> Diff: https://reviews.apache.org/r/53779/diff/
> 
> 
> Testing
> ---
> 
> Manually done on local env.
> 
> 
> Thanks,
> 
> Laszlo Puskas
> 
>

Re: Review Request 53779: Post user creation hook takes kinit executable location from system variable

[Robert Levas]

> On Nov. 15, 2016, 9:28 a.m., Robert Levas wrote:
> > ambari-server/src/main/resources/scripts/post-user-creation-hook.sh, line 54
> > 
> >
> > I think it would be better if Ambari passed in the search path to look 
> > for kinit rather than have the user set an environment variable.  What if 
> > the user forgets to set it?

I am dropping this issue given that this will eventually be replaced with 
something that works using the kinit path set in 
`kerberos-env/executable_search_paths`


- Robert


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


On Nov. 15, 2016, 6:33 a.m., Laszlo Puskas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53779/
> ---
> 
> (Updated Nov. 15, 2016, 6:33 a.m.)
> 
> 
> Review request for Ambari, Robert Levas, Sandor Magyari, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18894
> https://issues.apache.org/jira/browse/AMBARI-18894
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Kinit executable location may differ from the defaults in various deployments.
> The post user creation hook takes the location from a system variable that 
> makes easy to customize the location.
> (validation of the location availability of the executable is underway)
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/scripts/post-user-creation-hook.sh 34169c1 
> 
> Diff: https://reviews.apache.org/r/53779/diff/
> 
> 
> Testing
> ---
> 
> Manually done on local env.
> 
> 
> Thanks,
> 
> Laszlo Puskas
> 
>

Re: Review Request 53779: Post user creation hook takes kinit executable location from system variable

[Robert Levas]

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




ambari-server/src/main/resources/scripts/post-user-creation-hook.sh (line 54)


I think it would be better if Ambari passed in the search path to look for 
kinit rather than have the user set an environment variable.  What if the user 
forgets to set it?


- Robert Levas


On Nov. 15, 2016, 6:33 a.m., Laszlo Puskas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53779/
> ---
> 
> (Updated Nov. 15, 2016, 6:33 a.m.)
> 
> 
> Review request for Ambari, Robert Levas, Sandor Magyari, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18894
> https://issues.apache.org/jira/browse/AMBARI-18894
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Kinit executable location may differ from the defaults in various deployments.
> The post user creation hook takes the location from a system variable that 
> makes easy to customize the location.
> (validation of the location availability of the executable is underway)
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/scripts/post-user-creation-hook.sh 34169c1 
> 
> Diff: https://reviews.apache.org/r/53779/diff/
> 
> 
> Testing
> ---
> 
> Manually done on local env.
> 
> 
> Thanks,
> 
> Laszlo Puskas
> 
>

Re: Review Request 53728: KNOX/SSO support for Log Search (JWT based)

[Oliver Szabo]

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

(Updated Nov. 15, 2016, 2:31 p.m.)


Review request for Ambari, Miklos Gergely, Robert Nettleton, and Sumit Mohanty.


Changes
---

add smart configs and fix some small issues


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


Repository: ambari


Description
---

added JWT based authentication for Log Search.
Added a new filter with request matchers. Filter is executed after the original 
authentication filter is done wit the filtering, therfore its not needed to 
change anything on ambari server side (REST API)


Diffs (updated)
-

  ambari-logsearch/ambari-logsearch-portal/pom.xml be58732 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/AuthPropsConfig.java
 67ddd1f 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/SecurityConfig.java
 d3db110 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchJWTFilter.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchSecurityContextFormationFilter.java
 1320278 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchUsernamePasswordAuthenticationFilter.java
 85688a2 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/model/JWTAuthenticationToken.java
 PRE-CREATION 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
 febeffd 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/themes/theme.json
 2ed6474 
  ambari-web/app/data/HDP2/site_properties.js 5be3b5a 

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


Testing
---

testing done.


Thanks,

Oliver Szabo

Re: Review Request 53783: Suse11 deployment failures due to package issues

[Dmytro Sen]

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

(Updated Ноя. 15, 2016, 2:23 п.п.)


Review request for Ambari, Aravindan Vijayan, Myroslav Papirkovskyy, Sid Wagle, 
and Vitalyi Brodetskyi.


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


Repository: ambari


Description
---

Suse 11 deployment failed due to

  File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
line 303, in _call
raise ExecutionFailed(err_msg, code, out, err)
resource_management.core.exceptions.ExecutionFailed: Execution of 
'/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm 
ambari-metrics-monitor' returned 4. Problem: nothing provides python-kerberos 
needed by ambari-metrics-monitor-2.5.0.0-283.x86_64
 Solution 1: do not install ambari-metrics-monitor-2.5.0.0-283.x86_64
 Solution 2: break ambari-metrics-monitor-2.5.0.0-283.x86_64 by ignoring some 
of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): c


Diffs (updated)
-

  ambari-metrics/ambari-metrics-assembly/pom.xml cd45d35 
  ambari-metrics/ambari-metrics-assembly/src/main/package/deb/control/prerm 
f50d88a 
  
ambari-metrics/ambari-metrics-host-monitoring/conf/unix/ambari-metrics-monitor 
220d533 
  ambari-metrics/ambari-metrics-host-monitoring/pom.xml d6c1fab 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/package/rpm/preremove.sh 
9789127 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/__init__.py 
264a95d 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/MANIFEST.in
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/PKG-INFO 
PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/README.rst
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/PKG-INFO
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/SOURCES.txt
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/dependency_links.txt
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/top_level.txt
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/pysrc/kerberos.py
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/setup.cfg
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/setup.py 
PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/base64.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/base64.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberos.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosbasic.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosbasic.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosgss.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosgss.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberospw.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberospw.c
 PRE-CREATION 
  ambari-metrics/ambari-metrics-host-monitoring/src/test/python/unitTests.py 
4ffaec8 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/ams.py
 28aba35 

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


Testing
---

Unit tests passed

[INFO] 
[INFO] utility ... SUCCESS [1.123s]
[INFO] ambari-metrics  SUCCESS [0.767s]
[INFO] Ambari Metrics Common . SUCCESS [7.635s]
[INFO] Ambari Metrics Hadoop Sink  SUCCESS [6.377s]
[INFO] Ambari Metrics Flume Sink . SUCCESS [3.584s]
[INFO] Ambari Metrics Kafka Sink . SUCCESS [4.035s]
[INFO] Ambari Metrics Storm Sink . SUCCESS [2.883s]
[INFO] Ambari Metrics Storm Sink (Legacy)  SUCCESS [2.281s]
[INFO] Ambari Metrics Collector .. SUCCESS [5:52.858s]
[INFO] Ambari Metrics Monitor  SUCCESS [3.208s]
[INFO] Ambari Metrics Grafana  SUCCESS [11.910s]
[INFO] Ambari Metrics Assembly ... SUCCESS [2:48.073s]
[INFO] 

Re: Review Request 53727: Provide SSL related configurations for Ranger-Tagsync.

[Vishal Suvagia]

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

(Updated Nov. 15, 2016, 2:10 p.m.)


Review request for Ambari, Alejandro Fernandez, Gautam Borad, Jaimin Jetly, 
Jayush Luniya, Mugdha Varadkar, and Velmurugan Periasamy.


Changes
---

Request to wait for RR as will provide an updated patch.


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


Repository: ambari


Description (updated)
---

Request to wait for RR will upload a revised patch asap.
Need to provide ssl related configurations for Ranger-Tagsync service.


Diffs
-

  
ambari-common/src/main/python/resource_management/libraries/functions/constants.py
 d1428d4 
  
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
 6debaf1 
  
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/setup_ranger_xml.py
 6462495 
  
ambari-server/src/main/resources/stacks/HDP/2.0.6/properties/stack_features.json
 93e7bdf 
  
ambari-server/src/main/resources/stacks/HDP/2.6/services/RANGER/configuration/ranger-tagsync-policymgr-ssl.xml
 PRE-CREATION 
  
ambari-server/src/main/resources/stacks/HDP/2.6/services/RANGER/configuration/ranger-tagsync-site.xml
 PRE-CREATION 

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


Testing
---

Tested Ranger with Tagsync installation on CentOS 6.

Verified Unit-tests:

test_configure_secured (test_ranger_tagsync.TestRangerTagsync) ... 2016-11-14 
15:32:13,314 - Stack Feature Version Info: stack_version=2.5, 
version=2.5.0.0-801, current_cluster_version=2.5.0.0-801 -> 2.5.0.0-801
ok
test_start_default (test_ranger_tagsync.TestRangerTagsync) ... 2016-11-14 
15:32:13,333 - Stack Feature Version Info: stack_version=2.5, 
version=2.5.0.0-801, current_cluster_version=2.5.0.0-801 -> 2.5.0.0-801
ok
test_stop_default (test_ranger_tagsync.TestRangerTagsync) ... 2016-11-14 
15:32:13,350 - Stack Feature Version Info: stack_version=2.5, 
version=2.5.0.0-801, current_cluster_version=2.5.0.0-801 -> 2.5.0.0-801
ok


Thanks,

Vishal Suvagia

Re: Review Request 53673: AMBARI-18852 HostCleanup.py to be able to stop processes owned by users or java processes

[Di Li]

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

(Updated Nov. 15, 2016, 2:04 p.m.)


Review request for Ambari and Tim Thorpe.


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


Repository: ambari


Description
---

a new feature to support stopping processes owned by users or java processes.


Diffs (updated)
-

  ambari-agent/src/main/python/ambari_agent/HostCleanup.py cca79a8 
  ambari-agent/src/test/python/ambari_agent/TestHostCleanup.py 165c5f0 

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


Testing
---

unit test
patched a 2.5 cluster with the changes and run host cleanup with two .ini files 
I created.


Thanks,

Di Li

Re: Review Request 53742: Remaining components should be stack_select'ed for completeness

[Nate Cole]

> On Nov. 14, 2016, 5:11 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/HostOrderGrouping.java,
> >  line 191
> > 
> >
> > Actually, why is the python file name in the Java code and not in the 
> > upgrade pack?

This a great point.  The upgrade pack for a host-ordered group is very specific 
in the work it does.  I'll see if there's a way we can annotate the tasks that 
are currently built in code.  I'll make that a separate JIRA as we need to get 
things pushed and working first.


- Nate


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


On Nov. 14, 2016, 4:41 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53742/
> ---
> 
> (Updated Nov. 14, 2016, 4:41 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Duc Le.
> 
> 
> Bugs: AMBARI-18879
> https://issues.apache.org/jira/browse/AMBARI-18879
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When executing a HOST_ORDERED upgrade, the host should have "hdp-select set 
> all" run ONLY for that host.  This is similar to what we do during an RU 
> across all hosts after it's completed.  When the stack supports reimaging, 
> this step can be removed as the entire host would have ONLY the new version 
> anyway.
> 
> Made the host-group in the upgrade pack as skippable to allow a quick exit.  
> There was also some unused code in the AbstractUpgradeCatalog that shouldn't 
> be there.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/HostOrderGrouping.java
>  623fb76 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
>  86f5c8d 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/host-ordered-upgrade.xml
>  37b75b8 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
>  6b4b85a 
> 
> Diff: https://reviews.apache.org/r/53742/diff/
> 
> 
> Testing
> ---
> 
> Manual verification.  Automated pending.
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 53742: Remaining components should be stack_select'ed for completeness

[Nate Cole]

> On Nov. 14, 2016, 5:08 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/host-ordered-upgrade.xml,
> >  lines 84-86
> > 
> >
> > So, does this make every generated task skippable?

Yes


> On Nov. 14, 2016, 5:08 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/HostOrderGrouping.java,
> >  lines 192-193
> > 
> >
> > Yikes - I can just see this breaking if someone renamed/moves the file 
> > ... 
> > 
> > Can we make this a constant? Can we add a unit test to ensure that this 
> > file exists?

I'll pursue putting this in the upgrade pack in a separate jira.


- Nate


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


On Nov. 14, 2016, 4:41 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53742/
> ---
> 
> (Updated Nov. 14, 2016, 4:41 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Duc Le.
> 
> 
> Bugs: AMBARI-18879
> https://issues.apache.org/jira/browse/AMBARI-18879
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When executing a HOST_ORDERED upgrade, the host should have "hdp-select set 
> all" run ONLY for that host.  This is similar to what we do during an RU 
> across all hosts after it's completed.  When the stack supports reimaging, 
> this step can be removed as the entire host would have ONLY the new version 
> anyway.
> 
> Made the host-group in the upgrade pack as skippable to allow a quick exit.  
> There was also some unused code in the AbstractUpgradeCatalog that shouldn't 
> be there.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/HostOrderGrouping.java
>  623fb76 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
>  86f5c8d 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/host-ordered-upgrade.xml
>  37b75b8 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
>  6b4b85a 
> 
> Diff: https://reviews.apache.org/r/53742/diff/
> 
> 
> Testing
> ---
> 
> Manual verification.  Automated pending.
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 53742: Remaining components should be stack_select'ed for completeness

[Nate Cole]

> On Nov. 14, 2016, 5:18 p.m., Duc Le wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/HostOrderGrouping.java,
> >  line 191
> > 
> >
> > Will we save some time by doing this step accross all hosts in parallel 
> > like in RU?

Possibly - let me if that can be optimized in a separate JIRA.


- Nate


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


On Nov. 14, 2016, 4:41 p.m., Nate Cole wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53742/
> ---
> 
> (Updated Nov. 14, 2016, 4:41 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, and Duc Le.
> 
> 
> Bugs: AMBARI-18879
> https://issues.apache.org/jira/browse/AMBARI-18879
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> When executing a HOST_ORDERED upgrade, the host should have "hdp-select set 
> all" run ONLY for that host.  This is similar to what we do during an RU 
> across all hosts after it's completed.  When the stack supports reimaging, 
> this step can be removed as the entire host would have ONLY the new version 
> anyway.
> 
> Made the host-group in the upgrade pack as skippable to allow a quick exit.  
> There was also some unused code in the AbstractUpgradeCatalog that shouldn't 
> be there.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/upgrade/HostOrderGrouping.java
>  623fb76 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
>  86f5c8d 
>   
> ambari-server/src/main/resources/stacks/HDP/2.5/upgrades/host-ordered-upgrade.xml
>  37b75b8 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/UpgradeHelperTest.java
>  6b4b85a 
> 
> Diff: https://reviews.apache.org/r/53742/diff/
> 
> 
> Testing
> ---
> 
> Manual verification.  Automated pending.
> 
> 
> Thanks,
> 
> Nate Cole
> 
>

Re: Review Request 53725: AMBARI-18834 Add Ranger proxy user under Ranger KMS config during stack upgrade

[Jonathan Hurley]

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




ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml (lines 
139 - 144)


Are you sure this works? I don't think the XSD allows you to put an 
execute-stage in this location. 

I was actually referring to something like this:

```

  
  

  

```

You can scope the new group type to service="RANGER" component="RANGER_KMS"


- Jonathan Hurley


On Nov. 15, 2016, 1:43 a.m., Mugdha Varadkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53725/
> ---
> 
> (Updated Nov. 15, 2016, 1:43 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Gautam Borad, Jonathan 
> Hurley, and Velmurugan Periasamy.
> 
> 
> Bugs: AMBARI-18834
> https://issues.apache.org/jira/browse/AMBARI-18834
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Add below properties during stack upgrade to 2.5 in kerberos environment 
> under kms-site.xml
> 
> - hadoop.kms.proxyuser.[ranger].groups=*
> - hadoop.kms.proxyuser.[ranger].hosts=*
> - hadoop.kms.proxyuser.[ranger].users=*
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/RangerKmsProxyConfig.java
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.5.xml
>  04e4f3e 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/nonrolling-upgrade-2.6.xml
>  3233f7e 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.5.xml 
> 95c5f06 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.6.xml 
> a01996a 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.5.xml
>  05e2be1 
>   
> ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/nonrolling-upgrade-2.6.xml
>  1a26e59 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.5.xml 
> f0c6131 
>   ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/upgrade-2.6.xml 
> f520faf 
>   
> ambari-server/src/test/java/org/apache/ambari/server/serveraction/upgrades/RangerKmsProxyConfigTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53725/diff/
> 
> 
> Testing
> ---
> 
> Tested EU from 2.4 to 2.5 stack in kerberos environment on centos 6.
> 
> 
> --
>  T E S T S
> ---
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support 
> was removed in 8.0
> Running 
> org.apache.ambari.server.serveraction.upgrades.RangerKmsProxyConfigTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.679 sec - 
> in org.apache.ambari.server.serveraction.upgrades.RangerKmsProxyConfigTest
> 
> Results :
> 
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> 
> 
> Thanks,
> 
> Mugdha Varadkar
> 
>

Re: Review Request 53779: Post user creation hook takes kinit executable location from system variable

[Sebastian Toader]

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


Ship it!




Ship It!

- Sebastian Toader


On Nov. 15, 2016, 12:33 p.m., Laszlo Puskas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53779/
> ---
> 
> (Updated Nov. 15, 2016, 12:33 p.m.)
> 
> 
> Review request for Ambari, Robert Levas, Sandor Magyari, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18894
> https://issues.apache.org/jira/browse/AMBARI-18894
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Kinit executable location may differ from the defaults in various deployments.
> The post user creation hook takes the location from a system variable that 
> makes easy to customize the location.
> (validation of the location availability of the executable is underway)
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/scripts/post-user-creation-hook.sh 34169c1 
> 
> Diff: https://reviews.apache.org/r/53779/diff/
> 
> 
> Testing
> ---
> 
> Manually done on local env.
> 
> 
> Thanks,
> 
> Laszlo Puskas
> 
>

Review Request 53783: Suse11 deployment failures due to package issues

[Dmytro Sen]

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

Review request for Ambari, Aravindan Vijayan, Myroslav Papirkovskyy, Sid Wagle, 
and Vitalyi Brodetskyi.


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


Repository: ambari


Description
---

Suse 11 deployment failed due to

  File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
line 303, in _call
raise ExecutionFailed(err_msg, code, out, err)
resource_management.core.exceptions.ExecutionFailed: Execution of 
'/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm 
ambari-metrics-monitor' returned 4. Problem: nothing provides python-kerberos 
needed by ambari-metrics-monitor-2.5.0.0-283.x86_64
 Solution 1: do not install ambari-metrics-monitor-2.5.0.0-283.x86_64
 Solution 2: break ambari-metrics-monitor-2.5.0.0-283.x86_64 by ignoring some 
of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): c


Diffs
-

  ambari-metrics/ambari-metrics-assembly/pom.xml cd45d35 
  ambari-metrics/ambari-metrics-assembly/src/main/package/deb/control/prerm 
f50d88a 
  
ambari-metrics/ambari-metrics-host-monitoring/conf/unix/ambari-metrics-monitor 
220d533 
  ambari-metrics/ambari-metrics-host-monitoring/pom.xml d6c1fab 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/package/rpm/preremove.sh 
9789127 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/__init__.py 
264a95d 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/MANIFEST.in
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/PKG-INFO 
PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/README.rst
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/PKG-INFO
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/SOURCES.txt
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/dependency_links.txt
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/kerberos.egg-info/top_level.txt
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/pysrc/kerberos.py
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/setup.cfg
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/setup.py 
PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/base64.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/base64.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberos.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosbasic.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosbasic.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosgss.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberosgss.c
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberospw.h
 PRE-CREATION 
  
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/kerberos/src/kerberospw.c
 PRE-CREATION 
  ambari-metrics/ambari-metrics-host-monitoring/src/test/python/unitTests.py 
4ffaec8 

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


Testing
---

Unit tests passed

[INFO] 
[INFO] utility ... SUCCESS [1.123s]
[INFO] ambari-metrics  SUCCESS [0.767s]
[INFO] Ambari Metrics Common . SUCCESS [7.635s]
[INFO] Ambari Metrics Hadoop Sink  SUCCESS [6.377s]
[INFO] Ambari Metrics Flume Sink . SUCCESS [3.584s]
[INFO] Ambari Metrics Kafka Sink . SUCCESS [4.035s]
[INFO] Ambari Metrics Storm Sink . SUCCESS [2.883s]
[INFO] Ambari Metrics Storm Sink (Legacy)  SUCCESS [2.281s]
[INFO] Ambari Metrics Collector .. SUCCESS [5:52.858s]
[INFO] Ambari Metrics Monitor  SUCCESS [3.208s]
[INFO] Ambari Metrics Grafana  SUCCESS [11.910s]
[INFO] Ambari Metrics Assembly ... SUCCESS [2:48.073s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 9:24.932s
[INFO] Finished 

Review Request 53780: create separate RPM / DEB package for views during build process.

[Nitiraj Rathore]

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

Review request for Ambari, DIPAYAN BHOWMICK, Gaurav Nagar, Pallav Kulshreshtha, 
Prabhjyot Singh, Rohit Choudhary, Renjith Kamath, and Ashwin Rajeev.


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


Repository: ambari


Description
---

Earlier : view jars were shipped with the ambari-server package. 
Now : separate rpm and deb files can be created 
(ambari-views-package_$VERSION.deb, ambari-views-package-$VERSION.x86_64.rpm) 
which can be shipped and installed separately.

each view (module) in contrib/views can copy its jar into the parent 
(ambari-contrib-view project) target/views-jars folder and when mvn runs in 
ambari-views-package, it creates an RPM and DEB file packaging all the jars.

created RPM location : 
$AMBARI/contrib/views/ambari-views-package/target/rpm/ambari-views-package/RPMS/x86_64/ambari-views-package-2.5.0.0-0.x86_64.rpm
create DEB location : 
$AMBARI/contrib/views/ambari-views-package/target/ambari-views-package_2.5.0.0-0.deb

The order of module ambari-views-package in pom.xml of ambari-contrib-views 
should be last as it will create the package.

command to create deb and rpm
$ cd $AMBARI/contrib/views
$ mvn clean package rpm:rpm jdeb:jdeb install


Diffs
-

  contrib/views/ambari-views-package/pom.xml PRE-CREATION 
  contrib/views/ambari-views-package/src/main/package/deb/control/control 
PRE-CREATION 
  contrib/views/capacity-scheduler/pom.xml 7b7cdc9 
  contrib/views/files/pom.xml 67beef9 
  contrib/views/hawq/pom.xml 4fc543f 
  contrib/views/hive-next/pom.xml 46deaf3 
  contrib/views/hive/pom.xml 2814049 
  contrib/views/hueambarimigration/pom.xml 21837c3 
  contrib/views/jobs/pom.xml 8460c5b 
  contrib/views/pig/pom.xml d2aada7 
  contrib/views/pom.xml 94f8421 
  contrib/views/slider/pom.xml 0ddcb84 
  contrib/views/storm/pom.xml 38ec8ba 
  contrib/views/tez/pom.xml 26b0c49 
  contrib/views/wfmanager/pom.xml e03e656 
  contrib/views/zeppelin/pom.xml 52efdce 

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


Testing
---

manual testing of creation of


Thanks,

Nitiraj Rathore

Re: Review Request 53734: Ambari change hcat.proxy.hosts value during add service

[Dmitro Lisnichenko]

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

(Updated Nov. 15, 2016, 1:08 p.m.)


Review request for Ambari, Robert Levas and Vitalyi Brodetskyi.


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


Repository: ambari


Description
---

Whenever user adds service to Ambari, the value "hadoop.proxyuser.hcat.hosts" 
got changed. We should either prompt user if he is comfortable with the 
changes, or let it alone. In customer environment, this values got changed to 
something different when he adds Accumulo, Kafka and Knox.

After the initial install, the property hadoop.proxyuser.hcat.hosts = '*'
Then, Accumulo was installed using the Ambari Add Service Wizard. After 
Accumulo was installed, the value of hadoop.proxyuser.hcat.hosts was 
'baron2.example.org' (FQDN of second master node)
Then, Kafka was added using the Ambari Add Service Wizard. After Kafka was 
installed, the value of hadoop.proxyuser.hcat.hosts was 
"baron1.example.org,baron2.example.org".
Then Knox was added using the Ambari Add Service Wizard. After Knox was 
installed, the value of hadoop.proxyuser.hcat.hosts was 'baron1.example.org'. 
At this point the Hive Service Check failed with an "Unauthorized connection 
for super-user: hcat" error. "

In the support lab, value was set to hcat host after cluster installation. I 
changed it to * to match customer environments, and every time I add services 
it changed it back to hcat host

BUSINESS IMPACT: If customer is using Ambari view or Hue, changing this 
configuration will break them


Diffs (updated)
-

  ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py 
ee63f1e 
  ambari-server/src/test/python/stacks/2.0.6/common/test_stack_advisor.py 
125c9ca 

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


Testing
---

mvn clean test


Thanks,

Dmitro Lisnichenko

Re: Review Request 53778: Oozie config not shown as stale upon changing DefaultFS

[Sandor Magyari]

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


Ship it!




Ship It!

- Sandor Magyari


On Nov. 15, 2016, 10:06 a.m., Sebastian Toader wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53778/
> ---
> 
> (Updated Nov. 15, 2016, 10:06 a.m.)
> 
> 
> Review request for Ambari, Attila Doroszlai, Attila Magyar, Balázs Bence 
> Sári, Laszlo Puskas, and Sandor Magyari.
> 
> 
> Bugs: AMBARI-18891
> https://issues.apache.org/jira/browse/AMBARI-18891
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added core-site config type as a dependency for oozie. This ensures that 
> whenever core-site is changed oozie will be flaged as having stale configs as 
> well indicating that a restart is needed as some of the configs it uses has 
> changed.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/metainfo.xml 
> 66d272a 
> 
> Diff: https://reviews.apache.org/r/53778/diff/
> 
> 
> Testing
> ---
> 
> Manual testing.
> 
> Unit tests:
> there is only one failure which is not related to this change.
> 
> Failed tests:
> FAIL: test_update_directory_archive 
> (TestResourceFilesKeeper.TestResourceFilesKeeper)
> --
> Traceback (most recent call last):
>   File 
> "/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-common/src/test/python/mock/mock.py",
>  line 1199, in patched
> return func(*args, **keywargs)
>   File 
> "/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-server/src/test/python/TestResourceFilesKeeper.py",
>  line 191, in test_update_directory_archive
> self.assertTrue(write_hash_sum_mock.called)
> AssertionError: False is not true
> 
> 
> Thanks,
> 
> Sebastian Toader
> 
>

Re: Review Request 53778: Oozie config not shown as stale upon changing DefaultFS

[Balázs Bence Sári]

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


Ship it!




Ship It!

- Balázs Bence Sári


On Nov. 15, 2016, 10:06 a.m., Sebastian Toader wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53778/
> ---
> 
> (Updated Nov. 15, 2016, 10:06 a.m.)
> 
> 
> Review request for Ambari, Attila Doroszlai, Attila Magyar, Balázs Bence 
> Sári, Laszlo Puskas, and Sandor Magyari.
> 
> 
> Bugs: AMBARI-18891
> https://issues.apache.org/jira/browse/AMBARI-18891
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added core-site config type as a dependency for oozie. This ensures that 
> whenever core-site is changed oozie will be flaged as having stale configs as 
> well indicating that a restart is needed as some of the configs it uses has 
> changed.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/metainfo.xml 
> 66d272a 
> 
> Diff: https://reviews.apache.org/r/53778/diff/
> 
> 
> Testing
> ---
> 
> Manual testing.
> 
> Unit tests:
> there is only one failure which is not related to this change.
> 
> Failed tests:
> FAIL: test_update_directory_archive 
> (TestResourceFilesKeeper.TestResourceFilesKeeper)
> --
> Traceback (most recent call last):
>   File 
> "/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-common/src/test/python/mock/mock.py",
>  line 1199, in patched
> return func(*args, **keywargs)
>   File 
> "/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-server/src/test/python/TestResourceFilesKeeper.py",
>  line 191, in test_update_directory_archive
> self.assertTrue(write_hash_sum_mock.called)
> AssertionError: False is not true
> 
> 
> Thanks,
> 
> Sebastian Toader
> 
>

Re: Review Request 53778: Oozie config not shown as stale upon changing DefaultFS

[Laszlo Puskas]

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


Ship it!




Ship It!

- Laszlo Puskas


On Nov. 15, 2016, 10:06 a.m., Sebastian Toader wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53778/
> ---
> 
> (Updated Nov. 15, 2016, 10:06 a.m.)
> 
> 
> Review request for Ambari, Attila Doroszlai, Attila Magyar, Balázs Bence 
> Sári, Laszlo Puskas, and Sandor Magyari.
> 
> 
> Bugs: AMBARI-18891
> https://issues.apache.org/jira/browse/AMBARI-18891
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added core-site config type as a dependency for oozie. This ensures that 
> whenever core-site is changed oozie will be flaged as having stale configs as 
> well indicating that a restart is needed as some of the configs it uses has 
> changed.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/metainfo.xml 
> 66d272a 
> 
> Diff: https://reviews.apache.org/r/53778/diff/
> 
> 
> Testing
> ---
> 
> Manual testing.
> 
> Unit tests:
> there is only one failure which is not related to this change.
> 
> Failed tests:
> FAIL: test_update_directory_archive 
> (TestResourceFilesKeeper.TestResourceFilesKeeper)
> --
> Traceback (most recent call last):
>   File 
> "/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-common/src/test/python/mock/mock.py",
>  line 1199, in patched
> return func(*args, **keywargs)
>   File 
> "/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-server/src/test/python/TestResourceFilesKeeper.py",
>  line 191, in test_update_directory_archive
> self.assertTrue(write_hash_sum_mock.called)
> AssertionError: False is not true
> 
> 
> Thanks,
> 
> Sebastian Toader
> 
>

Re: Review Request 53728: KNOX/SSO support for Log Search (JWT based)

[Oliver Szabo]

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

(Updated Nov. 15, 2016, 10:42 a.m.)


Review request for Ambari, Miklos Gergely, Robert Nettleton, and Sumit Mohanty.


Changes
---

put back removed property


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


Repository: ambari


Description
---

added JWT based authentication for Log Search.
Added a new filter with request matchers. Filter is executed after the original 
authentication filter is done wit the filtering, therfore its not needed to 
change anything on ambari server side (REST API)


Diffs (updated)
-

  ambari-logsearch/ambari-logsearch-portal/pom.xml be58732 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/AuthPropsConfig.java
 67ddd1f 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/conf/SecurityConfig.java
 d3db110 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchJWTFilter.java
 PRE-CREATION 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchSecurityContextFormationFilter.java
 1320278 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/filters/LogsearchUsernamePasswordAuthenticationFilter.java
 85688a2 
  
ambari-logsearch/ambari-logsearch-portal/src/main/java/org/apache/ambari/logsearch/web/model/JWTAuthenticationToken.java
 PRE-CREATION 
  
ambari-server/src/main/resources/common-services/LOGSEARCH/0.5.0/configuration/logsearch-properties.xml
 febeffd 
  ambari-web/app/data/HDP2/site_properties.js 5be3b5a 

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


Testing
---

testing done.


Thanks,

Oliver Szabo

Re: Review Request 53674: AMBARI-18857 : Add Service wizard: Storm site configs related to Ambari metrics service are not displayed on ui

[Dmytro Sen]

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




ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py (line 
120)


This method overrides 2.0.6/stack_advisor.py.validateStormConfigurations() 

As a first statement, we should do something like 
super(HDP206StackAdvisor, self).validateStormConfigurations()


- Dmytro Sen


On Ноя. 11, 2016, 3:52 п.п., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53674/
> ---
> 
> (Updated Ноя. 11, 2016, 3:52 п.п.)
> 
> 
> Review request for Ambari, Dmytro Sen, Jaimin Jetly, Sumit Mohanty, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-18857
> https://issues.apache.org/jira/browse/AMBARI-18857
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This issue is result of storm site being scattered between Storm service and 
> AMS service. 
> It is highly recommended to avoid such scattering of config sites across 
> services. Doing so requires special handling on FE and generates lots of new 
> flows that needs to be tested. storm site should only belong and be packaged 
> inside Storm service. If there are some configs of storm-site that needs to 
> be added if AMS is present then stack advisor can be leveraged to achieve 
> that objective
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/storm-site.xml
>  7059b90 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/metainfo.xml
>  059b2b6 
>   
> ambari-server/src/main/resources/common-services/STORM/1.0.1/configuration/storm-site.xml
>  077590a 
>   ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py 
> f9a3a9a 
>   ambari-server/src/test/python/stacks/2.5/common/test_stack_advisor.py 
> 7124307 
> 
> Diff: https://reviews.apache.org/r/53674/diff/
> 
> 
> Testing
> ---
> 
> Manually tested.
> Python unit tests pass.
> Java Unit tests pending.
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Review Request 53778: Oozie config not shown as stale upon changing DefaultFS

[Sebastian Toader]

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

Review request for Ambari, Attila Doroszlai, Attila Magyar, Balázs Bence Sári, 
Laszlo Puskas, and Sandor Magyari.


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


Repository: ambari


Description
---

Added core-site config type as a dependency for oozie. This ensures that 
whenever core-site is changed oozie will be flaged as having stale configs as 
well indicating that a restart is needed as some of the configs it uses has 
changed.


Diffs
-

  ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/metainfo.xml 
66d272a 

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


Testing
---

Manual testing.

Unit tests:
there is only one failure which is not related to this change.

Failed tests:
FAIL: test_update_directory_archive 
(TestResourceFilesKeeper.TestResourceFilesKeeper)
--
Traceback (most recent call last):
  File 
"/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-common/src/test/python/mock/mock.py",
 line 1199, in patched
return func(*args, **keywargs)
  File 
"/Users/stoader/Projects/Hortonworks/apache/ambari/ambari-server/src/test/python/TestResourceFilesKeeper.py",
 line 191, in test_update_directory_archive
self.assertTrue(write_hash_sum_mock.called)
AssertionError: False is not true


Thanks,

Sebastian Toader

Re: Review Request 52155: ambari server upgrade ambari to 2.1.1 duplicate key error

[wang yaoxin]

> On 九月 27, 2016, 12:39 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java,
> >  lines 225-226
> > 
> >
> > This doesn't guarantee ordering of any kind - the first one which comes 
> > back could have an ID of 9. Since it doesn't match `m_hcsId`, this code 
> > would try to update it to to a value of 1 and possibly cause duplicates.
> > 
> > You can simply skip this whole section of updating if the 
> > `resultSet.getLong("id")` is non-null/non-zero. 
> > 
> > You can then so something like this:
> > `m_hcsId.set(NumberUtils.max(m_hcsId.get(), idKey)`

Hi Jonathan ,Thanks for your advice, that is highly appreciated. However, 
consider the randomness of the value of idKey, my method may avoid this issue. 
For instance, if the first-time get value of resultSet.getLong("id") is 2, and 
the second-time get value is 1, then basing on your method, the duplicates 
error would still occur. Hope we could get further agreement on this case, 
thanks.


- wang


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


On 九月 27, 2016, 12:03 p.m., wang yaoxin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52155/
> ---
> 
> (Updated 九月 27, 2016, 12:03 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Oliver Szabo, Robert Nettleton, 
> and Sebastian Toader.
> 
> 
> Bugs: AMBARI-18441
> https://issues.apache.org/jira/browse/AMBARI-18441
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> My first upgrade test failed due to my environment issue. Since in real 
> production environment this failure would  occur again.
> 
> ambari upgrade to 2.1.1 and later version, if the first time failed , excute 
> ambari-server upgrade again will error duplicate key value violates unique 
> constraint "pk_hostcomponentstate".
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog211.java
>  db13612 
> 
> Diff: https://reviews.apache.org/r/52155/diff/
> 
> 
> Testing
> ---
> 
> the unit test is UpgradeCatalog211Test.java: Process finished with exit code 
> 0.
> done !
> 
> 
> Thanks,
> 
> wang yaoxin
> 
>