Re: Review Request 59870: Part Two: Specify the script directly in alert target for script-based alert dispatchers

2017-06-07 Thread yao lei


> On 六月 8, 2017, 12:23 a.m., Richard Zang wrote:
> > Ship It!

Thank for your review.


- yao


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


On 六月 7, 2017, 4:34 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59870/
> ---
> 
> (Updated 六月 7, 2017, 4:34 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Richard Zang, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-21123
> https://issues.apache.org/jira/browse/AMBARI-21123
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Web Codes Part
> This patch amis to support creating alert target that inclueds property 
> ambari.dispatch-property.script.filename on web UI
> 
> More details, please see https://issues.apache.org/jira/browse/AMBARI-20739
> 
> 
> Diffs
> -
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  df15513 
>   ambari-web/app/messages.js 02a54f7 
>   ambari-web/app/templates/main/alerts/create_alert_notification.hbs 7ec5b1e 
>   ambari-web/app/utils/validator.js c069724 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  0d58afa 
> 
> 
> Diff: https://reviews.apache.org/r/59870/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-web & mvn test
>   21211 passing (33s)
>   128 pending
>   
> 2.Tested in a cluster
> 
> 
> File Attachments
> 
> 
> script_alert_notification_1.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/06/07/c77c5e4c-4d64-400a-8df9-11df1369e7fd__script_alert_notification_1.png
> script_alert_notification_2.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/06/07/1c230f27-4158-4ef4-90a8-483b3cfd4d52__script_alert_notification_2.png
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 59870: Part Two: Specify the script directly in alert target for script-based alert dispatchers

2017-06-06 Thread yao lei

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

Review request for Ambari, Alexandr Antonenko, Richard Zang, and Yusaku Sako.


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


Repository: ambari


Description
---

Web Codes Part
This patch amis to support creating alert target that inclueds property 
ambari.dispatch-property.script.filename on web UI

More details, please see https://issues.apache.org/jira/browse/AMBARI-20739


Diffs (updated)
-

  
ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js 
df15513 
  ambari-web/app/messages.js 02a54f7 
  ambari-web/app/templates/main/alerts/create_alert_notification.hbs 7ec5b1e 
  ambari-web/app/utils/validator.js c069724 
  
ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
 0d58afa 


Diff: https://reviews.apache.org/r/59870/diff/1/


Testing
---

1.cd ambari-web & mvn test
  21211 passing (33s)
  128 pending
  
2.Tested in a cluster


File Attachments


script_alert_notification_1.png
  
https://reviews.apache.org/media/uploaded/files/2017/06/07/c77c5e4c-4d64-400a-8df9-11df1369e7fd__script_alert_notification_1.png
script_alert_notification_2.png
  
https://reviews.apache.org/media/uploaded/files/2017/06/07/1c230f27-4158-4ef4-90a8-483b3cfd4d52__script_alert_notification_2.png


Thanks,

yao lei



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-06-06 Thread yao lei


> On 六月 1, 2017, 1:03 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
> > Lines 2708 (patched)
> > <https://reviews.apache.org/r/59440/diff/6/?file=1735247#file1735247line2708>
> >
> > Maybe make this a little clearer:
> > 
> > The directory for scripts which are used by the alert notification 
> > dispatcher.
> 
> yao lei wrote:
> Got it.
> I will make this change.
> 
> yao lei wrote:
> Hi Jonathan Hurley,
> Would you please commit this patch to trunk?
> Thanks.
> 
> Jonathan Hurley wrote:
> Done. Please close the review.

Thanks a lot


- yao


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


On 六月 2, 2017, 1:31 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59440/
> ---
> 
> (Updated 六月 2, 2017, 1:31 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, 
> and Tim Thorpe.
> 
> 
> Bugs: AMBARI-21122
> https://issues.apache.org/jira/browse/AMBARI-21122
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch will support using property 
> ambari.dispatch-property.script.filename in alert target to tell 
> AlertScriptDispatcher to lookup script by filename,default in  directory 
> /var/lib/ambari-server/resources/scripts. 
> 
> We can also change this directory in ambari.properties by 
> notification.dispatch.alert.script.directory property.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  114046f 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  84bfe52 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  f1f320d 
> 
> 
> Diff: https://reviews.apache.org/r/59440/diff/7/
> 
> 
> Testing
> ---
> 
> Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-06-05 Thread yao lei


> On 六月 5, 2017, 8:54 p.m., Richard Zang wrote:
> > Ship It!

Thanks for your review


- yao


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


On 六月 5, 2017, 10:28 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59485/
> ---
> 
> (Updated 六月 5, 2017, 10:28 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Richard Zang, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-21097
> https://issues.apache.org/jira/browse/AMBARI-21097
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Two Problems
> 
> Steps to reproduce problem one (see notifiction.png):
> 1.Open Alerts / Actions / Manage Alert Notifications
> 2.Create an alert notification named test
> 3.Select the created notification and click gear icon, you will find 
> Edit/Duplicate items are always grey but you can click and open a popup.
> 
> Steps to reproduce problem two(see notification-2.png):
> 1.Open Alerts / Actions / Manage Alert Notifications and delete all 
> notifications if exit
> 2.Firstly click the gear icon and then click Edit(Duplicate) item, some 
> errors will ouput in browser console.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/mappers/alert_notification_mapper.js 037c418 
>   ambari-web/app/models/alerts/alert_notification.js c2d7570 
>   ambari-web/app/templates/main/alerts/manage_alert_notifications_popup.hbs 
> da8faa8 
>   ambari-web/app/views/main/alerts/manage_alert_notifications_view.js aa05f86 
> 
> 
> Diff: https://reviews.apache.org/r/59485/diff/2/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-web  & mvn test
> 30383 passing (34s)
> 157 pending
> 
> 2.Tested in a cluster
> 
> 
> File Attachments
> 
> 
> notification-2.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/06/05/9c1d5973-8ced-4483-bdd3-e3d461c5dee2__notification-2.png
> notification.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/06/05/5ddcf172-e529-40ec-abe0-6c0cee83208f__notification.png
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-06-05 Thread yao lei


> On 六月 5, 2017, 6:21 p.m., Nate Cole wrote:
> > Ship It!

Thanks for your review


- yao


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


On 六月 2, 2017, 1:31 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59440/
> ---
> 
> (Updated 六月 2, 2017, 1:31 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, 
> and Tim Thorpe.
> 
> 
> Bugs: AMBARI-21122
> https://issues.apache.org/jira/browse/AMBARI-21122
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch will support using property 
> ambari.dispatch-property.script.filename in alert target to tell 
> AlertScriptDispatcher to lookup script by filename,default in  directory 
> /var/lib/ambari-server/resources/scripts. 
> 
> We can also change this directory in ambari.properties by 
> notification.dispatch.alert.script.directory property.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  114046f 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  84bfe52 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  f1f320d 
> 
> 
> Diff: https://reviews.apache.org/r/59440/diff/7/
> 
> 
> Testing
> ---
> 
> Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-06-05 Thread yao lei

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

(Updated June 5, 2017, 10:28 a.m.)


Review request for Ambari, Alexandr Antonenko, Richard Zang, and Yusaku Sako.


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


Repository: ambari


Description (updated)
---

Two Problems

Steps to reproduce problem one (see notifiction.png):
1.Open Alerts / Actions / Manage Alert Notifications
2.Create an alert notification named test
3.Select the created notification and click gear icon, you will find 
Edit/Duplicate items are always grey but you can click and open a popup.

Steps to reproduce problem two(see notification-2.png):
1.Open Alerts / Actions / Manage Alert Notifications and delete all 
notifications if exit
2.Firstly click the gear icon and then click Edit(Duplicate) item, some errors 
will ouput in browser console.


Diffs (updated)
-

  ambari-web/app/mappers/alert_notification_mapper.js 037c418 
  ambari-web/app/models/alerts/alert_notification.js c2d7570 
  ambari-web/app/templates/main/alerts/manage_alert_notifications_popup.hbs 
da8faa8 
  ambari-web/app/views/main/alerts/manage_alert_notifications_view.js aa05f86 


Diff: https://reviews.apache.org/r/59485/diff/2/

Changes: https://reviews.apache.org/r/59485/diff/1-2/


Testing
---

1.cd ambari-web  & mvn test
30383 passing (34s)
157 pending

2.Tested in a cluster


File Attachments (updated)


notification-2.png
  
https://reviews.apache.org/media/uploaded/files/2017/06/05/9c1d5973-8ced-4483-bdd3-e3d461c5dee2__notification-2.png
notification.png
  
https://reviews.apache.org/media/uploaded/files/2017/06/05/5ddcf172-e529-40ec-abe0-6c0cee83208f__notification.png


Thanks,

yao lei



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-06-01 Thread yao lei

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

(Updated 六月 2, 2017, 1:31 a.m.)


Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, and 
Tim Thorpe.


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


Repository: ambari


Description
---

This patch will support using property ambari.dispatch-property.script.filename 
in alert target to tell AlertScriptDispatcher to lookup script by 
filename,default in  directory /var/lib/ambari-server/resources/scripts. 

We can also change this directory in ambari.properties by 
notification.dispatch.alert.script.directory property.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
 114046f 
  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 84bfe52 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 f1f320d 


Diff: https://reviews.apache.org/r/59440/diff/7/

Changes: https://reviews.apache.org/r/59440/diff/6-7/


Testing
---

Tested in a cluster


Thanks,

yao lei



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-06-01 Thread yao lei


> On 六月 1, 2017, 1:03 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
> > Lines 2708 (patched)
> > <https://reviews.apache.org/r/59440/diff/6/?file=1735247#file1735247line2708>
> >
> > Maybe make this a little clearer:
> > 
> > The directory for scripts which are used by the alert notification 
> > dispatcher.

Got it.
I will make this change.


- yao


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


On 六月 1, 2017, 1:37 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59440/
> ---
> 
> (Updated 六月 1, 2017, 1:37 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, 
> and Tim Thorpe.
> 
> 
> Bugs: AMBARI-21122
> https://issues.apache.org/jira/browse/AMBARI-21122
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch will support using property 
> ambari.dispatch-property.script.filename in alert target to tell 
> AlertScriptDispatcher to lookup script by filename,default in  directory 
> /var/lib/ambari-server/resources/scripts. 
> 
> We can also change this directory in ambari.properties by 
> notification.dispatch.alert.script.directory property.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  114046f 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  84bfe52 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  f1f320d 
> 
> 
> Diff: https://reviews.apache.org/r/59440/diff/6/
> 
> 
> Testing
> ---
> 
> Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-06-01 Thread yao lei


> On 六月 1, 2017, 12:10 p.m., Tim Thorpe wrote:
> > Ship It!

Thanks a lot


- yao


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


On 六月 1, 2017, 1:37 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59440/
> ---
> 
> (Updated 六月 1, 2017, 1:37 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, 
> and Tim Thorpe.
> 
> 
> Bugs: AMBARI-21122
> https://issues.apache.org/jira/browse/AMBARI-21122
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch will support using property 
> ambari.dispatch-property.script.filename in alert target to tell 
> AlertScriptDispatcher to lookup script by filename,default in  directory 
> /var/lib/ambari-server/resources/scripts. 
> 
> We can also change this directory in ambari.properties by 
> notification.dispatch.alert.script.directory property.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
>  114046f 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  84bfe52 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  f1f320d 
> 
> 
> Diff: https://reviews.apache.org/r/59440/diff/6/
> 
> 
> Testing
> ---
> 
> Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-05-30 Thread yao lei

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

(Updated May 31, 2017, 4:35 a.m.)


Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.


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


Repository: ambari


Description
---

This patch will support using property ambari.dispatch-property.script.filename 
in alert target to tell AlertScriptDispatcher to lookup script by 
filename,default in  directory /var/lib/ambari-server/resources/scripts. 

We can also change this directory in ambari.properties by 
notification.dispatch.alert.script.directory property.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
 114046f 
  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 84bfe52 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 f1f320d 


Diff: https://reviews.apache.org/r/59440/diff/4/

Changes: https://reviews.apache.org/r/59440/diff/3-4/


Testing
---

Tested in a cluster


Thanks,

yao lei



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-05-30 Thread yao lei


> On May 30, 2017, 3:28 p.m., Jonathan Hurley wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
> > Lines 83-86 (patched)
> > <https://reviews.apache.org/r/59440/diff/3/?file=1733068#file1733068line83>
> >
> > This should be specified in Configuration as a default property of a 
> > new key (similar to how other directories are specified)

Thanks a lot.
This is fixed in updated patch


- yao


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


On May 25, 2017, 6:02 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59440/
> ---
> 
> (Updated May 25, 2017, 6:02 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-21122
> https://issues.apache.org/jira/browse/AMBARI-21122
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This patch will support using property 
> ambari.dispatch-property.script.filename in alert target to tell 
> AlertScriptDispatcher to lookup script by filename,default in  directory 
> /var/lib/ambari-server/resources/scripts. 
> 
> We can also change this directory in ambari.properties by 
> notification.dispatch.alert.script.directory property.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  84bfe52 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  f1f320d 
> 
> 
> Diff: https://reviews.apache.org/r/59440/diff/3/
> 
> 
> Testing
> ---
> 
> Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-05-25 Thread yao lei

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

(Updated 五月 25, 2017, 12:29 p.m.)


Review request for Ambari, Alexandr Antonenko, Zhe (Joe) Wang, Richard Zang, 
and Yusaku Sako.


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


Repository: ambari


Description
---

STR:
1.Open Alerts / Actions / Manage Alert Notifications
2.Create an alert notification named test
3.Select the created notification and click gear icon, you will find 
Edit/Duplicate items are always grey but you can click and open a popup.


Diffs
-

  ambari-web/app/mappers/alert_notification_mapper.js 037c418 
  ambari-web/app/models/alerts/alert_notification.js c2d7570 


Diff: https://reviews.apache.org/r/59485/diff/1/


Testing
---

1.cd ambari-web  & mvn test
30383 passing (34s)
157 pending

2.Tested in a cluster


Thanks,

yao lei



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-05-25 Thread yao lei


> On 五月 23, 2017, 11:41 a.m., Alexandr Antonenko wrote:
> > Ship It!
> 
> yao lei wrote:
> Thanks for your review
> 
> yao lei wrote:
> Hi Alexandr Antonenko,
> Would you please commit this patch if you are free?
> Thanks.
> 
> Alexandr Antonenko wrote:
> in trunk this changes are already in their place, after commit 
> Ambari-18281 Expose Disabling of Alert Targets in Web Client (Vivek Ratnavel 
> Subramanian via zhewang)
> 
> as for 2.5 branch, 2.5.2 RC is out, so no commits to that branch (only 
> critical blockers)
> 
> yao lei wrote:
> I see.
> Thanks Alexandr.
> 
> Alexandr Antonenko wrote:
> once 2.5.2 will be out, and we will start working on 2.5.3 (so 2.5 branch 
> will be opened for commits). Let's push it there. If your goal is to fix this 
> for 2.5.3

Good. Please commit to 2.5.3


- yao


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


On 五月 23, 2017, 8:10 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59485/
> ---
> 
> (Updated 五月 23, 2017, 8:10 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Zhe (Joe) Wang, Richard Zang, 
> and Yusaku Sako.
> 
> 
> Bugs: AMBARI-21097
> https://issues.apache.org/jira/browse/AMBARI-21097
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> STR:
> 1.Open Alerts / Actions / Manage Alert Notifications
> 2.Create an alert notification named test
> 3.Select the created notification and click gear icon, you will find 
> Edit/Duplicate items are always grey but you can click and open a popup.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/mappers/alert_notification_mapper.js 037c418 
>   ambari-web/app/models/alerts/alert_notification.js c2d7570 
> 
> 
> Diff: https://reviews.apache.org/r/59485/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-web  & mvn test
> 30383 passing (34s)
> 157 pending
> 
> 2.Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-05-25 Thread yao lei


> On May 23, 2017, 11:41 a.m., Alexandr Antonenko wrote:
> > Ship It!
> 
> yao lei wrote:
> Thanks for your review
> 
> yao lei wrote:
> Hi Alexandr Antonenko,
> Would you please commit this patch if you are free?
> Thanks.
> 
> Alexandr Antonenko wrote:
> in trunk this changes are already in their place, after commit 
> Ambari-18281 Expose Disabling of Alert Targets in Web Client (Vivek Ratnavel 
> Subramanian via zhewang)
> 
> as for 2.5 branch, 2.5.2 RC is out, so no commits to that branch (only 
> critical blockers)

I see.
Thanks Alexandr.


- yao


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


On May 23, 2017, 8:10 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59485/
> ---
> 
> (Updated May 23, 2017, 8:10 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Zhe (Joe) Wang, Richard Zang, 
> and Yusaku Sako.
> 
> 
> Bugs: AMBARI-21097
> https://issues.apache.org/jira/browse/AMBARI-21097
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> STR:
> 1.Open Alerts / Actions / Manage Alert Notifications
> 2.Create an alert notification named test
> 3.Select the created notification and click gear icon, you will find 
> Edit/Duplicate items are always grey but you can click and open a popup.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/mappers/alert_notification_mapper.js 037c418 
>   ambari-web/app/models/alerts/alert_notification.js c2d7570 
> 
> 
> Diff: https://reviews.apache.org/r/59485/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-web  & mvn test
> 30383 passing (34s)
> 157 pending
> 
> 2.Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59440: Part One: Specify the script directly in alert target for script-based alert dispatchers

2017-05-25 Thread yao lei

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

(Updated 五月 25, 2017, 6:02 a.m.)


Review request for Ambari, Alejandro Fernandez and Jonathan Hurley.


Summary (updated)
-

Part One: Specify the script directly in alert target for script-based alert 
dispatchers


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


Repository: ambari


Description (updated)
---

Although we can create the alert target of type ALERT_SCRIPT by web 
ui(AMBARI-18423), we still need access to ambari.properties to add the new 
script and then restart ambari server to make this function take effect.
It is better specify the script directly in alert target rather than in 
ambari.properties.In this way,we also don't need to restart ambari server.

This patch will support using property ambari.dispatch-property.script.filename 
in alert target to tell AlertScriptDispatcher to lookup script by 
filename,default in /var/lib/ambari-server/resources/scripts directory. 
We can also change this directory in ambari.properties by 
ambari.dispatch-property.script.directory property.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 d65a11d 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 68e7d02 


Diff: https://reviews.apache.org/r/59440/diff/2/

Changes: https://reviews.apache.org/r/59440/diff/1-2/


Testing (updated)
---

Unit Tests
1.cd ambari-server & mvn test
  Results :
  Failed tests: 
 ExportBlueprintRequestTest.testExport_noConfigs:138 expected:<3> but 
was:<4>
  Tests run: 4990, Failures: 1, Errors: 0, Skipped: 39
 

Some Test Cases

Case 1:
a.Write a shell script named foo.sh and put it in the directory 
/var/lib/ambari-server/resources/scripts,its content is as following:

\#\!/bin/bash
logFile=/var/log/ambari-server/log_script_filename.log
definitionName=$1
definitionLabel=$2
serviceName=$3
alertState=$4 
alertText=$5
alertTimestamp=$6
hostname=$7
echo received $# parameters:  $definitionName, $definitionLabel, $serviceName, 
$alertState ,$alertText ,$alertTimestamp, $hostname  >> $logFile

b.Create an alert target of type ALERT_SCRIPT and set 
ambari.dispatch-property.script.filename=foo.sh.

Post api/v1/alert_targets
{"AlertTarget":{"name":"test","description":"","global":true,"notification_type":"ALERT_SCRIPT","alert_states":["OK","WARNING","CRITICAL","UNKNOWN"],"properties":{"ambari.dispatch-property.script.filename":"foo.sh"}}}

c.Stop or start any service , wait for a moment, we can see the log in 
/var/ambari-server/log_script_filename.log

Case 2:
a.Add 
ambari.dispatch-property.script.directory=/var/lib/ambari-server/resources/scripts/alerts
 to ambari.properties and move foo.sh to this directory.
b.Restart ambari-server and delete /var/ambari-server/log_script_filename.log
c.Stop or start any service, wait for a moment, we can see the log in 
/var/ambari-server/log_script_filename.log

Case 3:
a.Modify previous alert target and add 
ambari.dispatch-property.script=com.mycompany.dispatch.shell.script

PUT api/v1/alert_targets/:id
{"AlertTarget":{"name":"test","description":"","global":true,"notification_type":"ALERT_SCRIPT","alert_states":["OK","WARNING","CRITICAL","UNKNOWN"],"properties":{"ambari.dispatch-property.script":"com.mycompany.dispatch.shell.script","ambari.dispatch-property.script.filename":"foo.sh"}}}

b.Write a shell script named foo2.sh and put it in directory 
/var/lib/ambari-server/resources/scripts,its content is as following:

\#\!/bin/bash
logFile=/var/log/ambari-server/log_script_dispatch_property.log
definitionName=$1
definitionLabel=$2
serviceName=$3
alertState=$4 
alertText=$5
alertTimestamp=$6
hostname=$7

c.Add 
com.mycompany.dispatch.shell.script=/var/lib/ambari-server/resources/scripts/foo2.sh
 to ambari.properties.
d.Restart ambari-server and delete /var/ambari-server/log_script_filename.log
e.Stop or start any service,wait for a moment, we should see log in 
/var/ambari-server/log_script_filename.log and 
/var/log/ambari-server/log_script_dispatch_property.log is not existed.

Case 4:
a.Modify previous target and delete ambari.dispatch-property.script.filename

PUT api/v1/alert_targets/:id
{"AlertTarget":{"name":"test","description":"","global":true,"notification_type":"ALERT_SCRIPT","alert_states":["OK","WARNING","CRITICAL","UNKNOWN"],"properties":{"ambari.dispatch-property.script":"com.mycompany.dispatch.shell.script"}}}

b.Delete /var/ambari-server/log_script_filename.log
c.Stop or start any service , wait for a moment, we should see log in 
/var/log/ambari-server/log_script_dispatch_property.log and 
/var/ambari-server/log_script_filename.log is not existed any more.


Thanks,

yao lei



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-05-24 Thread yao lei


> On 五月 23, 2017, 11:41 a.m., Alexandr Antonenko wrote:
> > Ship It!
> 
> yao lei wrote:
> Thanks for your review

Hi Alexandr Antonenko,
Would you please commit this patch if you are free?
Thanks.


- yao


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


On 五月 23, 2017, 8:10 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59485/
> ---
> 
> (Updated 五月 23, 2017, 8:10 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Zhe (Joe) Wang, Richard Zang, 
> and Yusaku Sako.
> 
> 
> Bugs: AMBARI-21097
> https://issues.apache.org/jira/browse/AMBARI-21097
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> STR:
> 1.Open Alerts / Actions / Manage Alert Notifications
> 2.Create an alert notification named test
> 3.Select the created notification and click gear icon, you will find 
> Edit/Duplicate items are always grey but you can click and open a popup.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/mappers/alert_notification_mapper.js 037c418 
>   ambari-web/app/models/alerts/alert_notification.js c2d7570 
> 
> 
> Diff: https://reviews.apache.org/r/59485/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-web  & mvn test
> 30383 passing (34s)
> 157 pending
> 
> 2.Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-05-23 Thread yao lei


> On 五月 23, 2017, 11:41 a.m., Alexandr Antonenko wrote:
> > Ship It!

Thanks for your review


- yao


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


On 五月 23, 2017, 8:10 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59485/
> ---
> 
> (Updated 五月 23, 2017, 8:10 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Zhe (Joe) Wang, Richard Zang, 
> and Yusaku Sako.
> 
> 
> Bugs: AMBARI-21097
> https://issues.apache.org/jira/browse/AMBARI-21097
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> STR:
> 1.Open Alerts / Actions / Manage Alert Notifications
> 2.Create an alert notification named test
> 3.Select the created notification and click gear icon, you will find 
> Edit/Duplicate items are always grey but you can click and open a popup.
> 
> 
> Diffs
> -
> 
>   ambari-web/app/mappers/alert_notification_mapper.js 037c418 
>   ambari-web/app/models/alerts/alert_notification.js c2d7570 
> 
> 
> Diff: https://reviews.apache.org/r/59485/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-web  & mvn test
> 30383 passing (34s)
> 157 pending
> 
> 2.Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 59485: Edit notifications options are always grey but can click and open a popup

2017-05-23 Thread yao lei

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

Review request for Ambari, Alexandr Antonenko, Richard Zang, and Yusaku Sako.


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


Repository: ambari


Description
---

STR:
1.Open Alerts / Actions / Manage Alert Notifications
2.Create an alert notification named test
3.Select the created notification and click gear icon, you will find 
Edit/Duplicate items are always grey but you can click and open a popup.


Diffs
-

  ambari-web/app/mappers/alert_notification_mapper.js 037c418 
  ambari-web/app/models/alerts/alert_notification.js c2d7570 


Diff: https://reviews.apache.org/r/59485/diff/1/


Testing
---

1.cd ambari-web  & mvn test
30383 passing (34s)
157 pending

2.Tested in a cluster


Thanks,

yao lei



Review Request 59440: Specify the script directly in alert target for script-based alert dispatchers

2017-05-22 Thread yao lei

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

Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Richard Zang, 
and Yusaku Sako.


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


Repository: ambari


Description
---

Although we can create the alert target of type ALERT_SCRIPT by web ui, we 
still need access to ambari.properties to add the new script and then restart 
ambari server to make this function take effect.
It is better specify the script directly in alert target rather than in 
ambari.properties.In this way,we also don't need to restart ambari server.

So now on web ui we will two ways to configure the script location for 
script-based alert dispatchers:
1.By script dispatch property (ambari.dispatch-property.script).This is already 
supported in previous ambari release.
Please see 
https://cwiki.apache.org/confluence/display/AMBARI/Creating+a+Script-based+Alert+Dispatcher+-+2.4.0

2.By script filename(ambari.dispatch-property.script.filename).
This new way will lookup the script by filename in script directory,default in 
/var/lib/ambari-server/resources/scripts.
We can change the directory in ambari.properties by 
ambari.dispatch-property.script.directory property.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 d65a11d 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 68e7d02 
  
ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js 
df15513 
  ambari-web/app/messages.js 0c15a19 
  ambari-web/app/templates/main/alerts/create_alert_notification.hbs 7ec5b1e 
  ambari-web/app/utils/validator.js c069724 
  
ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
 0d58afa 


Diff: https://reviews.apache.org/r/59440/diff/1/


Testing
---

Unit Tests
1.cd ambari-web & mvn test
  21212 passing (32s)
  128 pending

2.cd ambari-server & mvn test
  Results :
  Failed tests: 
 ExportBlueprintRequestTest.testExport_noConfigs:138 expected:<3> but 
was:<4>
  Tests run: 4990, Failures: 1, Errors: 0, Skipped: 39
 

Test Cases

Case 1:
a.Write a shell script named foo.sh and put it in the directory 
/var/lib/ambari-server/resources/scripts,its content is as following:

#!/bin/bash
logFile=/var/log/ambari-server/log_script_filename.log
definitionName=$1
definitionLabel=$2
serviceName=$3
alertState=$4 
alertText=$5
alertTimestamp=$6
hostname=$7
echo received $# parameters:  $definitionName, $definitionLabel, $serviceName, 
$alertState ,$alertText ,$alertTimestamp, $hostname  >> $logFile

b.Create an alert target of type ALERT_SCRIPT on web ui and set Script Filename 
with foo.sh.
c.Stop or start any service , wait for a moment, we can see the log in 
/var/ambari-server/log_script_filename.log


Case 2:
a.Add 
ambari.dispatch-property.script.directory=/var/lib/ambari-server/resources/scripts/alerts
 to ambari.properties and move foo.sh to this directory.
b.Restart ambari-server and delete /var/ambari-server/log_script_filename.log
c.Stop or start any service, wait for a moment, we can see the log in 
/var/ambari-server/log_script_filename.log


Case 3:
a.Modify previous alert target on web ui and set Script Dispatch Property with  
com.mycompany.dispatch.shell.script
b.Write a shell script named foo2.sh and put it in directory 
/var/lib/ambari-server/resources/scripts too,its content is as following:

#!/bin/bash
logFile=/var/log/ambari-server/log_script_dispatch_property.log
definitionName=$1
definitionLabel=$2
serviceName=$3
alertState=$4 
alertText=$5
alertTimestamp=$6
hostname=$7

b.Add 
com.mycompany.dispatch.shell.script=/var/lib/ambari-server/resources/scripts/foo2.sh
 to ambari.properties.
c.Restart ambari-server and delete /var/ambari-server/log_script_filename.log
d.Stop or start any service,wait for a moment, we should see log in 
/var/ambari-server/log_script_filename.log and 
/var/log/ambari-server/log_script_dispatch_property.log is not exited.


Case 4:
a.Modify previous target and set Script Filename with empty
b.Delete /var/ambari-server/log_script_filename.log
c.Stop or start any service , wait for a moment, we should see log in 
/var/log/ambari-server/log_script_dispatch_property.log and 
/var/ambari-server/log_script_filename.log is not exited any more.


Thanks,

yao lei



Review Request 59256: RBAC:Ambari should be sensitve to the change of login user's permissions.

2017-05-13 Thread yao lei

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

Review request for Ambari, Alexandr Antonenko, Robert Levas, Richard Zang, and 
Yusaku Sako.


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


Repository: ambari


Description
---

Steps to reproduce:
1.Login ambari with ambari administrator role and create a user named Test on 
host A.
2.Assign service administrator role(or any other one of five roles) to this 
user Test.
3.On host B, login ambari with user Test .Now it plays as a service 
administrato role.
4.On host A, unassign the role of user Test , or change the role to another 
one, or even delete this user.
5.On host B, we will find the user Test can continue to operate ambari with 
previous permissions as a service administrator which actually have already 
changed by step 4.

Except for on two different hosts, we also can reproduce this problem between 
two different browsers on local host.

One solution:
Periodly schedule a task to update current user's authorization. If any error 
happens in this process, we should log off current user.


Diffs
-

  ambari-web/app/controllers/global/update_controller.js 8a3f984 
  ambari-web/app/utils/helper.js 4867c65 
  ambari-web/test/controllers/global/update_controller_test.js 2a9d020 


Diff: https://reviews.apache.org/r/59256/diff/1/


Testing
---

1.mvn test
  20691 passing (30s)
  128 pending
2.Tested in cluster


Thanks,

yao lei



Re: Review Request 59085: RBAC: Service Operator/Administrator Role don't have HOST.ADD_DELETE_COMPONENTS permission so we 'd better hide relevant buttons on Web UI

2017-05-09 Thread yao lei


> On 五月 9, 2017, 3:10 p.m., Robert Levas wrote:
> > Ship It!

Thanks for your review


- yao


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


On 五月 9, 2017, 9:49 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59085/
> ---
> 
> (Updated 五月 9, 2017, 9:49 a.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Robert Levas, and Richard Zang.
> 
> 
> Bugs: AMBARI-20961
> https://issues.apache.org/jira/browse/AMBARI-20961
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Steps to reproduce:
> 1.Create a user named test and assign Service Operator(Administrator) Role to 
> this user.
> 2.Login with this user and open Services -> Hive -> Service Actions, the menu 
> include highlight items : Add Hive Metastore and Add HiveServer2.
> Zookeeper,Hbase and other service also have the above issue.
> 
> Because Service Operator(Administrator) Role don't have 
> HOST.ADD_DELETE_COMPONENTS permission at all , we 'd better hide these buttons
> 
> 
> Diffs
> -
> 
>   ambari-web/app/views/main/service/item.js ac736a6 
> 
> 
> Diff: https://reviews.apache.org/r/59085/diff/2/
> 
> 
> Testing
> ---
> 
> 1.Create five users: test1 ,test2 ,test3 ,test4 ,test5  
> 2.Assign role Cluster User to test1,
>   Service Operator to test2,
>   Service Administrator to test3,
>   Cluster Operator to test4,
>   Cluster Administrator  to test5
> 3.Login with above users in sequence and find items of Service Actions shown 
> as expected
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 59085: RBAC: Service Operator/Administrator Role don't have HOST.ADD_DELETE_COMPONENTS permission so we 'd better hide relevant buttons on Web UI

2017-05-09 Thread yao lei

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

Review request for Ambari, Alexandr Antonenko, Robert Levas, and Richard Zang.


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


Repository: ambari


Description
---

Steps to reproduce:
1.Create a user named test and assign Service Operator(Administrator) Role to 
this user.
2.Login with this user and open Services -> Hive -> Service Actions, the menu 
include highlight items : Add Hive Metastore and Add HiveServer2.
Zookeeper,Hbase and other service also have the above issue.

Because Service Operator(Administrator) Role don't have 
HOST.ADD_DELETE_COMPONENTS permission at all , we 'd better hide these buttons


Diffs
-

  ambari-web/app/views/main/service/item.js ac736a6 


Diff: https://reviews.apache.org/r/59085/diff/1/


Testing
---

1.Create five users: test1 ,test2 ,test3 ,test4 ,test5  
2.Assign role Cluster User to test1?
  Service Operator to test2?
  Service Administrator to test3?
  Cluster Operator to test4?
  Cluster Administrator  to test5
3.Login with above users in sequence and find items of Service Actions shown as 
expected


Thanks,

yao lei



Re: Review Request 58256: Support creating/editing alert dispatch targets for script-based alert dispatchers by web wizard instead of command line

2017-04-11 Thread yao lei


> On 四月 11, 2017, 5:37 p.m., Alejandro Fernandez wrote:
> > ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
> > Line 170 (original), 175 (patched)
> > <https://reviews.apache.org/r/58256/diff/1/?file=1686353#file1686353line175>
> >
> > Insert a space after the comma

Thanks for your review


- yao


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


On 四月 12, 2017, 1 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58256/
> ---
> 
> (Updated 四月 12, 2017, 1 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Alexandr Antonenko, Andrii 
> Tkach, Di Li, Jaimin Jetly, Zhe (Joe) Wang, Matt, Nate Cole, Richard Zang, 
> and Yusaku Sako.
> 
> 
> Bugs: AMBARI-18423
> https://issues.apache.org/jira/browse/AMBARI-18423
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari now support creating/editing three kinds of alert dispatch targets by 
> web wizard, including EMAIL,SNMP,Custom SNMP.
> If we want to create another kind of alert dispatch target ALERT_SCRIPT for 
> script-based alert dispatcher,we have to execute a command manually like 
> following:
> {code}
> POST api/v1/alert_targets
> 
> {
>   "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": true
>   }
> }
> {code}
> or
> {code}
> POST api/v1/alert_targets
> 
> {
>   "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": false,
> "groups":[1,3]
> "alert_states":["WARNING","CRITICAL","UNKNOWN"],
> "properties": {
>   "ambari.dispatch-property.script": 
> "com.mycompany.dispatch.syslog.script"
> }
>   }
> }
> {code}
> More details, please see 
> https://cwiki.apache.org/confluence/display/AMBARI/Creating+a+Script-based+Alert+Dispatcher+-+2.4.0
> We should do this by web wizard rather than command line, which will lead to 
> more convenience
> We think it is really helpeful for us when using script-based alert 
> dispatcher.
> 
> 
> Diffs
> -----
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  73c19c6 
>   ambari-web/app/messages.js a2edf06 
>   ambari-web/app/templates/main/alerts/create_alert_notification.hbs 5b40bca 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  31da561 
> 
> 
> Diff: https://reviews.apache.org/r/58256/diff/2/
> 
> 
> Testing
> ---
> 
> mvn test
> 20676 passing (34s)
> 128 pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 58256: Support creating/editing alert dispatch targets for script-based alert dispatchers by web wizard instead of command line

2017-04-07 Thread yao lei


> On 四月 8, 2017, 3:06 a.m., Richard Zang wrote:
> > Ship It!

Thanks for your review.


- yao


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


On 四月 7, 2017, 2:16 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58256/
> ---
> 
> (Updated 四月 7, 2017, 2:16 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Alexandr Antonenko, Andrii 
> Tkach, Di Li, Jaimin Jetly, Zhe (Joe) Wang, Matt, Nate Cole, Richard Zang, 
> and Yusaku Sako.
> 
> 
> Bugs: AMBARI-18423
> https://issues.apache.org/jira/browse/AMBARI-18423
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari now support creating/editing three kinds of alert dispatch targets by 
> web wizard, including EMAIL,SNMP,Custom SNMP.
> If we want to create another kind of alert dispatch target ALERT_SCRIPT for 
> script-based alert dispatcher,we have to execute a command manually like 
> following:
> {code}
> POST api/v1/alert_targets
> 
> {
>   "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": true
>   }
> }
> {code}
> or
> {code}
> POST api/v1/alert_targets
> 
> {
>   "AlertTarget": {
> "name": "syslogger",
> "description": "Syslog Target",
> "notification_type": "ALERT_SCRIPT",
> "global": false,
> "groups":[1,3]
> "alert_states":["WARNING","CRITICAL","UNKNOWN"],
> "properties": {
>   "ambari.dispatch-property.script": 
> "com.mycompany.dispatch.syslog.script"
> }
>   }
> }
> {code}
> More details, please see 
> https://cwiki.apache.org/confluence/display/AMBARI/Creating+a+Script-based+Alert+Dispatcher+-+2.4.0
> We should do this by web wizard rather than command line, which will lead to 
> more convenience
> We think it is really helpeful for us when using script-based alert 
> dispatcher.
> 
> 
> Diffs
> -
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  73c19c6 
>   ambari-web/app/messages.js a2edf06 
>   ambari-web/app/templates/main/alerts/create_alert_notification.hbs 5b40bca 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  31da561 
> 
> 
> Diff: https://reviews.apache.org/r/58256/diff/1/
> 
> 
> Testing
> ---
> 
> mvn test
> 20676 passing (34s)
> 128 pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 58256: Support creating/editing alert dispatch targets for script-based alert dispatchers by web wizard instead of command line

2017-04-06 Thread yao lei

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

Review request for Ambari, Alejandro Fernandez, Alexandr Antonenko, Andrii 
Tkach, Di Li, Jaimin Jetly, Zhe (Joe) Wang, Matt, Nate Cole, Richard Zang, and 
Yusaku Sako.


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


Repository: ambari


Description
---

Ambari now support creating/editing three kinds of alert dispatch targets by 
web wizard, including EMAIL,SNMP,Custom SNMP.
If we want to create another kind of alert dispatch target ALERT_SCRIPT for 
script-based alert dispatcher,we have to execute a command manually like 
following:
{code}
POST api/v1/alert_targets

{
  "AlertTarget": {
"name": "syslogger",
"description": "Syslog Target",
"notification_type": "ALERT_SCRIPT",
"global": true
  }
}
{code}
or
{code}
POST api/v1/alert_targets

{
  "AlertTarget": {
"name": "syslogger",
"description": "Syslog Target",
"notification_type": "ALERT_SCRIPT",
"global": false,
"groups":[1,3]
"alert_states":["WARNING","CRITICAL","UNKNOWN"],
"properties": {
  "ambari.dispatch-property.script": 
"com.mycompany.dispatch.syslog.script"
}
  }
}
{code}
More details, please see 
https://cwiki.apache.org/confluence/display/AMBARI/Creating+a+Script-based+Alert+Dispatcher+-+2.4.0
We should do this by web wizard rather than command line, which will lead to 
more convenience
We think it is really helpeful for us when using script-based alert dispatcher.


Diffs
-

  
ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js 
73c19c6 
  ambari-web/app/messages.js a2edf06 
  ambari-web/app/templates/main/alerts/create_alert_notification.hbs 5b40bca 
  
ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
 31da561 


Diff: https://reviews.apache.org/r/58256/diff/1/


Testing
---

mvn test
20676 passing (34s)
128 pending


Thanks,

yao lei



Re: Review Request 57716: Ambari View examples phone-list-upgrade-view/phone-list-view cannot display normally

2017-03-27 Thread yao lei


> On 三月 27, 2017, 5:51 p.m., Alejandro Fernandez wrote:
> > ambari-views/examples/phone-list-upgrade-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
> > Lines 73 (patched)
> > <https://reviews.apache.org/r/57716/diff/1/?file=108#file108line73>
> >
> > I'm not familiar with this View. Is it now rendering the HTML instead 
> > of returning a text back?

Yes.It's very easy to verify by STR.
It is a Java Servlet problem essentially.
The browser don't know how to render the HTML codes returned by method doPost() 
in servlet.
We should specify the Content-Type explicitly in method doPost() just like 
doGet()


- yao


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


On 三月 17, 2017, 1:47 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57716/
> ---
> 
> (Updated 三月 17, 2017, 1:47 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, DIPAYAN BHOWMICK, Gaurav 
> Nagar, and Tom Beerbower.
> 
> 
> Bugs: AMBARI-20476
> https://issues.apache.org/jira/browse/AMBARI-20476
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Problem: 
> After adding/updating/deleting one record,the web page displays html code 
> directly as shown in attached pictures.
> 
> Steps to reproduce:
> 1.cd ambari-views/examples
> 2.cd phone-list-upgrade-view & mvn clean package
> 3.cd phone-list-view & mvn clean package
> 4.copy phone-list-upgrade-view/target/phone-list-upgrade-view-*.jar,
> phone-list-view/target/phone-list-view-*.jar 
> to /var/lib/ambari-server/resources/views
> 5.ambari-server restart
> 6.open the view and add/update/delete record.
> 
> Solution: add response header to method doPost() in PhoneListServlet.java
> 
> 
> Diffs
> -
> 
>   
> ambari-views/examples/phone-list-upgrade-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
>  6ed87cd 
>   
> ambari-views/examples/phone-list-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
>  146a8e3 
> 
> 
> Diff: https://reviews.apache.org/r/57716/diff/1/
> 
> 
> Testing
> ---
> 
> Tested in a cluster
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 57721: Custom properties of Alert Target are not reset after last Alert Target being created

2017-03-22 Thread yao lei


> On 三月 22, 2017, 9:02 p.m., Alexandr Antonenko wrote:
> > Ship It!

Thanks for your review.
Alexandr,Would you mind pushing them to where they want to go?


- yao


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


On 三月 22, 2017, 1:48 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57721/
> ---
> 
> (Updated 三月 22, 2017, 1:48 a.m.)
> 
> 
> Review request for Ambari, Andrii Babiichuk, Alexandr Antonenko, Andrii 
> Tkach, Denys Buzhor, Jaimin Jetly, Oleg Nechiporenko, and Richard Zang.
> 
> 
> Bugs: AMBARI-20484
> https://issues.apache.org/jira/browse/AMBARI-20484
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Steps to reproduce:
> 1.Open Alerts / Actions / Manage Notifications
> 2.Click + buttion and save a new alert target with any custom properties like 
> (a1,b1) and (a2,b2)
> 3.Click + buttion again,at the bottom of popup, you will still find the 
> custom properties which belong to the last alert target.
> 
> Solution:
> We should reset custom proepertis before creating a new Alert Target.
> 
> 
> Diffs
> -
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  f470f08 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  15b4da3 
> 
> 
> Diff: https://reviews.apache.org/r/57721/diff/1/
> 
> 
> Testing
> ---
> 
> mvn test
> 20580 passing (36s)
> 153 pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 57721: Custom properties of Alert Target are not reset after last Alert Target being created

2017-03-22 Thread yao lei


> On 三月 22, 2017, 6:12 p.m., Andrii Tkach wrote:
> > Ship It!

Thanks for your review


- yao


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


On 三月 22, 2017, 1:48 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57721/
> ---
> 
> (Updated 三月 22, 2017, 1:48 a.m.)
> 
> 
> Review request for Ambari, Andrii Babiichuk, Alexandr Antonenko, Andrii 
> Tkach, Denys Buzhor, Jaimin Jetly, Oleg Nechiporenko, and Richard Zang.
> 
> 
> Bugs: AMBARI-20484
> https://issues.apache.org/jira/browse/AMBARI-20484
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Steps to reproduce:
> 1.Open Alerts / Actions / Manage Notifications
> 2.Click + buttion and save a new alert target with any custom properties like 
> (a1,b1) and (a2,b2)
> 3.Click + buttion again,at the bottom of popup, you will still find the 
> custom properties which belong to the last alert target.
> 
> Solution:
> We should reset custom proepertis before creating a new Alert Target.
> 
> 
> Diffs
> -
> 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  f470f08 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  15b4da3 
> 
> 
> Diff: https://reviews.apache.org/r/57721/diff/1/
> 
> 
> Testing
> ---
> 
> mvn test
> 20580 passing (36s)
> 153 pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 57721: Custom properties of Alert Target are not reset after last Alert Target being created

2017-03-17 Thread yao lei

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

Review request for Ambari, Andrii Babiichuk, Alexandr Antonenko, Oleg 
Nechiporenko, and Richard Zang.


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


Repository: ambari


Description
---

Steps to reproduce:
1.Open Alerts / Actions / Manage Notifications
2.Click + buttion and save a new alert target with any custom properties like 
(a1,b1) and (a2,b2)
3.Click + buttion again,at the bottom of popup, you will still find the custom 
properties which belong to the last alert target.

Solution:
We should reset custom proepertis before creating a new Alert Target.


Diffs
-

  
ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js 
f470f08 
  
ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
 15b4da3 


Diff: https://reviews.apache.org/r/57721/diff/1/


Testing
---

mvn test
20580 passing (36s)
153 pending


Thanks,

yao lei



Re: Review Request 57716: Ambari View examples phone-list-upgrade-view/phone-list-view cannot display normally

2017-03-16 Thread yao lei

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

(Updated 三月 17, 2017, 1:47 a.m.)


Review request for Ambari, Alejandro Fernandez, DIPAYAN BHOWMICK, Gaurav Nagar, 
and Tom Beerbower.


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


Repository: ambari


Description (updated)
---

Problem: 
After adding/updating/deleting one record,the web page displays html code 
directly as shown in attached pictures.

Steps to reproduce:
1.cd ambari-views/examples
2.cd phone-list-upgrade-view & mvn clean package
3.cd phone-list-view & mvn clean package
4.copy phone-list-upgrade-view/target/phone-list-upgrade-view-*.jar,
phone-list-view/target/phone-list-view-*.jar 
to /var/lib/ambari-server/resources/views
5.ambari-server restart
6.open the view and add/update/delete record.

Solution: add response header to method doPost() in PhoneListServlet.java


Diffs
-

  
ambari-views/examples/phone-list-upgrade-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
 6ed87cd 
  
ambari-views/examples/phone-list-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
 146a8e3 


Diff: https://reviews.apache.org/r/57716/diff/1/


Testing
---

Tested in a cluster


Thanks,

yao lei



Review Request 57716: Ambari View examples phone-list-upgrade-view/phone-list-view cannot display normally

2017-03-16 Thread yao lei

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

Review request for Ambari, DIPAYAN BHOWMICK and Tom Beerbower.


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


Repository: ambari


Description
---

Problem: 
After adding/updating/deleting one record,the web page displays html code 
directly as shown in attached pictures.
Steps to reproduce:
1.cd ambari-views/examples
2.cd phone-list-upgrade-view & mvn clean package
3.cd phone-list-view & mvn clean package
4.copy phone-list-upgrade-view/target/phone-list-upgrade-view-*.jar,
phone-list-view/target/phone-list-view-*.jar 
to /var/lib/ambari-server/resources/views
5.ambari-server restart
6.open the view and add/update/delete record.
Solution: add response header to method doPost() in PhoneListServlet.java


Diffs
-

  
ambari-views/examples/phone-list-upgrade-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
 6ed87cd 
  
ambari-views/examples/phone-list-view/src/main/java/org/apache/ambari/view/phonelist/PhoneListServlet.java
 146a8e3 


Diff: https://reviews.apache.org/r/57716/diff/1/


Testing
---

Tested in a cluster


Thanks,

yao lei



Re: Review Request 57281: Script-Based Alert Dispathers support passing more parameters to script

2017-03-06 Thread yao lei


> On 三月 6, 2017, 2:21 p.m., Jonathan Hurley wrote:
> > Ship It!
> 
> yao lei wrote:
> Hi Jonathan,
> Thank you very much.
> Would you please help me to commit the patch to trunk if you are free?
> 
> Jonathan Hurley wrote:
> Yes, I'm just running a quick test on this patch locally and I'll commit 
> it shortly once it passes...
> 
> Jonathan Hurley wrote:
> Committed. Please close the review.

Thank you again.I will close it later


- yao


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


On 三月 3, 2017, 11:56 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57281/
> ---
> 
> (Updated 三月 3, 2017, 11:56 a.m.)
> 
> 
> Review request for Ambari and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-20291
> https://issues.apache.org/jira/browse/AMBARI-20291
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Script-Based Alert Dispatcher now pass five parameters to script,including 
> alert definition name, definition label,service name, alert state, and alert 
> text.
> But if script can receive other two parameters from dispather,it will be 
> better.
> 1.hostname.
> Because hostname the alert for is not always included in alert text,although 
> it may be null like aggregate alerts.
> With it we can more quick to find the related host that occured alert.
> 2.alert timestamp.
> We may need to know the alert occurrence time ( state change time) more 
> exactly. After the alert happened,it will spend some time to schedule the 
> script to run.
> Without it,we can only regard the script start time as the alert occurrence 
> time.
> 
> We now use this feature to send alert information to mobile phone and suggest 
> also passing hostname and alert timestamp.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/services/AlertNoticeDispatchService.java
>  174f31f 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  9e0e406 
> 
> 
> Diff: https://reviews.apache.org/r/57281/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-server
>mvn test
> 
> 2.write a python script to receive parameters from dispatcher
> 
> 
> #!/usr/bin/python
> import sys
> import logging
> 
> def main():
> definitionName = sys.argv[1]
> definitionLabel = sys.argv[2]
> serviceName = sys.argv[3]
> alertState = sys.argv[4]
> alertText = sys.argv[5]
> alertTimestamp = sys.argv[6]
> hostname = sys.argv[7] if len(sys.argv)-1 == 7 else None
> 
> logFile='/var/log/ambari-server/log_py.log'
> 
> logging.basicConfig(filename = logFile, level = logging.DEBUG)
> logging.debug('received ' + str(len(sys.argv)-1) + ' parameters')
> for i in range(1, len(sys.argv)):
> logging.debug('parameter ' +str(i) + ':' +str(sys.argv[i]))
> 
> if __name__ == '__main__':
>main()
> 
> 
> Stop and start any service like HDFS , we can see the expected result in 
> /var/log/ambari-server/log_py.log,
> 
> 3.write a shell script to  receive parameters from dispatcher
> 
> 
> #!/bin/bash
> logFile=/var/log/ambari-server/log_sh.log
> definitionName=$1
> definitionLabel=$2
> serviceName=$3
> alertState=$4 
> alertText=$5
> alertTimestamp=$6
> hostname=$7
> 
> echo received $# parameters:  $definitionName, $definitionLabel, 
> $serviceName, $alertState ,$alertText ,$alertTimestamp, $hostname  >> $logFile
> 
> 
> Stop and start any service like HDFS , we can see the expected result in 
> /var/ambari-server/log_sh.log, we can see the expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 57281: Script-Based Alert Dispathers support passing more parameters to script

2017-03-06 Thread yao lei


> On 三月 6, 2017, 2:21 p.m., Jonathan Hurley wrote:
> > Ship It!

Hi Jonathan,
Thank you very much.
Would you please help me to commit the patch to trunk if you are free?


- yao


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


On 三月 3, 2017, 11:56 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57281/
> ---
> 
> (Updated 三月 3, 2017, 11:56 a.m.)
> 
> 
> Review request for Ambari and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-20291
> https://issues.apache.org/jira/browse/AMBARI-20291
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Script-Based Alert Dispatcher now pass five parameters to script,including 
> alert definition name, definition label,service name, alert state, and alert 
> text.
> But if script can receive other two parameters from dispather,it will be 
> better.
> 1.hostname.
> Because hostname the alert for is not always included in alert text,although 
> it may be null like aggregate alerts.
> With it we can more quick to find the related host that occured alert.
> 2.alert timestamp.
> We may need to know the alert occurrence time ( state change time) more 
> exactly. After the alert happened,it will spend some time to schedule the 
> script to run.
> Without it,we can only regard the script start time as the alert occurrence 
> time.
> 
> We now use this feature to send alert information to mobile phone and suggest 
> also passing hostname and alert timestamp.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/services/AlertNoticeDispatchService.java
>  174f31f 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  9e0e406 
> 
> 
> Diff: https://reviews.apache.org/r/57281/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-server
>mvn test
> 
> 2.write a python script to receive parameters from dispatcher
> 
> 
> #!/usr/bin/python
> import sys
> import logging
> 
> def main():
> definitionName = sys.argv[1]
> definitionLabel = sys.argv[2]
> serviceName = sys.argv[3]
> alertState = sys.argv[4]
> alertText = sys.argv[5]
> alertTimestamp = sys.argv[6]
> hostname = sys.argv[7] if len(sys.argv)-1 == 7 else None
> 
> logFile='/var/log/ambari-server/log_py.log'
> 
> logging.basicConfig(filename = logFile, level = logging.DEBUG)
> logging.debug('received ' + str(len(sys.argv)-1) + ' parameters')
> for i in range(1, len(sys.argv)):
> logging.debug('parameter ' +str(i) + ':' +str(sys.argv[i]))
> 
> if __name__ == '__main__':
>main()
> 
> 
> Stop and start any service like HDFS , we can see the expected result in 
> /var/log/ambari-server/log_py.log,
> 
> 3.write a shell script to  receive parameters from dispatcher
> 
> 
> #!/bin/bash
> logFile=/var/log/ambari-server/log_sh.log
> definitionName=$1
> definitionLabel=$2
> serviceName=$3
> alertState=$4 
> alertText=$5
> alertTimestamp=$6
> hostname=$7
> 
> echo received $# parameters:  $definitionName, $definitionLabel, 
> $serviceName, $alertState ,$alertText ,$alertTimestamp, $hostname  >> $logFile
> 
> 
> Stop and start any service like HDFS , we can see the expected result in 
> /var/ambari-server/log_sh.log, we can see the expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 57281: Script-Based Alert Dispathers support passing more parameters to script

2017-03-03 Thread yao lei


> On 三月 3, 2017, 6:48 p.m., Alejandro Fernandez wrote:
> > Ship It!

Thank for reviewing this patch


- yao


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


On 三月 3, 2017, 11:56 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57281/
> ---
> 
> (Updated 三月 3, 2017, 11:56 a.m.)
> 
> 
> Review request for Ambari and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-20291
> https://issues.apache.org/jira/browse/AMBARI-20291
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Script-Based Alert Dispatcher now pass five parameters to script,including 
> alert definition name, definition label,service name, alert state, and alert 
> text.
> But if script can receive other two parameters from dispather,it will be 
> better.
> 1.hostname.
> Because hostname the alert for is not always included in alert text,although 
> it may be null like aggregate alerts.
> With it we can more quick to find the related host that occured alert.
> 2.alert timestamp.
> We may need to know the alert occurrence time ( state change time) more 
> exactly. After the alert happened,it will spend some time to schedule the 
> script to run.
> Without it,we can only regard the script start time as the alert occurrence 
> time.
> 
> We now use this feature to send alert information to mobile phone and suggest 
> also passing hostname and alert timestamp.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/services/AlertNoticeDispatchService.java
>  174f31f 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  9e0e406 
> 
> 
> Diff: https://reviews.apache.org/r/57281/diff/1/
> 
> 
> Testing
> ---
> 
> 1.cd ambari-server
>mvn test
> 
> 2.write a python script to receive parameters from dispatcher
> 
> 
> #!/usr/bin/python
> import sys
> import logging
> 
> def main():
> definitionName = sys.argv[1]
> definitionLabel = sys.argv[2]
> serviceName = sys.argv[3]
> alertState = sys.argv[4]
> alertText = sys.argv[5]
> alertTimestamp = sys.argv[6]
> hostname = sys.argv[7] if len(sys.argv)-1 == 7 else None
> 
> logFile='/var/log/ambari-server/log_py.log'
> 
> logging.basicConfig(filename = logFile, level = logging.DEBUG)
> logging.debug('received ' + str(len(sys.argv)-1) + ' parameters')
> for i in range(1, len(sys.argv)):
> logging.debug('parameter ' +str(i) + ':' +str(sys.argv[i]))
> 
> if __name__ == '__main__':
>main()
> 
> 
> Stop and start any service like HDFS , we can see the expected result in 
> /var/log/ambari-server/log_py.log,
> 
> 3.write a shell script to  receive parameters from dispatcher
> 
> 
> #!/bin/bash
> logFile=/var/log/ambari-server/log_sh.log
> definitionName=$1
> definitionLabel=$2
> serviceName=$3
> alertState=$4 
> alertText=$5
> alertTimestamp=$6
> hostname=$7
> 
> echo received $# parameters:  $definitionName, $definitionLabel, 
> $serviceName, $alertState ,$alertText ,$alertTimestamp, $hostname  >> $logFile
> 
> 
> Stop and start any service like HDFS , we can see the expected result in 
> /var/ambari-server/log_sh.log, we can see the expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 57281: Script-Based Alert Dispathers support passing more parameters to script

2017-03-03 Thread yao lei

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

Review request for Ambari and Jonathan Hurley.


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


Repository: ambari


Description
---

Script-Based Alert Dispatcher now pass five parameters to script,including 
alert definition name, definition label,service name, alert state, and alert 
text.
But if script can receive other two parameters from dispather,it will be better.
1.hostname.
Because hostname the alert for is not always included in alert text,although it 
may be null like aggregate alerts.
With it we can more quick to find the related host that occured alert.
2.alert timestamp.
We may need to know the alert occurrence time ( state change time) more 
exactly. After the alert happened,it will spend some time to schedule the 
script to run.
Without it,we can only regard the script start time as the alert occurrence 
time.

We now use this feature to send alert information to mobile phone and suggest 
also passing hostname and alert timestamp.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 907588d 
  
ambari-server/src/main/java/org/apache/ambari/server/state/services/AlertNoticeDispatchService.java
 174f31f 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 9e0e406 


Diff: https://reviews.apache.org/r/57281/diff/1/


Testing
---

1.cd ambari-server
   mvn test

2.write a python script to receive parameters from dispatcher


#!/usr/bin/python
import sys
import logging

def main():
definitionName = sys.argv[1]
definitionLabel = sys.argv[2]
serviceName = sys.argv[3]
alertState = sys.argv[4]
alertText = sys.argv[5]
alertTimestamp = sys.argv[6]
hostname = sys.argv[7] if len(sys.argv)-1 == 7 else None

logFile='/var/log/ambari-server/log_py.log'

logging.basicConfig(filename = logFile, level = logging.DEBUG)
logging.debug('received ' + str(len(sys.argv)-1) + ' parameters')
for i in range(1, len(sys.argv)):
logging.debug('parameter ' +str(i) + ':' +str(sys.argv[i]))

if __name__ == '__main__':
   main()


Stop and start any service like HDFS , we can see the expected result in 
/var/log/ambari-server/log_py.log,

3.write a shell script to  receive parameters from dispatcher


#!/bin/bash
logFile=/var/log/ambari-server/log_sh.log
definitionName=$1
definitionLabel=$2
serviceName=$3
alertState=$4 
alertText=$5
alertTimestamp=$6
hostname=$7

echo received $# parameters:  $definitionName, $definitionLabel, $serviceName, 
$alertState ,$alertText ,$alertTimestamp, $hostname  >> $logFile


Stop and start any service like HDFS , we can see the expected result in 
/var/ambari-server/log_sh.log, we can see the expected result.


Thanks,

yao lei



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-22 Thread yao lei


> On 二月 22, 2017, 10:28 p.m., Jaimin Jetly wrote:
> > We already hasve the stack way to co-host a component. In 3.0.0, we have 
> > committed a patch by which you can enforce a slave/master component to be 
> > co-hosted with another slave/master component. There are snapshots of how 
> > UI will behave on the reviewboard. Link: https://reviews.apache.org/r/55865/
> > There is another open ticket that have created to recommend the layout as 
> > per the dependency mentioned in stack definition: 
> > https://issues.apache.org/jira/browse/AMBARI-20122
> > 
> > I believ we should rather leverage stack advisor for the recommendation and 
> > validation purpose of any stack defined dependency.
> > 
> > Even the existing single case of Hive/WebHCat which is a legacy code should 
> > be refactored to remove it's hard-coded occurrnece from UI. All we need to 
> > do is add in hive stack:
> > Add to  node of HIVE_SERVER:
> > 
> > HIVE/WEBHCAT_SERVER
> > host
> > 
> > 
> > This will then use stack advisor logic committed as part of  
> > https://issues.apache.org/jira/browse/AMBARI-19685. Further enhancement of 
> > making sure both the component and host scope depencdency by default 
> > appears on the same host can be achieved by addressing 
> > https://issues.apache.org/jira/browse/AMBARI-20122

Thank you for reviewing this patch.
I also think your contribution is more flexible.


- yao


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


On 二月 22, 2017, 1:52 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55817/
> ---
> 
> (Updated 二月 22, 2017, 1:52 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Di Li, Jaimin Jetly, Jayush 
> Luniya, Zhe (Joe) Wang, and Matt.
> 
> 
> Bugs: AMBARI-19618
> https://issues.apache.org/jira/browse/AMBARI-19618
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Cohosted components information now is hardcoded in 
> stack_service_component.js as following:
> 
> App.StackServiceComponent.coHost =
>{ 'WEBHCAT_SERVER': 'HIVE_SERVER' };
> 
> It's better to move them from javascript to metainfom.xml by adding tag 
> in stack like following:
> 
> //HIVE
> 
> WEBHCAT_SERVER
> WebHCat Server
> MASTER
> 1
> true
> true
> HIVE_SERVER
> 
> 
> //RANGER https://issues.apache.org/jira/browse/AMBARI-19557
> 
> RANGER_USERSYNC
> Ranger Usersync
> MASTER
> 1
> true
> RANGER_ADMIN
> 
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
>  2f42313 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
>  c731641 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
>  51d9847 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
> 409bcae 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
> 4ba3cf1 
>   ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
> a9db470 
>   ambari-server/src/main/resources/properties.json 72104a9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
>  89f9d94 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
>  6e37ded 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
>  87a1fc7 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
> 3224eac 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
> edc5dfb 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   ambari-web/app/mappers/stack_service_mapper.js 4bda89d 
>   ambari-web/app/models/stack_service_component.js eb6f2db 
>   ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
>   ambari-web/test/service_components.js bcc4a29 
> 
> Diff: https://reviews.apache.org/r/55817/diff/
> 
> 
> Testing
> ---
> 
> 1.Ambari Web Unit Tests:

Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-22 Thread yao lei


> On 二月 22, 2017, 9:33 p.m., Alejandro Fernandez wrote:
> > Ship It!

Thank you for reviewing this patch


- yao


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


On 二月 22, 2017, 1:52 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55817/
> ---
> 
> (Updated 二月 22, 2017, 1:52 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Di Li, Jaimin Jetly, Jayush 
> Luniya, Zhe (Joe) Wang, and Matt.
> 
> 
> Bugs: AMBARI-19618
> https://issues.apache.org/jira/browse/AMBARI-19618
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Cohosted components information now is hardcoded in 
> stack_service_component.js as following:
> 
> App.StackServiceComponent.coHost =
>{ 'WEBHCAT_SERVER': 'HIVE_SERVER' };
> 
> It's better to move them from javascript to metainfom.xml by adding tag 
> in stack like following:
> 
> //HIVE
> 
> WEBHCAT_SERVER
> WebHCat Server
> MASTER
> 1
> true
> true
> HIVE_SERVER
> 
> 
> //RANGER https://issues.apache.org/jira/browse/AMBARI-19557
> 
> RANGER_USERSYNC
> Ranger Usersync
> MASTER
> 1
> true
> RANGER_ADMIN
> 
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
>  2f42313 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
>  c731641 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
>  51d9847 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
> 409bcae 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
> 4ba3cf1 
>   ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
> a9db470 
>   ambari-server/src/main/resources/properties.json 72104a9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
>  89f9d94 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
>  6e37ded 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
>  87a1fc7 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
> 3224eac 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
> edc5dfb 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   ambari-web/app/mappers/stack_service_mapper.js 4bda89d 
>   ambari-web/app/models/stack_service_component.js eb6f2db 
>   ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
>   ambari-web/test/service_components.js bcc4a29 
> 
> Diff: https://reviews.apache.org/r/55817/diff/
> 
> 
> Testing
> ---
> 
> 1.Ambari Web Unit Tests:
>   20307 passing (35s)
>   153 pending
> 
> 2.Ambari Server Unit Tests:
>   Failed tests:
>   ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
> expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
>  expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
>  expected: but was:
>   Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30
> 
> 3.Installed a cluster using RPM based on latest trunk codes and screenshots 
> attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
> expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-22 Thread yao lei


> On 二月 22, 2017, 9:21 p.m., Di Li wrote:
> > ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml,
> >  line 109
> > <https://reviews.apache.org/r/55817/diff/3/?file=1641784#file1641784line109>
> >
> > Hello Yao,
> > 
> > As you said in comment to Matt's question on cross-service co-hosting, 
> > your change is currently just to move the logic from hardcode logic on UI 
> > to the backend. I wonder if this can be improved a little bit to support 
> > multiple components. All components should be from the same service for the 
> > current design. (I think stack_advisor.py handles  as cross-service co host 
> > by part of the laytout calculation.)
> > 
> > the coHost section in metainfo.xml files can be 
> > 
> > 
> >   A1
> >   A2 
> > 
> > 
> > UI code needs updates accordingly.
> 
> Di Li wrote:
> I dropped my comment as Jaimin's code from 
> https://reviews.apache.org/r/55865/ is much more flexible and this JIRA can 
> leverage the new behavior for  hive server/webhcat cohost logic as Jaimin 
> suggested.

Thank you for reviewing this patch


- yao


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


On 二月 22, 2017, 1:52 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55817/
> ---
> 
> (Updated 二月 22, 2017, 1:52 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Di Li, Jaimin Jetly, Jayush 
> Luniya, Zhe (Joe) Wang, and Matt.
> 
> 
> Bugs: AMBARI-19618
> https://issues.apache.org/jira/browse/AMBARI-19618
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Cohosted components information now is hardcoded in 
> stack_service_component.js as following:
> 
> App.StackServiceComponent.coHost =
>{ 'WEBHCAT_SERVER': 'HIVE_SERVER' };
> 
> It's better to move them from javascript to metainfom.xml by adding tag 
> in stack like following:
> 
> //HIVE
> 
> WEBHCAT_SERVER
> WebHCat Server
> MASTER
> 1
> true
> true
> HIVE_SERVER
> 
> 
> //RANGER https://issues.apache.org/jira/browse/AMBARI-19557
> 
> RANGER_USERSYNC
> Ranger Usersync
> MASTER
> 1
> true
> RANGER_ADMIN
> 
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
>  2f42313 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
>  c731641 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
>  51d9847 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
> 409bcae 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
> 4ba3cf1 
>   ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
> a9db470 
>   ambari-server/src/main/resources/properties.json 72104a9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
>  89f9d94 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
>  6e37ded 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
>  87a1fc7 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
> 3224eac 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
> edc5dfb 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   ambari-web/app/mappers/stack_service_mapper.js 4bda89d 
>   ambari-web/app/models/stack_service_component.js eb6f2db 
>   ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
>   ambari-web/test/service_components.js bcc4a29 
> 
> Diff: https://reviews.apache.org/r/55817/diff/
> 
> 
> Testing
> ---
> 
> 1.Ambari Web Unit Tests:
>   20307 passing (35s)
>   153 pending
> 
> 2.Ambari Server Unit Tests:
>   Failed tests:
>   ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
> expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
>  expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
>  expected: but was:
>   Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30
> 
> 3.Installed a cluster using RPM based on latest trunk codes and screenshots 
> attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
> expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-21 Thread yao lei

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

(Updated 二月 22, 2017, 1:52 a.m.)


Review request for Ambari, Alejandro Fernandez, Di Li, Jaimin Jetly, Jayush 
Luniya, Zhe (Joe) Wang, and Matt.


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


Repository: ambari


Description
---

Cohosted components information now is hardcoded in stack_service_component.js 
as following:

App.StackServiceComponent.coHost =
   { 'WEBHCAT_SERVER': 'HIVE_SERVER' };

It's better to move them from javascript to metainfom.xml by adding tag 
in stack like following:

//HIVE

WEBHCAT_SERVER
WebHCat Server
MASTER
1
true
true
HIVE_SERVER


//RANGER https://issues.apache.org/jira/browse/AMBARI-19557

RANGER_USERSYNC
Ranger Usersync
MASTER
1
true
RANGER_ADMIN



Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
 2f42313 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
 c731641 
  
ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java 
51d9847 
  ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
409bcae 
  ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
4ba3cf1 
  ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
a9db470 
  ambari-server/src/main/resources/properties.json 72104a9 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
 89f9d94 
  
ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
 6e37ded 
  
ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
 87a1fc7 
  ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
3224eac 
  
ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml 
PRE-CREATION 
  ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
edc5dfb 
  
ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml 
PRE-CREATION 
  ambari-web/app/mappers/stack_service_mapper.js 4bda89d 
  ambari-web/app/models/stack_service_component.js eb6f2db 
  ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
  ambari-web/test/service_components.js bcc4a29 

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


Testing
---

1.Ambari Web Unit Tests:
  20307 passing (35s)
  153 pending

2.Ambari Server Unit Tests:
  Failed tests:
  ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
expected: but was:
  
ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
 expected: but was:
  
ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
 expected: but was:
  Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30

3.Installed a cluster using RPM based on latest trunk codes and screenshots 
attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
expected result.


Thanks,

yao lei



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-21 Thread yao lei


> On 二月 14, 2017, 3:50 a.m., Matt wrote:
> > ambari-web/test/mappers/stack_service_mapper_test.js, line 169
> > <https://reviews.apache.org/r/55817/diff/2/?file=1632648#file1632648line169>
> >
> > Can we have a test case where ```coHost```s are defined both ways?
> > 
> > ```
> > {
> >   "StackServiceComponents" : {
> > "component_name": "WEBHCAT_SERVER",
> > "co_host": "HIVE_SERVER"
> >},
> >"StackServiceComponents" : {
> > "component_name": "HIVE_SERVER",
> > "co_host": "WEBHCAT_SERVER"
> >}
> > }
> > ```
> > 
> > The above case should work without errors - even though it has 
> > duplicate information. Having this test case would make the UI more 
> > resilient to potential errors.
> > 
> > Is this already handled by the backend code?

Hi Matt.
Thanks for your comment.
I will add the test case to the updated patch.
But I will handle the duplicate configuration in fronted code,this is because i 
think the backend code will only extact configurartion from tag  which 
will be displayed by API
How about your opinion?


- yao


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


On 二月 14, 2017, 1:20 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55817/
> ---
> 
> (Updated 二月 14, 2017, 1:20 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Jayush Luniya, 
> and Matt.
> 
> 
> Bugs: AMBARI-19618
> https://issues.apache.org/jira/browse/AMBARI-19618
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Cohosted components information now is hardcoded in 
> stack_service_component.js as following:
> 
> App.StackServiceComponent.coHost =
>{ 'WEBHCAT_SERVER': 'HIVE_SERVER' };
> 
> It's better to move them from javascript to metainfom.xml by adding tag 
> in stack like following:
> 
> //HIVE
> 
> WEBHCAT_SERVER
> WebHCat Server
> MASTER
> 1
> true
> true
> HIVE_SERVER
> 
> 
> //RANGER https://issues.apache.org/jira/browse/AMBARI-19557
> 
> RANGER_USERSYNC
> Ranger Usersync
> MASTER
> 1
> true
> RANGER_ADMIN
> 
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
>  2f42313 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
>  c731641 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
>  51d9847 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
> 409bcae 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
> 4ba3cf1 
>   ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
> a9db470 
>   ambari-server/src/main/resources/properties.json 72104a9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
>  af67f05 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
>  6e37ded 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
>  87a1fc7 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
> 3224eac 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
> edc5dfb 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   ambari-web/app/mappers/stack_service_mapper.js 21c4db9 
>   ambari-web/app/models/stack_service_component.js eb6f2db 
>   ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
>   ambari-web/test/service_components.js bcc4a29 
> 
> Diff: https://reviews.apache.org/r/55817/diff/
> 
> 
> Testing
> ---
> 
> 1.Ambari Web Unit Tests:
>   20307 passing (35s)
>   153 pending
> 
> 2.Ambari Server Unit Tests:
>   Failed tests:
>   ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
> expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
>  expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
>  expected: but was:
>   Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30
> 
> 3.Installed a cluster using RPM based on latest trunk codes and screenshots 
> attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
> expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-14 Thread yao lei


> On 二月 14, 2017, 3:50 a.m., Matt wrote:
> > I'm curious whether this feature allow cohosting of another service's 
> > components?
> > 
> > Eg:
> > Service A has components A1 and A2
> > Service B has components B1, B2 and B3
> > Can A1 be coHosted with B2, using this feature?

Thanks for your comment.
In this patch,the cohost relationship is just decided by the component name 
configured in tag ,irrelevant to service.
But as far as i know,the cohost components only come in pairs in the same 
service,like HIVE,RANGER or other service

The patch now just moved the configuration from fronted web to backend 
metainfo.xml.


- yao


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


On 二月 14, 2017, 1:20 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55817/
> ---
> 
> (Updated 二月 14, 2017, 1:20 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Jayush Luniya, 
> and Matt.
> 
> 
> Bugs: AMBARI-19618
> https://issues.apache.org/jira/browse/AMBARI-19618
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Cohosted components information now is hardcoded in 
> stack_service_component.js as following:
> 
> App.StackServiceComponent.coHost =
>{ 'WEBHCAT_SERVER': 'HIVE_SERVER' };
> 
> It's better to move them from javascript to metainfom.xml by adding tag 
> in stack like following:
> 
> //HIVE
> 
> WEBHCAT_SERVER
> WebHCat Server
> MASTER
> 1
> true
> true
> HIVE_SERVER
> 
> 
> //RANGER https://issues.apache.org/jira/browse/AMBARI-19557
> 
> RANGER_USERSYNC
> Ranger Usersync
> MASTER
> 1
> true
> RANGER_ADMIN
> 
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
>  2f42313 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
>  c731641 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
>  51d9847 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
> 409bcae 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
> 4ba3cf1 
>   ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
> a9db470 
>   ambari-server/src/main/resources/properties.json 72104a9 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
>  af67f05 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
>  6e37ded 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
>  87a1fc7 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
> 3224eac 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
> edc5dfb 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   ambari-web/app/mappers/stack_service_mapper.js 21c4db9 
>   ambari-web/app/models/stack_service_component.js eb6f2db 
>   ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
>   ambari-web/test/service_components.js bcc4a29 
> 
> Diff: https://reviews.apache.org/r/55817/diff/
> 
> 
> Testing
> ---
> 
> 1.Ambari Web Unit Tests:
>   20307 passing (35s)
>   153 pending
> 
> 2.Ambari Server Unit Tests:
>   Failed tests:
>   ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
> expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
>  expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
>  expected: but was:
>   Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30
> 
> 3.Installed a cluster using RPM based on latest trunk codes and screenshots 
> attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
> expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-02-13 Thread yao lei

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

(Updated 二月 14, 2017, 1:20 a.m.)


Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Jayush Luniya, 
and Matt.


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


Repository: ambari


Description
---

Cohosted components information now is hardcoded in stack_service_component.js 
as following:

App.StackServiceComponent.coHost =
   { 'WEBHCAT_SERVER': 'HIVE_SERVER' };

It's better to move them from javascript to metainfom.xml by adding tag 
in stack like following:

//HIVE

WEBHCAT_SERVER
WebHCat Server
MASTER
1
true
true
HIVE_SERVER


//RANGER https://issues.apache.org/jira/browse/AMBARI-19557

RANGER_USERSYNC
Ranger Usersync
MASTER
1
true
RANGER_ADMIN



Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
 2f42313 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
 c731641 
  
ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java 
51d9847 
  ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
409bcae 
  ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
4ba3cf1 
  ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
a9db470 
  ambari-server/src/main/resources/properties.json 72104a9 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
 af67f05 
  
ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
 6e37ded 
  
ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
 87a1fc7 
  ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
3224eac 
  
ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml 
PRE-CREATION 
  ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
edc5dfb 
  
ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml 
PRE-CREATION 
  ambari-web/app/mappers/stack_service_mapper.js 21c4db9 
  ambari-web/app/models/stack_service_component.js eb6f2db 
  ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
  ambari-web/test/service_components.js bcc4a29 

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


Testing
---

1.Ambari Web Unit Tests:
  20307 passing (35s)
  153 pending

2.Ambari Server Unit Tests:
  Failed tests:
  ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
expected: but was:
  
ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
 expected: but was:
  
ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
 expected: but was:
  Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30

3.Installed a cluster using RPM based on latest trunk codes and screenshots 
attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
expected result.


Thanks,

yao lei



Re: Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-01-25 Thread yao lei


> On 一月 25, 2017, 6:39 p.m., Jayush Luniya wrote:
> > Yao, please add Jaimin to this review.

Thanks


- yao


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


On 一月 26, 2017, 12:22 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55817/
> ---
> 
> (Updated 一月 26, 2017, 12:22 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jaimin Jetly, Jayush Luniya, 
> and Matt.
> 
> 
> Bugs: AMBARI-19618
> https://issues.apache.org/jira/browse/AMBARI-19618
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Cohosted components information now is hardcoded in 
> stack_service_component.js as following:
> 
> App.StackServiceComponent.coHost =
>{ 'WEBHCAT_SERVER': 'HIVE_SERVER' };
> 
> It's better to move them from javascript to metainfom.xml by adding tag 
> in stack like following:
> 
> //HIVE
> 
> WEBHCAT_SERVER
> WebHCat Server
> MASTER
> 1
> true
> true
> HIVE_SERVER
> 
> 
> //RANGER https://issues.apache.org/jira/browse/AMBARI-19557
> 
> RANGER_USERSYNC
> Ranger Usersync
> MASTER
> 1
> true
> RANGER_ADMIN
> 
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
>  2f42313 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
>  c731641 
>   
> ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java
>  51d9847 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
> 409bcae 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
> 4ba3cf1 
>   ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
> a9db470 
>   ambari-server/src/main/resources/properties.json 698b6c5 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
>  6e2190b 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
>  6e37ded 
>   
> ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
>  87a1fc7 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
> 3224eac 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
> edc5dfb 
>   
> ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml
>  PRE-CREATION 
>   ambari-web/app/mappers/stack_service_mapper.js 21c4db9 
>   ambari-web/app/models/stack_service_component.js eb6f2db 
>   ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
>   ambari-web/test/service_components.js bcc4a29 
> 
> Diff: https://reviews.apache.org/r/55817/diff/
> 
> 
> Testing
> ---
> 
> 1.Ambari Web Unit Tests:
>   20307 passing (35s)
>   153 pending
> 
> 2.Ambari Server Unit Tests:
>   Failed tests:
>   ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
> expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
>  expected: but was:
>   
> ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
>  expected: but was:
>   Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30
> 
> 3.Installed a cluster using RPM based on latest trunk codes and screenshots 
> attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
> expected result.
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 55817: AMBARI-19618 Make cohosted components configurable in metainfo.xml instead of hardcoding in UI

2017-01-20 Thread yao lei

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

Review request for Ambari, Alejandro Fernandez, Jayush Luniya, and Matt.


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


Repository: ambari


Description
---

Cohosted components information now is hardcoded in stack_service_component.js 
as following:

App.StackServiceComponent.coHost =
   { 'WEBHCAT_SERVER': 'HIVE_SERVER' };

It's better to move them from javascript to metainfom.xml by adding tag 
in stack like following:

//HIVE

WEBHCAT_SERVER
WebHCat Server
MASTER
1
true
true
HIVE_SERVER


//RANGER https://issues.apache.org/jira/browse/AMBARI-19557

RANGER_USERSYNC
Ranger Usersync
MASTER
1
true
RANGER_ADMIN



Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/StackServiceComponentResponse.java
 2f42313 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackServiceComponentResourceProvider.java
 c731641 
  
ambari-server/src/main/java/org/apache/ambari/server/stack/ComponentModule.java 
51d9847 
  ambari-server/src/main/java/org/apache/ambari/server/state/ComponentInfo.java 
409bcae 
  ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/metainfo.xml 
4ba3cf1 
  ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml 
a9db470 
  ambari-server/src/main/resources/properties.json 698b6c5 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerTest.java
 6e2190b 
  
ambari-server/src/test/java/org/apache/ambari/server/stack/ComponentModuleTest.java
 6e37ded 
  
ambari-server/src/test/java/org/apache/ambari/server/stack/StackManagerTest.java
 87a1fc7 
  ambari-server/src/test/resources/stacks/HDP/2.0.5/services/HIVE/metainfo.xml 
3224eac 
  
ambari-server/src/test/resources/stacks/HDP/2.0.5/services/RANGER/metainfo.xml 
PRE-CREATION 
  ambari-server/src/test/resources/stacks/HDP/2.0.6/services/HIVE/metainfo.xml 
edc5dfb 
  
ambari-server/src/test/resources/stacks/HDP/2.0.6/services/RANGER/metainfo.xml 
PRE-CREATION 
  ambari-web/app/mappers/stack_service_mapper.js 21c4db9 
  ambari-web/app/models/stack_service_component.js eb6f2db 
  ambari-web/test/mappers/stack_service_mapper_test.js 9da8b24 
  ambari-web/test/service_components.js bcc4a29 

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


Testing
---

1.Ambari Web Unit Tests:
  20307 passing (35s)
  153 pending

2.Ambari Server Unit Tests:
  Failed tests:
  ViewRegistryTest.testReadViewArchives:239->testReadViewArchives:466 
expected: but was:
  
ViewRegistryTest.testReadViewArchives_removeUndeployed:244->testReadViewArchives:466
 expected: but was:
  
ViewRegistryTest.testReadViewArchives_viewAutoInstanceCreation:254->testReadViewArchives:466
 expected: but was:
  Tests run: 4417, Failures: 3, Errors: 0, Skipped: 30

3.Installed a cluster using RPM based on latest trunk codes and screenshots 
attached in https://issues.apache.org/jira/browse/AMBARI-19618 show the 
expected result.


Thanks,

yao lei



Re: Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-09 Thread yao lei


> On 一月 6, 2017, 9:16 p.m., Aravindan Vijayan wrote:
> > The hostname sent to AMS must match the hostname managed in Ambari Server. 
> > If we make this change in Flume sink, and the hostname is mixed case or 
> > upper case in Ambari Server, then the metrics not will be displayed. 
> > 
> > Did you happen to investigate why Ambari server has lower hostcase name 
> > while the actual hostname is in mixed/upper case?
> 
> yao lei wrote:
> Thanks for your reply.
> Firstly,the hostnames of flume metrics sent by flume sink  and stored in 
> ams hbase are actual hostnames,they are in mixed/upper/lower case.
> Secondly,hostnames displayed on web client and registered in ambari 
> database are always lowcase. 
> when ambari  web client  want to  show flume agent host level metrics ,it 
> will send a request to ams collector passed by a lowcase hostname by that 
> collector will query metrics record.
> So if hostname in ams hbase is not lowcase,it will not match the passed 
> lowcase value
> 
> yao lei wrote:
> Hi Dmytro.
> Could you give me any suggestion when you are available?
> 
> Aravindan Vijayan wrote:
> Hi Yao,
> 
> Ideally, hostname case should not be changed in Ambari. Can you attach 
> the response to the following GET calls as JSON files?
> 
> http://:8080/api/v1/hosts/
> http://:8080/api/v1/clusters//hosts/
> 
> yao lei wrote:
> Ok,each response as following :
> 1.{
>   "href" : "http://gg5:8080/api/v1/hosts;,
>   "items" : [
> {
>   "href" : "http://gg5:8080/api/v1/hosts/gg3;,
>   "Hosts" : {
> "cluster_name" : "test",
> "host_name" : "gg3"
>   }
> },
> {
>   "href" : "http://gg5:8080/api/v1/hosts/gg5;,
>   "Hosts" : {
> "cluster_name" : "test",
> "host_name" : "gg5"
>   }
> }
>   ]
> }
> 2.{
>   "href" : "http://gg5:8080/api/v1/clusters/test/hosts;,
>   "items" : [
> {
>   "href" : "http://gg5:8080/api/v1/clusters/test/hosts/gg3;,
>   "Hosts" : {
> "cluster_name" : "test",
> "host_name" : "gg3"
>   }
> },
> {
>   "href" : "http://gg5:8080/api/v1/clusters/test/hosts/gg5;,
>   "Hosts" : {
> "cluster_name" : "test",
> "host_name" : "gg5"
>   }
> }
>   ]
> }

Used Ambari is 2.4.2
Actul hostnames configured in OS are GG3 and gg5 which are stored in colomun 
HOSTNAME in table METRIC_RECORD.


- yao


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


On 一月 9, 2017, 6:27 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55173/
> ---
> 
> (Updated 一月 9, 2017, 6:27 a.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Matt, Myroslav Papirkovskyy, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-19357
> https://issues.apache.org/jira/browse/AMBARI-19357
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If hostname of flume agent is uppercase or mixed-case?web client will not 
> show flume metrics normally.
> This is because we will query metric records by lowercase hostname used in 
> ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
> picture),so we will not get any records.
> This patch amis to convert hostname of metric record of flume to lowercase 
> before inserting into ams hbase.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
>  c1b684b 
> 
> Diff: https://reviews.apache.org/r/55173/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-09 Thread yao lei


> On 一月 6, 2017, 9:16 p.m., Aravindan Vijayan wrote:
> > The hostname sent to AMS must match the hostname managed in Ambari Server. 
> > If we make this change in Flume sink, and the hostname is mixed case or 
> > upper case in Ambari Server, then the metrics not will be displayed. 
> > 
> > Did you happen to investigate why Ambari server has lower hostcase name 
> > while the actual hostname is in mixed/upper case?
> 
> yao lei wrote:
> Thanks for your reply.
> Firstly,the hostnames of flume metrics sent by flume sink  and stored in 
> ams hbase are actual hostnames,they are in mixed/upper/lower case.
> Secondly,hostnames displayed on web client and registered in ambari 
> database are always lowcase. 
> when ambari  web client  want to  show flume agent host level metrics ,it 
> will send a request to ams collector passed by a lowcase hostname by that 
> collector will query metrics record.
> So if hostname in ams hbase is not lowcase,it will not match the passed 
> lowcase value
> 
> yao lei wrote:
> Hi Dmytro.
> Could you give me any suggestion when you are available?
> 
> Aravindan Vijayan wrote:
> Hi Yao,
> 
> Ideally, hostname case should not be changed in Ambari. Can you attach 
> the response to the following GET calls as JSON files?
> 
> http://:8080/api/v1/hosts/
> http://:8080/api/v1/clusters//hosts/

Ok,each response as following :
1.{
  "href" : "http://gg5:8080/api/v1/hosts;,
  "items" : [
{
  "href" : "http://gg5:8080/api/v1/hosts/gg3;,
  "Hosts" : {
"cluster_name" : "test",
"host_name" : "gg3"
  }
},
{
  "href" : "http://gg5:8080/api/v1/hosts/gg5;,
  "Hosts" : {
"cluster_name" : "test",
"host_name" : "gg5"
  }
}
  ]
}
2.{
  "href" : "http://gg5:8080/api/v1/clusters/test/hosts;,
  "items" : [
{
  "href" : "http://gg5:8080/api/v1/clusters/test/hosts/gg3;,
  "Hosts" : {
"cluster_name" : "test",
"host_name" : "gg3"
  }
},
{
  "href" : "http://gg5:8080/api/v1/clusters/test/hosts/gg5;,
  "Hosts" : {
"cluster_name" : "test",
"host_name" : "gg5"
  }
}
  ]
}


- yao


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


On 一月 9, 2017, 6:27 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55173/
> ---
> 
> (Updated 一月 9, 2017, 6:27 a.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Matt, Myroslav Papirkovskyy, and Sid 
> Wagle.
> 
> 
> Bugs: AMBARI-19357
> https://issues.apache.org/jira/browse/AMBARI-19357
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If hostname of flume agent is uppercase or mixed-case?web client will not 
> show flume metrics normally.
> This is because we will query metric records by lowercase hostname used in 
> ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
> picture),so we will not get any records.
> This patch amis to convert hostname of metric record of flume to lowercase 
> before inserting into ams hbase.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
>  c1b684b 
> 
> Diff: https://reviews.apache.org/r/55173/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-08 Thread yao lei


> On 一月 9, 2017, 1:23 a.m., Matt wrote:
> > Is this issue only for Flume? 
> > 
> > If the root cause is because of case mismatch, are other sinks (like 
> > StormTimelineMetricsSink, similar code to get hostname) prone to have the 
> > same issue?
> 
> yao lei wrote:
> Hi Matt.
> Thanks for your reply.
> I am not sure whether other service have same issue.I happened to click 
> one host of flume agents in Flume Summary page and found its Channel Metrics 
> show nothing.
> This flume agent actual hostname is GG3 and displayed in Flume Summary 
> and Hosts page as gg3
> In web browser I found some requests sent to server like, such as 
> 
> http://gg5:8080/api/v1/clusters/test/hosts/gg3/host_components/FLUME_HANDLER?fields=metrics/flume/flume/CHANNEL/*&_=1483927924281
>
> 
> http://gg5:8080/api/v1/clusters/test/hosts/gg3/host_components/FLUME_HANDLER?fields=metrics/flume/flume/CHANNEL/ch2/ChannelCapacity[1483924529,1483928129,15]&_=1483927924545
> 
> These request hostname is lowercase gg3 and will not match  the value GG3 
> stored in AMS table METRIC_RECORD.

When debugging in getTimelineMetrics#TimelineWebServices, the hostname is 
passed lowercase value


- yao


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


On 一月 5, 2017, 3:23 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55173/
> ---
> 
> (Updated 一月 5, 2017, 3:23 a.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Matt, and Myroslav Papirkovskyy.
> 
> 
> Bugs: AMBARI-19357
> https://issues.apache.org/jira/browse/AMBARI-19357
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If hostname of flume agent is uppercase or mixed-case?web client will not 
> show flume metrics normally.
> This is because we will query metric records by lowercase hostname used in 
> ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
> picture),so we will not get any records.
> This patch amis to convert hostname of metric record of flume to lowercase 
> before inserting into ams hbase.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
>  c1b684b 
> 
> Diff: https://reviews.apache.org/r/55173/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-08 Thread yao lei


> On 一月 9, 2017, 1:23 a.m., Matt wrote:
> > Is this issue only for Flume? 
> > 
> > If the root cause is because of case mismatch, are other sinks (like 
> > StormTimelineMetricsSink, similar code to get hostname) prone to have the 
> > same issue?

Hi Matt.
Thanks for your reply.
I am not sure whether other service have same issue.I happened to click one 
host of flume agents in Flume Summary page and found its Channel Metrics show 
nothing.
This flume agent actual hostname is GG3 and displayed in Flume Summary and 
Hosts page as gg3
In web browser I found some requests sent to server like, such as 
http://gg5:8080/api/v1/clusters/test/hosts/gg3/host_components/FLUME_HANDLER?fields=metrics/flume/flume/CHANNEL/*&_=1483927924281
   
http://gg5:8080/api/v1/clusters/test/hosts/gg3/host_components/FLUME_HANDLER?fields=metrics/flume/flume/CHANNEL/ch2/ChannelCapacity[1483924529,1483928129,15]&_=1483927924545

These request hostname is lowercase gg3 and will not match  the value GG3 
stored in AMS table METRIC_RECORD.


- yao


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


On 一月 5, 2017, 3:23 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55173/
> ---
> 
> (Updated 一月 5, 2017, 3:23 a.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Matt, and Myroslav Papirkovskyy.
> 
> 
> Bugs: AMBARI-19357
> https://issues.apache.org/jira/browse/AMBARI-19357
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If hostname of flume agent is uppercase or mixed-case?web client will not 
> show flume metrics normally.
> This is because we will query metric records by lowercase hostname used in 
> ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
> picture),so we will not get any records.
> This patch amis to convert hostname of metric record of flume to lowercase 
> before inserting into ams hbase.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
>  c1b684b 
> 
> Diff: https://reviews.apache.org/r/55173/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-07 Thread yao lei


> On 一月 6, 2017, 9:16 p.m., Aravindan Vijayan wrote:
> > The hostname sent to AMS must match the hostname managed in Ambari Server. 
> > If we make this change in Flume sink, and the hostname is mixed case or 
> > upper case in Ambari Server, then the metrics not will be displayed. 
> > 
> > Did you happen to investigate why Ambari server has lower hostcase name 
> > while the actual hostname is in mixed/upper case?
> 
> yao lei wrote:
> Thanks for your reply.
> Firstly,the hostnames of flume metrics sent by flume sink  and stored in 
> ams hbase are actual hostnames,they are in mixed/upper/lower case.
> Secondly,hostnames displayed on web client and registered in ambari 
> database are always lowcase. 
> when ambari  web client  want to  show flume agent host level metrics ,it 
> will send a request to ams collector passed by a lowcase hostname by that 
> collector will query metrics record.
> So if hostname in ams hbase is not lowcase,it will not match the passed 
> lowcase value

Hi Dmytro.
Could you give me any suggestion when you are available?


- yao


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


On 一月 5, 2017, 3:23 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55173/
> ---
> 
> (Updated 一月 5, 2017, 3:23 a.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Matt, and Myroslav Papirkovskyy.
> 
> 
> Bugs: AMBARI-19357
> https://issues.apache.org/jira/browse/AMBARI-19357
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If hostname of flume agent is uppercase or mixed-case?web client will not 
> show flume metrics normally.
> This is because we will query metric records by lowercase hostname used in 
> ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
> picture),so we will not get any records.
> This patch amis to convert hostname of metric record of flume to lowercase 
> before inserting into ams hbase.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
>  c1b684b 
> 
> Diff: https://reviews.apache.org/r/55173/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-07 Thread yao lei


> On 一月 6, 2017, 9:16 p.m., Aravindan Vijayan wrote:
> > The hostname sent to AMS must match the hostname managed in Ambari Server. 
> > If we make this change in Flume sink, and the hostname is mixed case or 
> > upper case in Ambari Server, then the metrics not will be displayed. 
> > 
> > Did you happen to investigate why Ambari server has lower hostcase name 
> > while the actual hostname is in mixed/upper case?

Thanks for your reply.
Firstly,the hostnames of flume metrics sent by flume sink  and stored in ams 
hbase are actual hostnames,they are in mixed/upper/lower case.
Secondly,hostnames displayed on web client and registered in ambari database 
are always lowcase. 
when ambari  web client  want to  show flume agent host level metrics ,it will 
send a request to ams collector passed by a lowcase hostname by that collector 
will query metrics record.
So if hostname in ams hbase is not lowcase,it will not match the passed lowcase 
value


- yao


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


On 一月 5, 2017, 3:23 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55173/
> ---
> 
> (Updated 一月 5, 2017, 3:23 a.m.)
> 
> 
> Review request for Ambari, Dmytro Sen, Matt, and Myroslav Papirkovskyy.
> 
> 
> Bugs: AMBARI-19357
> https://issues.apache.org/jira/browse/AMBARI-19357
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If hostname of flume agent is uppercase or mixed-case?web client will not 
> show flume metrics normally.
> This is because we will query metric records by lowercase hostname used in 
> ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
> picture),so we will not get any records.
> This patch amis to convert hostname of metric record of flume to lowercase 
> before inserting into ams hbase.
> 
> 
> Diffs
> -
> 
>   
> ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
>  c1b684b 
> 
> Diff: https://reviews.apache.org/r/55173/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 55173: Flume metrics can't show if hostname of flume agent is not lowercase

2017-01-04 Thread yao lei

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

Review request for Ambari.


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


Repository: ambari


Description
---

If hostname of flume agent is uppercase or mixed-case?web client will not show 
flume metrics normally.
This is because we will query metric records by lowercase hostname used in 
ambari ,but the hostname in METRIC_RECORD is not lowercase (see attached 
picture),so we will not get any records.
This patch amis to convert hostname of metric record of flume to lowercase 
before inserting into ams hbase.


Diffs
-

  
ambari-metrics/ambari-metrics-flume-sink/src/main/java/org/apache/hadoop/metrics2/sink/flume/FlumeTimelineMetricsSink.java
 c1b684b 

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


Testing
---

Manually Tested


Thanks,

yao lei



Re: Review Request 52183: Support creating/editing alert target which notification_type is ALERT_SCRIPT in web client

2016-11-10 Thread yao lei


> On 十一月 10, 2016, 3:02 p.m., Jonathan Hurley wrote:
> > What's the state of this review? Has it been abandoned? If so, can we close 
> > it?

jhurley,thanks for your attention.
There seem not have more feedbacks about this review request.
If you are sure this funciton is repeated in new "wizard" workflow for alerts,i 
will close it later


- yao


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


On 十月 13, 2016, 7:43 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52183/
> ---
> 
> (Updated 十月 13, 2016, 7:43 a.m.)
> 
> 
> Review request for Ambari, Jaimin Jetly, Jonathan Hurley, Zhe (Joe) Wang, 
> Oleg Tikhonov, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-18423
> https://issues.apache.org/jira/browse/AMBARI-18423
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari now only support creating/editing alert notifications of type 
> EMAIL/SNMP in web client.
> This patch aims to support another notification type  ALERT_SCRIPT
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  10a7918 
>   ambari-web/app/messages.js 2c819e5 
>   ambari-web/app/templates/main/alerts/create_alert_notification.hbs a248e57 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  a0a4ce4 
> 
> Diff: https://reviews.apache.org/r/52183/diff/
> 
> 
> Testing
> ---
> 
> ambari-web/mvn test
> 
> 
> 30365 tests complete (43 seconds)
> 151 tests pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 52183: Support creating/editing alert target which notification_type is ALERT_SCRIPT in web client

2016-10-12 Thread yao lei


> On 十月 12, 2016, 8:15 p.m., Xi Wang wrote:
> > This will
> > not impact the new "create alert wizard" because this is part of alert 
> > notifications management.

Thanks for your comment.
But I wonder whether I need to mark this jira as duplicatie if some relevent 
jiras have existed


- yao


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


On 九月 23, 2016, 2:24 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52183/
> ---
> 
> (Updated 九月 23, 2016, 2:24 a.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Zhe (Joe) Wang, and Oleg Tikhonov.
> 
> 
> Bugs: AMBARI-18423
> https://issues.apache.org/jira/browse/AMBARI-18423
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari now only support creating/editing alert notifications of type 
> EMAIL/SNMP in web client.
> This patch aims to support another notification type  ALERT_SCRIPT
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  10a7918 
>   ambari-web/app/messages.js 2c819e5 
>   ambari-web/app/templates/main/alerts/create_alert_notification.hbs a248e57 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  a0a4ce4 
> 
> Diff: https://reviews.apache.org/r/52183/diff/
> 
> 
> Testing
> ---
> 
> ambari-web/mvn test
> 
> 
> 30365 tests complete (43 seconds)
> 151 tests pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 52183: Support creating/editing alert target which notification_type is ALERT_SCRIPT in web client

2016-10-12 Thread yao lei


> On 十月 12, 2016, 1:48 p.m., Jonathan Hurley wrote:
> > I can't really comment on the front-end work since that's not an area I'm 
> > familiar with. However, I do believe there are Jiras scoping a new "wizard" 
> > workflow for alerts in Ambari 3.0 which this may impact.

Thanks for your comment.


- yao


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


On 九月 23, 2016, 2:24 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52183/
> ---
> 
> (Updated 九月 23, 2016, 2:24 a.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Zhe (Joe) Wang, and Oleg Tikhonov.
> 
> 
> Bugs: AMBARI-18423
> https://issues.apache.org/jira/browse/AMBARI-18423
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari now only support creating/editing alert notifications of type 
> EMAIL/SNMP in web client.
> This patch aims to support another notification type  ALERT_SCRIPT
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js
>  10a7918 
>   ambari-web/app/messages.js 2c819e5 
>   ambari-web/app/templates/main/alerts/create_alert_notification.hbs a248e57 
>   
> ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
>  a0a4ce4 
> 
> Diff: https://reviews.apache.org/r/52183/diff/
> 
> 
> Testing
> ---
> 
> ambari-web/mvn test
> 
> 
> 30365 tests complete (43 seconds)
> 151 tests pending
> 
> 
> Thanks,
> 
> yao lei
> 
>



Review Request 52183: Support creating/editing alert target which notification_type is ALERT_SCRIPT in web client

2016-09-22 Thread yao lei

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

Review request for Ambari, Jonathan Hurley, Zhe (Joe) Wang, and Oleg Tikhonov.


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


Repository: ambari


Description
---

Ambari now only support creating/editing alert notifications of type EMAIL/SNMP 
in web client.
This patch aims to support another notification type  ALERT_SCRIPT


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 907588d 
  
ambari-web/app/controllers/main/alerts/manage_alert_notifications_controller.js 
10a7918 
  ambari-web/app/messages.js 2c819e5 
  ambari-web/app/templates/main/alerts/create_alert_notification.hbs a248e57 
  
ambari-web/test/controllers/main/alerts/manage_alert_notifications_controller_test.js
 a0a4ce4 

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


Testing
---

ambari-web/mvn test


30365 tests complete (43 seconds)
151 tests pending


Thanks,

yao lei



Re: Review Request 51599: AMBARI-18292 Support dispatching notifications of assigned alert states for script-based alert dispatcher

2016-09-20 Thread yao lei


> On 九月 3, 2016, 7:17 p.m., Jonathan Hurley wrote:
> > This is not the correct way to accomplish this. Instead, when you create 
> > the alert target, you can specify which alert states the alert target cares 
> > about:
> > 
> > ```
> > {
> >   "AlertTarget": {
> > "name": "Simple",
> > "description": "This target does not work and is only an exmaple of 
> > setting states",
> > "alert_states": ["OK", "WARNING"]
> > "notification_type": "FOO",
> > "groups": [1,2,3]
> >   }
> > }
> > ```
> > 
> > This is also accomplished through the Web Client when created/editing the 
> > target.
> 
> yao lei wrote:
> thanks for your explaination.
> Do your mean that we can creating or editing the  alert target on web ui?
> 
> Jonathan Hurley wrote:
> Yes you can.
> 
> yao lei wrote:
> Thanks your reply.
> I think i need to upgrade my current ambari  2.1.1
> 
> yao lei wrote:
> Hi,jhurley.
> I am sorry to bother you again.
> I can't find the operation on Web Client to create alert target which 
> notification_type is ALERT_SCRIPT.
> It seems that Ambari only support creating/editing alert notifications of 
> type EMAIL/SNMP  ( Alerts -> Actions -> Manage Notifications -> Icon plus -> 
> Create Alert Notification)
> My Ambari verison now is 2.4.0.1
> 
> Jonathan Hurley wrote:
> That's correct - creating a SCRIPT type dispatcher is not supported in 
> the web client yet. I believe the web client is working on scoping an alert 
> wizard for 2.5.0, but until then you'd need to use a POST to create it.

Thanks,got it.
I have just committed a patch to support creating/editing a SCRIPT type 
dispatcher in web client  : )
I will appreciate it if you could review my patch 
(https://issues.apache.org/jira/browse/AMBARI-18423)


- yao


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


On 九月 3, 2016, 2:36 p.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51599/
> ---
> 
> (Updated 九月 3, 2016, 2:36 p.m.)
> 
> 
> Review request for Ambari and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-18292
> https://issues.apache.org/jira/browse/AMBARI-18292
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> By default, Ambari allow all notifications of all kinds of alert states 
> (OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
> However, sometimes we hope to filter notification of some alert states 
> This patch will resolve this by setting 
> 'notification.dispatch.alert.script.states' in ambari.properties as following:
> 
> #Only dispatch WARNING and CRITICAL state notification 
> notification.dispatch.alert.script.states=WARNING,CRITICAL
> 
> If you don't set this property that means all notifications will be 
> dispatched.
> 
> I think making the desired alerts notifications configurable may be useful 
> for Ambari users.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  9e0e406 
> 
> Diff: https://reviews.apache.org/r/51599/diff/
> 
> 
> Testing
> ---
> 
> Tested
> 
> Running 
> org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 51599: AMBARI-18292 Support dispatching notifications of assigned alert states for script-based alert dispatcher

2016-09-07 Thread yao lei


> On 九月 3, 2016, 7:17 p.m., Jonathan Hurley wrote:
> > This is not the correct way to accomplish this. Instead, when you create 
> > the alert target, you can specify which alert states the alert target cares 
> > about:
> > 
> > ```
> > {
> >   "AlertTarget": {
> > "name": "Simple",
> > "description": "This target does not work and is only an exmaple of 
> > setting states",
> > "alert_states": ["OK", "WARNING"]
> > "notification_type": "FOO",
> > "groups": [1,2,3]
> >   }
> > }
> > ```
> > 
> > This is also accomplished through the Web Client when created/editing the 
> > target.
> 
> yao lei wrote:
> thanks for your explaination.
> Do your mean that we can creating or editing the  alert target on web ui?
> 
> Jonathan Hurley wrote:
> Yes you can.

Thanks your reply.
I think i need to upgrade my current ambari  2.1.1


- yao


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


On 九月 3, 2016, 2:36 p.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51599/
> ---
> 
> (Updated 九月 3, 2016, 2:36 p.m.)
> 
> 
> Review request for Ambari and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-18292
> https://issues.apache.org/jira/browse/AMBARI-18292
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> By default, Ambari allow all notifications of all kinds of alert states 
> (OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
> However, sometimes we hope to filter notification of some alert states 
> This patch will resolve this by setting 
> 'notification.dispatch.alert.script.states' in ambari.properties as following:
> 
> #Only dispatch WARNING and CRITICAL state notification 
> notification.dispatch.alert.script.states=WARNING,CRITICAL
> 
> If you don't set this property that means all notifications will be 
> dispatched.
> 
> I think making the desired alerts notifications configurable may be useful 
> for Ambari users.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  9e0e406 
> 
> Diff: https://reviews.apache.org/r/51599/diff/
> 
> 
> Testing
> ---
> 
> Tested
> 
> Running 
> org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 51599: AMBARI-18292 Support dispatching notifications of assigned alert states for script-based alert dispatcher

2016-09-03 Thread yao lei


> On 九月 3, 2016, 7:17 p.m., Jonathan Hurley wrote:
> > This is not the correct way to accomplish this. Instead, when you create 
> > the alert target, you can specify which alert states the alert target cares 
> > about:
> > 
> > ```
> > {
> >   "AlertTarget": {
> > "name": "Simple",
> > "description": "This target does not work and is only an exmaple of 
> > setting states",
> > "alert_states": ["OK", "WARNING"]
> > "notification_type": "FOO",
> > "groups": [1,2,3]
> >   }
> > }
> > ```
> > 
> > This is also accomplished through the Web Client when created/editing the 
> > target.

thanks for your explaination.
Do your mean that we can creating or editing the  alert target on web ui?


- yao


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


On 九月 3, 2016, 2:36 p.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51599/
> ---
> 
> (Updated 九月 3, 2016, 2:36 p.m.)
> 
> 
> Review request for Ambari and Jonathan Hurley.
> 
> 
> Bugs: AMBARI-18292
> https://issues.apache.org/jira/browse/AMBARI-18292
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> By default, Ambari allow all notifications of all kinds of alert states 
> (OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
> However, sometimes we hope to filter notification of some alert states 
> This patch will resolve this by setting 
> 'notification.dispatch.alert.script.states' in ambari.properties as following:
> 
> #Only dispatch WARNING and CRITICAL state notification 
> notification.dispatch.alert.script.states=WARNING,CRITICAL
> 
> If you don't set this property that means all notifications will be 
> dispatched.
> 
> I think making the desired alerts notifications configurable may be useful 
> for Ambari users.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
>  907588d 
>   
> ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
>  9e0e406 
> 
> Diff: https://reviews.apache.org/r/51599/diff/
> 
> 
> Testing
> ---
> 
> Tested
> 
> Running 
> org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 51599: AMBARI-18292 Support dispatching notifications of assigned alert states for script-based alert dispatcher

2016-09-03 Thread yao lei

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

(Updated 九月 3, 2016, 2:36 p.m.)


Review request for Ambari and Jonathan Hurley.


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


Repository: ambari


Description (updated)
---

By default, Ambari allow all notifications of all kinds of alert states 
(OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
However, sometimes we hope to filter notification of some alert states 
This patch will resolve this by setting 
'notification.dispatch.alert.script.states' in ambari.properties as following:

#Only dispatch WARNING and CRITICAL state notification 
notification.dispatch.alert.script.states=WARNING,CRITICAL

If you don't set this property that means all notifications will be dispatched.

I think making the desired alerts notifications configurable may be useful for 
Ambari users.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 907588d 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 9e0e406 

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


Testing
---

Tested

Running 
org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in


Thanks,

yao lei



Re: Review Request 51599: AMBARI-18292 Support dispatching notifications of assigned alert states for script-based alert dispatcher

2016-09-02 Thread yao lei

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

(Updated 九月 3, 2016, 12:03 a.m.)


Review request for Ambari.


Summary (updated)
-

AMBARI-18292 Support dispatching notifications of assigned alert states for 
script-based alert dispatcher


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


Repository: ambari


Description (updated)
---

By default, Ambari allow all notifications of all kinds of alert states 
(OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
However, sometimes we hope to filter notification of some alert states 
This patch will resolve this by setting 
'notification.dispatch.alert.script.states' in ambari.properties as following:

#Only dispatch WARNING and CRITICAL state notification 
notification.dispatch.alert.script.states=WARNING,CRITICAL

If you don't set this property that means all notifications will be dispatched


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 907588d 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 9e0e406 

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


Testing
---

Tested

Running 
org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in


Thanks,

yao lei



Re: Review Request 51599: AMBARI-18292 Support dispatching notification of assigned alert states for script-based alert dispatcher

2016-09-02 Thread yao lei

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

(Updated 九月 2, 2016, 1:27 p.m.)


Review request for Ambari.


Summary (updated)
-

AMBARI-18292 Support dispatching notification of assigned alert states for 
script-based alert dispatcher


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


Repository: ambari


Description
---

By default, Ambari allow all notification of all kinds of alert states 
(OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
However, sometimes we hope to filter notification of some alert states 
This patch will resolve this by setting 
'notification.dispatch.alert.script.states' in ambari.properties as following:

#Only dispatch WARNING and CRITICAL state notification 
notification.dispatch.alert.script.states=WARNING,CRITICAL

If you don't set this property that means all notification will be dispatched


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 907588d 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 9e0e406 

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


Testing
---

Tested

Running 
org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in


Thanks,

yao lei



Review Request 51599: Support dispatching notification of assigned alert states for script-based alert dispatcher

2016-09-02 Thread yao lei

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

Review request for Ambari.


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


Repository: ambari


Description
---

By default, Ambari allow all notification of all kinds of alert states 
(OK,WARNING,CRITICAL,UNKNOWN) to dispatch in script-based alert dispatcher.
However, sometimes we hope to filter notification of some alert states 
This patch will resolve this by setting 
'notification.dispatch.alert.script.states' in ambari.properties as following:

#Only dispatch WARNING and CRITICAL state notification 
notification.dispatch.alert.script.states=WARNING,CRITICAL

If you don't set this property that means all notification will be dispatched


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcher.java
 907588d 
  
ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/AlertScriptDispatcherTest.java
 9e0e406 

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


Testing
---

Tested

Running 
org.apache.ambari.server.notifications.dispatchers.AlertScriptDispatcherTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.096 sec - in


Thanks,

yao lei



Re: Review Request 42155: AMBARI-14605 '[RAM_DISK]' configured in dfs.datanode.data.dir fails to validate

2016-05-03 Thread yao lei


> On 五月 4, 2016, 4:14 a.m., Matt wrote:
> > You may close this review as it has been submitted already.

ok,thanks,Matt


- yao


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


On 五月 3, 2016, 4:57 a.m., yao lei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42155/
> ---
> 
> (Updated 五月 3, 2016, 4:57 a.m.)
> 
> 
> Review request for Ambari and Matt.
> 
> 
> Bugs: AMBARI-14605
> https://issues.apache.org/jira/browse/AMBARI-14605
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> HDFS now support four kinds of heterogeneous storage types: ARCHIVE, DISK, 
> SSD and RAM_DISK.
> If we configure dfs.datanode.data.dir as [RAM_DISK]/anydir,it fails to 
> validate.
> please see 
> https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ArchivalStorage.html#Configuration
> A
> 
> 
> Diffs
> -
> 
>   ambari-web/app/utils/validator.js 9d11746 
>   ambari-web/test/utils/validator_test.js ef90561 
> 
> Diff: https://reviews.apache.org/r/42155/diff/
> 
> 
> Testing
> ---
> 
> Manually Tested.
> But Ambari Web Unit Test fails in trunk for other reasons described in 
> https://builds.apache.org/job/Ambari-trunk-test-patch/4848//artifact/patch-work/testrun_ambari-web.txt
> 
> 
> Thanks,
> 
> yao lei
> 
>



Re: Review Request 42155: AMBARI-14605 '[RAM_DISK]' configured in dfs.datanode.data.dir fails to validate

2016-05-02 Thread yao lei

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

(Updated 五月 3, 2016, 4:57 a.m.)


Review request for Ambari and Matt.


Changes
---

I have rebuilt the patch based on the latest codebase of trunk


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


Repository: ambari


Description
---

HDFS now support four kinds of heterogeneous storage types: ARCHIVE, DISK, SSD 
and RAM_DISK.
If we configure dfs.datanode.data.dir as [RAM_DISK]/anydir,it fails to validate.
please see 
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ArchivalStorage.html#Configuration
A


Diffs (updated)
-

  ambari-web/app/utils/validator.js 9d11746 
  ambari-web/test/utils/validator_test.js ef90561 

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


Testing
---

Manually Tested.
But Ambari Web Unit Test fails in trunk for other reasons described in 
https://builds.apache.org/job/Ambari-trunk-test-patch/4848//artifact/patch-work/testrun_ambari-web.txt


Thanks,

yao lei