date:20160209


[ 
https://issues.apache.org/jira/browse/AMBARI-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139495#comment-15139495
 ] 

Hudson commented on AMBARI-14962:
-

FAILURE: Integrated in Ambari-trunk-Commit #4300 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4300/])
AMBARI-14962 : Auto configure AMS UI to use AMS Datasource (avijayan) 
(avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=14396f2b74115744d6f4c93b97a9911cd1e58ff1])
* 
ambari-server/src/test/python/stacks/2.0.6/AMBARI_METRICS/test_metrics_grafana.py
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/metrics_grafana_datasource.json.j2
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana_util.py


> Auto configure AMS UI to use AMS Datasource
> ---
>
> Key: AMBARI-14962
> URL: https://issues.apache.org/jira/browse/AMBARI-14962
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-14962.patch
>
>
> Invoke Grafana's create datasource REST call to configure the datasource as 
> part of AMS UI lifecycle commands (say "Start").
> See http://docs.grafana.org/reference/http_api/ (POST /api/datasources).
> Note that we need to specify the AMS Collector URL while creating the 
> datasource via the API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43349: Update in memory service list only after successful persistance

2016-02-09 Thread Ajit Kumar



> On Feb. 9, 2016, 7:48 p.m., Nahappan Somasundaram wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java,
> >  line 462
> > 
> >
> > This seems to be the only change required! The rest of the changes are 
> > refactoring and fixing syntax sugar. :-)
> > 
> > It took me a while to identify the actual fix. Which is why it is 
> > always good to leave out the noise.

Yes, that is correct :). I took me quite some time to read through every line 
of code to figure out what is going on. This is the reason, I just moved whole 
chunk to a separate method which makes reading code is much easier. Filing a 
jira for this would be overkill.


- Ajit


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


On Feb. 9, 2016, 4:18 p.m., Ajit Kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43349/
> ---
> 
> (Updated Feb. 9, 2016, 4:18 p.m.)
> 
> 
> Review request for Ambari, Jayush Luniya, Nahappan Somasundaram, and Sumit 
> Mohanty.
> 
> 
> Bugs: AMBARI-14965
> https://issues.apache.org/jira/browse/AMBARI-14965
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> If post request of service creation fails due to db error, Get request shows 
> service is created. If you send post request again, it fails stating service 
> already exists though DB doesn't have any corresponding entry.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java
>  a2aca7071af661f9903c11121572ec5b110b3826 
> 
> Diff: https://reviews.apache.org/r/43349/diff/
> 
> 
> Testing
> ---
> 
> Unit test
> Tested APIs manually.
> 
> 
> Thanks,
> 
> Ajit Kumar
> 
>

[jira] [Commented] (AMBARI-14964) AMS cannot be installed on trunk

2016-02-09 Thread jun aoki (JIRA)


[ 
https://issues.apache.org/jira/browse/AMBARI-14964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139407#comment-15139407
 ] 

jun aoki commented on AMBARI-14964:
---

I just made a reviewboard on behalf of [~avijayan]

> AMS cannot be installed on trunk
> 
>
> Key: AMBARI-14964
> URL: https://issues.apache.org/jira/browse/AMBARI-14964
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-14964.patch
>
>
> Installation of AMS fails due to the following:
> {code}
> stderr: 
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
>  line 65, in 
> AmsGrafana().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 238, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
>  line 28, in install
> self.install_packages(env, exclude_packages = 
> ['ambari-metrics-collector'])
> TypeError: install_packages() got an unexpected keyword argument 
> 'exclude_packages'
>  stdout:
> 2016-02-08 23:55:57,518 - Using hadoop conf dir: 
> /usr/hdp/current/hadoop-client/conf
> 2016-02-08 23:55:57,519 - Group['hadoop'] {}
> 2016-02-08 23:55:57,520 - Group['users'] {}
> 2016-02-08 23:55:57,520 - User['hive'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,520 - User['zookeeper'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,521 - User['ams'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,521 - User['ambari-qa'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'users']}
> 2016-02-08 23:55:57,522 - User['tez'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'users']}
> 2016-02-08 23:55:57,522 - User['hdfs'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,523 - User['yarn'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,523 - User['hcat'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,524 - User['mapred'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,524 - User['hbase'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,525 - File['/var/lib/ambari-agent/tmp/changeUid.sh'] 
> {'content': StaticFile('changeToSecureUid.sh'), 'mode': 0555}
> 2016-02-08 23:55:57,526 - Execute['/var/lib/ambari-agent/tmp/changeUid.sh 
> ambari-qa 
> /tmp/hadoop-ambari-qa,/tmp/hsperfdata_ambari-qa,/home/ambari-qa,/tmp/ambari-qa,/tmp/sqoop-ambari-qa']
>  {'not_if': '(test $(id -u ambari-qa) -gt 1000) || (false)'}
> 2016-02-08 23:55:57,529 - Skipping 
> Execute['/var/lib/ambari-agent/tmp/changeUid.sh ambari-qa 
> /tmp/hadoop-ambari-qa,/tmp/hsperfdata_ambari-qa,/home/ambari-qa,/tmp/ambari-qa,/tmp/sqoop-ambari-qa']
>  due to not_if
> 2016-02-08 23:55:57,530 - Directory['/tmp/hbase-hbase'] {'owner': 'hbase', 
> 'create_parents': True, 'mode': 0775, 'cd_access': 'a'}
> 2016-02-08 23:55:57,530 - File['/var/lib/ambari-agent/tmp/changeUid.sh'] 
> {'content': StaticFile('changeToSecureUid.sh'), 'mode': 0555}
> 2016-02-08 23:55:57,531 - Execute['/var/lib/ambari-agent/tmp/changeUid.sh 
> hbase /home/hbase,/tmp/hbase,/usr/bin/hbase,/var/log/hbase,/tmp/hbase-hbase'] 
> {'not_if': '(test $(id -u hbase) -gt 1000) || (false)'}
> 2016-02-08 23:55:57,534 - Skipping 
> Execute['/var/lib/ambari-agent/tmp/changeUid.sh hbase 
> /home/hbase,/tmp/hbase,/usr/bin/hbase,/var/log/hbase,/tmp/hbase-hbase'] due 
> to not_if
> 2016-02-08 23:55:57,534 - Group['hdfs'] {}
> 2016-02-08 23:55:57,534 - User['hdfs'] {'fetch_nonlocal_groups': True, 
> 'groups': [u'hadoop', u'hdfs']}
> 2016-02-08 23:55:57,535 - FS Type: 
> 2016-02-08 23:55:57,535 - Directory['/etc/hadoop'] {'mode': 0755}
> 2016-02-08 23:55:57,548 - 
> File['/usr/hdp/current/hadoop-client/conf/hadoop-env.sh'] {'content': 
> InlineTemplate(...), 'owner': 'hdfs', 'group': 'hadoop'}
> 2016-02-08 23:55:57,548 - 
> Directory['/var/lib/ambari-agent/tmp/hadoop_java_io_tmpdir'] {'owner': 
> 'hdfs', 'group': 'hadoop', 'mode': 0777}
> 2016-02-08 23:55:57,557 - Repository['HDP-2.3'] {'base_url': 
> 'http://public-repo-1.hortonworks.com/HDP/ubuntu12/2.x/updates/2.3.4.0', 
> 'action': ['create'], 'components': [u'HDP', 'main'], 'repo_template': 
> '{{package_type}} {{base_url}} {{components}}', 'repo_file_name': 'HDP', 
> 'mirror_list': None}
>

[jira] [Commented] (AMBARI-14932) "download zip" does not work

2016-02-09 Thread DIPAYAN BHOWMICK (JIRA)


[ 
https://issues.apache.org/jira/browse/AMBARI-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139425#comment-15139425
 ] 

DIPAYAN BHOWMICK commented on AMBARI-14932:
---

Hi [~patel...@us.ibm.com], you are absolutely correct, the redundancy in second 
call was done because of one of the side effect. If we had directly hit the 
download URL then the error will be thrown when we set 'window.location.href' 
with the download URL. So, as the MediaType in that case will be 
"application/json" the browser will open up a new tab and display the error in 
the new tab. To prevent that scenario and to have a consistent UI two call 
approach was taken. 

Thanks

> "download zip"  does not work
> -
>
> Key: AMBARI-14932
> URL: https://issues.apache.org/jira/browse/AMBARI-14932
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views, contrib
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: DownloadService.tiff, adapter.tiff, 
> error_after_file_open.tiff, file_1.tiff, file_2.tiff, screenshot.tiff
>
>
> Steps to Reproduce:
> 1. go to "View" - "FILES" - " Create Instance"
> 2. go to hdfs file view
> 3. click "download zip" icon
> The click doesn't download any file. The REST call returns 200 OK status.
> Detailed steps on configuring Views can be found in the link below:
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/bk_ambari_views_guide-20150721.pdf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14892) Add Grafana as a component to AMS

2016-02-09 Thread jun aoki (JIRA)


[ 
https://issues.apache.org/jira/browse/AMBARI-14892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139430#comment-15139430
 ] 

jun aoki commented on AMBARI-14892:
---

[~aonishuk], thank you for letting me know. It will be an useful functionality. 
I made a reviewboard in the other jira and made some comments.

> Add Grafana as a component to AMS
> -
>
> Key: AMBARI-14892
> URL: https://issues.apache.org/jira/browse/AMBARI-14892
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.2.1
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-14892-trunk.patch, AMBARI-14892.patch
>
>
> Add a MASTER component called Grafana to AMS service.
> Include install and start/stop script for the grafana server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14981) Move service specific exclude packages logic from resource management to stack.

2016-02-09 Thread Aravindan Vijayan (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aravindan Vijayan updated AMBARI-14981:
---
Description: Based on recommendations from [~jaoki], [~sumitmohanty], 
[~swagle]

> Move service specific exclude packages logic from resource management to 
> stack.
> ---
>
> Key: AMBARI-14981
> URL: https://issues.apache.org/jira/browse/AMBARI-14981
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Andrew Onischuk
>Priority: Critical
> Fix For: 2.4.0
>
>
> Based on recommendations from [~jaoki], [~sumitmohanty], [~swagle]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 42838: Add upgrade support for Setting feature

2016-02-09 Thread Ajit Kumar



> On Feb. 9, 2016, 6:40 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java,
> >  line 130
> > 
> >
> > This should be idempotent. If anything fails in this file, we should be 
> > able to retry.
> > Please add a check that the table doesn't already exist.
> > Before inserting those 2 rows, can check if they already exist.
> 
> Nahappan Somasundaram wrote:
> SchemaUpgradeHelper::main() or at least 
> SchemaUpgradeHelper::executeUpgrade() should be transactional. If anything 
> fails, we should be able to leave the DB in the state it was found, instead 
> of a partially upgraded schema, which will  break the system if the upgrade 
> is not run again. It is cumbersome to verify each upgrade for partial 
> execution before re-running the upgrade.
> 
> If an upgrade was successful, re-running the upgrade should exit with a 
> message. I suppose this is already happening.

I agree with Nahappan here. Ideal way to deal with the problem is make sure db 
changes are transactional. I looked at other UpgradeCatalog*.java and there is 
no validation during table creation if table already exists. If current 
implementation of UpgradeCatalog can leave DB in inconsistent/partial upgrade 
state, we should handle that as a separate task.


- Ajit


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


On Feb. 4, 2016, 12:36 a.m., Ajit Kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42838/
> ---
> 
> (Updated Feb. 4, 2016, 12:36 a.m.)
> 
> 
> Review request for Ambari, Jayush Luniya, Nahappan Somasundaram, and Sumit 
> Mohanty.
> 
> 
> Bugs: AMBARI-14912
> https://issues.apache.org/jira/browse/AMBARI-14912
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Update upgrade catalog 240 and add db schema changes for settings table.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  3414388b9a738a4fc7cc5d0f484fe553cce840ee 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  d1d68f24871422936321ad0c940499fc1ef4cbec 
> 
> Diff: https://reviews.apache.org/r/42838/diff/
> 
> 
> Testing
> ---
> 
> Unit testing. Currently my local trunk build is breaking even w/o my changes. 
> I'll run mvn clean install when it is fixed.
> 
> 
> Thanks,
> 
> Ajit Kumar
> 
>

[jira] [Commented] (AMBARI-14962) Auto configure AMS UI to use AMS Datasource


[ 
https://issues.apache.org/jira/browse/AMBARI-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139640#comment-15139640
 ] 

Hudson commented on AMBARI-14962:
-

FAILURE: Integrated in Ambari-branch-2.2 #309 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/309/])
AMBARI-14962 Auto configure AMS UI to use AMS Datasource (avijayan) (avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=d142d888f9f3c52d125806d0fa90596ab9553ae5])
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/metrics_grafana_datasource.json.j2
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana_util.py
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py
* 
ambari-server/src/test/python/stacks/2.0.6/AMBARI_METRICS/test_metrics_grafana.py


> Auto configure AMS UI to use AMS Datasource
> ---
>
> Key: AMBARI-14962
> URL: https://issues.apache.org/jira/browse/AMBARI-14962
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-14962.patch
>
>
> Invoke Grafana's create datasource REST call to configure the datasource as 
> part of AMS UI lifecycle commands (say "Start").
> See http://docs.grafana.org/reference/http_api/ (POST /api/datasources).
> Note that we need to specify the AMS Collector URL while creating the 
> datasource via the API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14973) ambari-agent upstart script restart triggers the restart of hbase specific JVM processes


[ 
https://issues.apache.org/jira/browse/AMBARI-14973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139641#comment-15139641
 ] 

Hudson commented on AMBARI-14973:
-

FAILURE: Integrated in Ambari-branch-2.2 #309 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/309/])
AMBARI-14973. ambari-agent upstart script restart triggers the restart 
(aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=43e9da158cdba8c996592dada80615e848380ea8])
* ambari-agent/src/main/python/ambari_agent/PythonExecutor.py


> ambari-agent upstart script restart triggers the restart of hbase specific 
> JVM processes
> 
>
> Key: AMBARI-14973
> URL: https://issues.apache.org/jira/browse/AMBARI-14973
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14973.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 42838: Add upgrade support for Setting feature

2016-02-09 Thread Sid Wagle



> On Feb. 9, 2016, 6:40 p.m., Alejandro Fernandez wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java,
> >  line 130
> > 
> >
> > This should be idempotent. If anything fails in this file, we should be 
> > able to retry.
> > Please add a check that the table doesn't already exist.
> > Before inserting those 2 rows, can check if they already exist.
> 
> Nahappan Somasundaram wrote:
> SchemaUpgradeHelper::main() or at least 
> SchemaUpgradeHelper::executeUpgrade() should be transactional. If anything 
> fails, we should be able to leave the DB in the state it was found, instead 
> of a partially upgraded schema, which will  break the system if the upgrade 
> is not run again. It is cumbersome to verify each upgrade for partial 
> execution before re-running the upgrade.
> 
> If an upgrade was successful, re-running the upgrade should exit with a 
> message. I suppose this is already happening.
> 
> Ajit Kumar wrote:
> I agree with Nahappan here. Ideal way to deal with the problem is make 
> sure db changes are transactional. I looked at other UpgradeCatalog*.java and 
> there is no validation during table creation if table already exists. If 
> current implementation of UpgradeCatalog can leave DB in inconsistent/partial 
> upgrade state, we should handle that as a separate task.
> 
> Alejandro Fernandez wrote:
> The changes are not transactional. This is just good practice, check if 
> the table and records exist before attempting to insert them. Also, if 
> another unrelated change fails as part of the upgrade and this change for 
> Settings was already done and the upgrade must be re-ran, we don't want it to 
> fail. This is a very critical part of Ambari.

All DDL methods on DBAccessorImpl do a check before create, so the createTable, 
createFK etc are all idempotent.
Although we haven't made everything transactional, idempotency is a must, only 
is upgrade completes successfully we do not re-run the last Catalog.


- Sid


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


On Feb. 4, 2016, 12:36 a.m., Ajit Kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42838/
> ---
> 
> (Updated Feb. 4, 2016, 12:36 a.m.)
> 
> 
> Review request for Ambari, Jayush Luniya, Nahappan Somasundaram, and Sumit 
> Mohanty.
> 
> 
> Bugs: AMBARI-14912
> https://issues.apache.org/jira/browse/AMBARI-14912
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Update upgrade catalog 240 and add db schema changes for settings table.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java
>  3414388b9a738a4fc7cc5d0f484fe553cce840ee 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java
>  d1d68f24871422936321ad0c940499fc1ef4cbec 
> 
> Diff: https://reviews.apache.org/r/42838/diff/
> 
> 
> Testing
> ---
> 
> Unit testing. Currently my local trunk build is breaking even w/o my changes. 
> I'll run mvn clean install when it is fixed.
> 
> 
> Thanks,
> 
> Ajit Kumar
> 
>

[jira] [Updated] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


 [ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad updated AMBARI-14875:
--
Affects Version/s: 2.2.0

> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.1.patch, AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


 [ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad updated AMBARI-14875:
--
Attachment: AMBARI-14875.1.patch

> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.1.patch, AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14827) HiveViews: Value in cell coming up as null for select query

2016-02-09 Thread Gaurav Nagar (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Nagar updated AMBARI-14827:
--
Attachment: AMBARI-14827.2_branch-2.2.patch

> HiveViews: Value in cell coming up as null for select query
> ---
>
> Key: AMBARI-14827
> URL: https://issues.apache.org/jira/browse/AMBARI-14827
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.2.1
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.2.2
>
> Attachments: AMBARI-14827.2_branch-2.2.patch, 
> AMBARI-14827_branch-2.2.patch, Screen Shot 2016-01-27 at 2.26.23 PM.png
>
>
> Executed the queries in hive view editor in the following order:
> set hive.execution.engine=tez;
> create table testtable61 (PersonID int, NameForSearch varchar(255), Name2 
> varchar(255));
> set hive.execution.engine=tez;
> create table testtable62 (PersonID int, NameForSearch varchar(255), Name2 
> varchar(255));
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values('name','name0','secondname0');
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values(1,'name1','secondname1');
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values(2,'name2','secondname2');
> set hive.execution.engine=tez;
> SELECT * FROM testtable61;
> returns the three rows but the value 1 in columns1 shows as null. screenshot 
> attached
> For incorrect values being inserted, the expected value in the cell was empty 
> and not null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (AMBARI-14562) Ranger : If configured audit store is 'solr', then audit_store value should be 'solr'


 [ 
https://issues.apache.org/jira/browse/AMBARI-14562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad reopened AMBARI-14562:
---

Reopening to add the changes to branch-2.2 also, since changes of AMBARI-14933 
will break branch-2.2 otherwise.

> Ranger : If configured audit store is 'solr', then audit_store value should 
> be 'solr'
> -
>
> Key: AMBARI-14562
> URL: https://issues.apache.org/jira/browse/AMBARI-14562
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14562.1.patch, AMBARI-14562.patch
>
>
> *Following implementation is required:*
> 1. if solr and db both are enabled in ambari (ranger audit tab) ==> audit 
> source type in advanced tab should be Solr, and audit_store value should be 
> 'solr' in Ranger install.properties
> 2. if only solr is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be Solr, and audit_store value should be 'solr' in 
> Ranger install.properties
> 3. if only db is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be DB, and audit_store value should be 'db' in Ranger 
> install.properties
> Ranger install.properties should be updated before Ambari starts Ranger 
> installation scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: 1weekAfterReset.png
1weekBeforeReset.png

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14562) Ranger : If configured audit store is 'solr', then audit_store value should be 'solr'


 [ 
https://issues.apache.org/jira/browse/AMBARI-14562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad updated AMBARI-14562:
--
Fix Version/s: 2.2.2

> Ranger : If configured audit store is 'solr', then audit_store value should 
> be 'solr'
> -
>
> Key: AMBARI-14562
> URL: https://issues.apache.org/jira/browse/AMBARI-14562
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14562.1.patch, AMBARI-14562.patch
>
>
> *Following implementation is required:*
> 1. if solr and db both are enabled in ambari (ranger audit tab) ==> audit 
> source type in advanced tab should be Solr, and audit_store value should be 
> 'solr' in Ranger install.properties
> 2. if only solr is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be Solr, and audit_store value should be 'solr' in 
> Ranger install.properties
> 3. if only db is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be DB, and audit_store value should be 'db' in Ranger 
> install.properties
> Ranger install.properties should be updated before Ambari starts Ranger 
> installation scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default

Antonenko Alexander created AMBARI-14967:


 Summary: Incorrect behavior of period combobox/metrics on 
Dashboard page after resetting all widgets to default
 Key: AMBARI-14967
 URL: https://issues.apache.org/jira/browse/AMBARI-14967
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.2.1
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Priority: Critical
 Fix For: 2.2.2


Steps:
# Go to Dashboard page.
# Change metrics period to any value ("1 week", for example).
# Click "Metric Actions">"Edit"->"Reset all widgets to default".

Result: period combobox has old value (1 week), but metrics are displayed for 1 
hour. Also after opening and closing widget window data in widget changes 
according to period (1 week).

So, it is not fully clear - period value should be overwritten to "1 hour" as 
default after "Reset all widgets to default" click or no but then metrics 
should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


[ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138741#comment-15138741
 ] 

Hadoop QA commented on AMBARI-14967:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12787041/AMBARI-14967_trunk.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-web.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5271//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5271//console

This message is automatically generated.

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> AMBARI-14967_22.patch, AMBARI-14967_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14969) autobootstrap failed on Cenots7


 [ 
https://issues.apache.org/jira/browse/AMBARI-14969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Onischuk updated AMBARI-14969:
-
Attachment: AMBARI-14969.patch

> autobootstrap failed on Cenots7
> ---
>
> Key: AMBARI-14969
> URL: https://issues.apache.org/jira/browse/AMBARI-14969
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14969.patch
>
>
> Confirm Hosts step was failed:
> 
> 
> #  
> /os-r7-eeameu-devdeploy-5.novalocal/var/run/ambari-server/bootstrap/1/bootstrap.err
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py", 
> line 35, in 
> from ambari_commons import OSCheck, OSConst
> ImportError: No module named ambari_commons
> 
> Cluster [artifacts](http://linux-jenkins.qe.hortonworks.com/home/jenkins/qe-
> artifacts/os-r7-eeameu-devdeploy/artifacts)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 43356: autobootstrap failed on Cenots7

2016-02-09 Thread Andrew Onischuk


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

Review request for Ambari and Dmitro Lisnichenko.


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


Repository: ambari


Description
---

Confirm Hosts step was failed:



#  
/os-r7-eeameu-devdeploy-5.novalocal/var/run/ambari-server/bootstrap/1/bootstrap.err
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py", line 
35, in 
from ambari_commons import OSCheck, OSConst
ImportError: No module named ambari_commons


Cluster [artifacts](http://linux-jenkins.qe.hortonworks.com/home/jenkins/qe-
artifacts/os-r7-eeameu-devdeploy/artifacts)


Diffs
-

  ambari-server/src/main/python/bootstrap.py 75bb26a 

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


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

[jira] [Created] (AMBARI-14969) autobootstrap failed on Cenots7

Andrew Onischuk created AMBARI-14969:


 Summary: autobootstrap failed on Cenots7
 Key: AMBARI-14969
 URL: https://issues.apache.org/jira/browse/AMBARI-14969
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.2.2
 Attachments: AMBARI-14969.patch

Confirm Hosts step was failed:



#  
/os-r7-eeameu-devdeploy-5.novalocal/var/run/ambari-server/bootstrap/1/bootstrap.err
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py", line 
35, in 
from ambari_commons import OSCheck, OSConst
ImportError: No module named ambari_commons


Cluster [artifacts](http://linux-jenkins.qe.hortonworks.com/home/jenkins/qe-
artifacts/os-r7-eeameu-devdeploy/artifacts)





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14827) HiveViews: Value in cell coming up as null for select query


[ 
https://issues.apache.org/jira/browse/AMBARI-14827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138783#comment-15138783
 ] 

Hadoop QA commented on AMBARI-14827:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12787033/AMBARI-14827.2_branch-2.2.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
contrib/views/hive.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5274//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5274//console

This message is automatically generated.

> HiveViews: Value in cell coming up as null for select query
> ---
>
> Key: AMBARI-14827
> URL: https://issues.apache.org/jira/browse/AMBARI-14827
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.2.1
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.2.2
>
> Attachments: AMBARI-14827.2_branch-2.2.patch, 
> AMBARI-14827_branch-2.2.patch, Screen Shot 2016-01-27 at 2.26.23 PM.png
>
>
> Executed the queries in hive view editor in the following order:
> set hive.execution.engine=tez;
> create table testtable61 (PersonID int, NameForSearch varchar(255), Name2 
> varchar(255));
> set hive.execution.engine=tez;
> create table testtable62 (PersonID int, NameForSearch varchar(255), Name2 
> varchar(255));
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values('name','name0','secondname0');
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values(1,'name1','secondname1');
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values(2,'name2','secondname2');
> set hive.execution.engine=tez;
> SELECT * FROM testtable61;
> returns the three rows but the value 1 in columns1 shows as null. screenshot 
> attached
> For incorrect values being inserted, the expected value in the cell was empty 
> and not null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 43357: Remove support for HDP 2.1

2016-02-09 Thread Andrew Onischuk


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

Review request for Ambari and Dmitro Lisnichenko.


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


Repository: ambari


Description
---

Disable the HDP 2.1 stack option from Ambari in Ambari 2.2.2 release.


Diffs
-

  ambari-server/src/main/resources/stacks/HDP/2.1/metainfo.xml 8ee982c 

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


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Re: Review Request 43357: Remove support for HDP 2.1

2016-02-09 Thread Dmitro Lisnichenko


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


Ship it!




Ship It!

- Dmitro Lisnichenko


On Feb. 9, 2016, 12:58 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43357/
> ---
> 
> (Updated Feb. 9, 2016, 12:58 p.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-14970
> https://issues.apache.org/jira/browse/AMBARI-14970
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Disable the HDP 2.1 stack option from Ambari in Ambari 2.2.2 release.
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/resources/stacks/HDP/2.1/metainfo.xml 8ee982c 
> 
> Diff: https://reviews.apache.org/r/43357/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

Re: Review Request 43009: View: Capacity Scheduler View - Provide dropdown for scheduling calculator


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




contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queues.js
 (line 421)


Its more redable to split at ,


- Sreenath Somarajapuram


On Jan. 30, 2016, 7:05 a.m., Akhil PB wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43009/
> ---
> 
> (Updated Jan. 30, 2016, 7:05 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Pallav Kulshreshtha, and 
> Sreenath Somarajapuram.
> 
> 
> Bugs: AMBARI-14852
> https://issues.apache.org/jira/browse/AMBARI-14852
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Implement dropdown for scheduling calculator in capacity scheduler view.
> 
> 
> Diffs
> -
> 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queues.js
>  416ff43 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/styles/application.less
>  c0acf4f 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/templates/schedulerPanel.hbs
>  4419aa0 
> 
> Diff: https://reviews.apache.org/r/43009/diff/
> 
> 
> Testing
> ---
> 
> Done some manual unit testing. The dropdown will be only shown in ambari 
> operator mode.
> 
> 
> Thanks,
> 
> Akhil PB
> 
>

Re: Review Request 43089: View: Capacity Scheduler View: Cannot delete 'root.default' queue when it should be


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




contrib/views/capacity-scheduler/src/main/resources/ui/app/components/confirmDelete.js
 (line 42)


Probably
if (this.get("param.id") === 'root.default')
might be better.



contrib/views/capacity-scheduler/src/main/resources/ui/app/styles/application.less
 (line 264)


Please keep a check on the intentation.


- Sreenath Somarajapuram


On Feb. 2, 2016, 12:17 p.m., Akhil PB wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43089/
> ---
> 
> (Updated Feb. 2, 2016, 12:17 p.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Pallav Kulshreshtha, and 
> Sreenath Somarajapuram.
> 
> 
> Bugs: AMBARI-14873
> https://issues.apache.org/jira/browse/AMBARI-14873
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Enabled deletion for default queue in capacity scheduler view.
> 
> 
> Diffs
> -
> 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/components/confirmDelete.js
>  5ada051 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queue.js
>  521b473 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/styles/application.less
>  c0acf4f 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/templates/queue.hbs
>  15550d1 
> 
> Diff: https://reviews.apache.org/r/43089/diff/
> 
> 
> Testing
> ---
> 
> Done manual unit testing in ambari operator/admin mode.
> 
> 
> Thanks,
> 
> Akhil PB
> 
>

Re: Review Request 42712: AMBARI-14753: Capsched view: The view does not show the "effective" permissions of a queue


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




contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queue.js 
(line 316)


Can we make this logic simpler. Is there a reason behind converting the 
array into a different form?


- Sreenath Somarajapuram


On Feb. 8, 2016, 10:20 a.m., Akhil PB wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42712/
> ---
> 
> (Updated Feb. 8, 2016, 10:20 a.m.)
> 
> 
> Review request for Ambari, DIPAYAN BHOWMICK, Pallav Kulshreshtha, and 
> Sreenath Somarajapuram.
> 
> 
> Bugs: AMBARI-14753
> https://issues.apache.org/jira/browse/AMBARI-14753
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Added effective permissions for acl_submit_application and 
> acl_administer_queue in capshed.
> 
> 
> Diffs
> -
> 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queue.js
>  521b473 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/styles/application.less
>  c0acf4f 
>   
> contrib/views/capacity-scheduler/src/main/resources/ui/app/templates/queue.hbs
>  15550d1 
> 
> Diff: https://reviews.apache.org/r/42712/diff/
> 
> 
> Testing
> ---
> 
> Done some manual unit testing in both ambari operator and non-operator mode.
> 
> 
> Thanks,
> 
> Akhil PB
> 
>

Re: Review Request 43087: AMBARI-14875 : Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off

2016-02-09 Thread Andriy Babiichuk


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


Ship it!




Ship It!

- Andriy Babiichuk


On Фев. 9, 2016, 9:40 д.п., Gautam Borad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43087/
> ---
> 
> (Updated Фев. 9, 2016, 9:40 д.п.)
> 
> 
> Review request for Ambari, Andriy Babiichuk, Alejandro Fernandez, Jaimin 
> Jetly, Mahadev Konar, Sumit Mohanty, Selvamohan Neethiraj, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: AMBARI-14875
> https://issues.apache.org/jira/browse/AMBARI-14875
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Earlier, Audit to DB related config properties used to be visible for Ranger 
> Admin (during installation) as those were mandatory set of properties to 
> install Ranger Admin.  As Ranger Admin is now moving away from default Audit 
> to DB settings, changes are needed in Ambari stacks as well.
> 
> Attached patch has changes in theme_version_2.json to hide Ranger's Audit to 
> DB related configuration properties if Audit to DB is disabled.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/themes/theme_version_1.json
>  cb5aa78 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/themes/theme_version_2.json
>  2c469a9 
> 
> Diff: https://reviews.apache.org/r/43087/diff/
> 
> 
> Testing
> ---
> 
> Installed Ranger and verified toggling of 'Audit to DB flag' hides Audit to 
> DB related configuration properties.
> 
> 
> Thanks,
> 
> Gautam Borad
> 
>

[jira] [Resolved] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


 [ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad resolved AMBARI-14875.
---
Resolution: Fixed

> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.1.patch, AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


[ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138684#comment-15138684
 ] 

Gautam Borad commented on AMBARI-14875:
---

Committed to trunk : 
https://github.com/apache/ambari/commit/12faf8cbae92cfa7836e7508ec2df8f2bd41d286
Committed to branch-2.2 : 
https://github.com/apache/ambari/commit/b30fa67b3327fda96dc501f81c8e6c42e80d965a

> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.1.patch, AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 43355: Tez Ambari View: Add protocol configuration for YARN


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

Review request for Ambari, DIPAYAN BHOWMICK and Pallav Kulshreshtha.


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


Repository: ambari


Description
---

- Value set in yarn.http.policy is required for creating task attempt log 
links, and we need a mechanism to get that configuration value at the UI side.
- As host points to Ambari proxy, there is no way to know the protocol at which 
yarn daemons are configured to run.


Diffs
-

  
contrib/views/tez/src/main/java/org/apache/ambari/view/tez/ViewController.java 
16b470a 
  
contrib/views/tez/src/main/java/org/apache/ambari/view/tez/ViewControllerImpl.java
 c1456bc 
  contrib/views/tez/src/main/resources/ui/scripts/init-ambari-view.js c246536 
  
contrib/views/utils/src/main/java/org/apache/ambari/view/utils/ambari/Services.java
 8a50012 

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


Testing
---

Tested locally on Ambari with latest Tez UI 1.


Thanks,

Sreenath Somarajapuram

[jira] [Commented] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


[ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138765#comment-15138765
 ] 

Hadoop QA commented on AMBARI-14967:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12787041/AMBARI-14967_trunk.patch
  against trunk revision .

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5273//console

This message is automatically generated.

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> AMBARI-14967_22.patch, AMBARI-14967_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 42906: HiveViews: Value in cell coming up as null for select query

2016-02-09 Thread Gaurav Nagar


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

(Updated Feb. 9, 2016, 9:47 a.m.)


Review request for Ambari, DIPAYAN BHOWMICK, Rohit Choudhary, Srimanth Gunturi, 
Sid Wagle, and Yusaku Sako.


Changes
---

Handled null,empty and null value string in following way:
empty string - ""
null - null
string with value null - "null"


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


Repository: ambari


Description
---

Added null check for cell value. If the value is null don't add String value.


Diffs (updated)
-

  
contrib/views/hive/src/main/java/org/apache/ambari/view/hive/resources/jobs/ResultsPaginationController.java
 84dec4d 

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


Testing
---

Manual Testing.

Output of mvn clean install

---
 T E S T S
---

---
 T E S T S
---
Running org.apache.ambari.view.hive.backgroundjobs.BackgroundJobControllerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.475 sec
Running org.apache.ambari.view.hive.client.ConnectionTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.362 sec
Running org.apache.ambari.view.hive.client.UtilsTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.291 sec
Running org.apache.ambari.view.hive.PropertyValidatorTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec
Running org.apache.ambari.view.hive.resources.files.FileServiceTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.568 sec
Running org.apache.ambari.view.hive.resources.jobs.AggregatorTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.257 sec
Running org.apache.ambari.view.hive.resources.jobs.ATSParserTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.206 sec
Running org.apache.ambari.view.hive.resources.jobs.JobLDAPServiceTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.921 sec
Running org.apache.ambari.view.hive.resources.jobs.JobServiceTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.941 sec
Running org.apache.ambari.view.hive.resources.jobs.LogParserTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.076 sec
Running org.apache.ambari.view.hive.resources.resources.FileResourceServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.623 sec
Running 
org.apache.ambari.view.hive.resources.savedQueries.SavedQueryResourceManagerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.144 sec
Running org.apache.ambari.view.hive.resources.savedQueries.SavedQueryServiceTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.982 sec
Running org.apache.ambari.view.hive.resources.udfs.UDFServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.666 sec
Running org.apache.ambari.view.hive.resources.upload.DataParserTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.107 sec

Results :

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


Thanks,

Gaurav Nagar

[jira] [Commented] (AMBARI-14859) Ranger - Keep all temporary files in the tmp directory defined in the Agent's configuration


[ 
https://issues.apache.org/jira/browse/AMBARI-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138693#comment-15138693
 ] 

Gautam Borad commented on AMBARI-14859:
---

Committed to trunk : 
https://github.com/apache/ambari/commit/472d62a7b3c0383ad4d95fe659ac87b4a8da3a1f
Committed to branch-2.2 : 
https://github.com/apache/ambari/commit/d06be53446783a19947b0739b942a6dca2030288

> Ranger - Keep all temporary files in the tmp directory defined in the Agent's 
> configuration
> ---
>
> Key: AMBARI-14859
> URL: https://issues.apache.org/jira/browse/AMBARI-14859
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.3.0
>
> Attachments: AMBARI-14859.patch
>
>
> For stack implementation related to Ranger in Ambari : 
> Move temporary files created by Ambari code, they should reside in the tmp 
> directory defined in the Agent's configuration. (Refer: 
> https://reviews.apache.org/r/34296 )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: BUG-52014_trunk.patch

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> BUG-52014_branch-2_2.patch, BUG-52014_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14968) [Ambari Web UI] Hosts list for DataNode is not correct

2016-02-09 Thread Mukhadin Buzdov (JIRA)

Mukhadin Buzdov created AMBARI-14968:


 Summary: [Ambari Web UI] Hosts list for DataNode is not correct
 Key: AMBARI-14968
 URL: https://issues.apache.org/jira/browse/AMBARI-14968
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.2
 Environment: _Operating system_: CentOS Linux 7 
{color:gray}(7.1.1503){color}
_Platform_: HDP 2.3.4.0
Reporter: Mukhadin Buzdov
Priority: Minor


5 nodes _HDP_ cluster: *Node1*, *Node2*, *Node3*, *Node4*, *Node5*.
_DataNode_ was installed on *Node4* and *Node5*.

*Steps to reproduce*:
# Log in to _Ambari Web UI_.
# Go to _Dashboard_.
# Select _HDFS_ service from the left menu.
# Press _DataNodes_ link in the _Summary_ section.
{color:red}Will show *Node1* and *Node2* instances, which is not correct.{color}

*Additional information*:
* Same for _HDFS RegionServer_, _YARN NodeManager_, etc.
* Please see screenshot attached: *BUG_DataNode_Hosts.png*



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: AMBARI-14967_22.patch

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> AMBARI-14967_22.patch, AMBARI-14967_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: AMBARI-14967_trunk.patch

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> AMBARI-14967_22.patch, AMBARI-14967_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


 [ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad updated AMBARI-14875:
--
Affects Version/s: (was: 2.4.0)
   2.2.1

> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


 [ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad updated AMBARI-14875:
--
Fix Version/s: 2.2.2

> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14892) Add Grafana as a component to AMS


[ 
https://issues.apache.org/jira/browse/AMBARI-14892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138624#comment-15138624
 ] 

Andrew Onischuk commented on AMBARI-14892:
--

[~jaoki], we had to move to different logic for excluding packages, as the one 
with used before was problematic to use for RU/EU. Now you should use the new 
logics introduced by addinging conditions to metainfo.xml and 
package_conditions.py to exclude the packages.

Please feel free to ping me if you have any questions on this.

> Add Grafana as a component to AMS
> -
>
> Key: AMBARI-14892
> URL: https://issues.apache.org/jira/browse/AMBARI-14892
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.2.1
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-14892-trunk.patch, AMBARI-14892.patch
>
>
> Add a MASTER component called Grafana to AMS service.
> Include install and start/stop script for the grafana server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMBARI-14562) Ranger : If configured audit store is 'solr', then audit_store value should be 'solr'


 [ 
https://issues.apache.org/jira/browse/AMBARI-14562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad resolved AMBARI-14562.
---
Resolution: Fixed

> Ranger : If configured audit store is 'solr', then audit_store value should 
> be 'solr'
> -
>
> Key: AMBARI-14562
> URL: https://issues.apache.org/jira/browse/AMBARI-14562
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14562.1.patch, AMBARI-14562.patch
>
>
> *Following implementation is required:*
> 1. if solr and db both are enabled in ambari (ranger audit tab) ==> audit 
> source type in advanced tab should be Solr, and audit_store value should be 
> 'solr' in Ranger install.properties
> 2. if only solr is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be Solr, and audit_store value should be 'solr' in 
> Ranger install.properties
> 3. if only db is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be DB, and audit_store value should be 'db' in Ranger 
> install.properties
> Ranger install.properties should be updated before Ambari starts Ranger 
> installation scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14859) Ranger - Keep all temporary files in the tmp directory defined in the Agent's configuration


 [ 
https://issues.apache.org/jira/browse/AMBARI-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gautam Borad updated AMBARI-14859:
--
Fix Version/s: (was: 2.3.0)
   2.4.0

> Ranger - Keep all temporary files in the tmp directory defined in the Agent's 
> configuration
> ---
>
> Key: AMBARI-14859
> URL: https://issues.apache.org/jira/browse/AMBARI-14859
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14859.patch
>
>
> For stack implementation related to Ranger in Ambari : 
> Move temporary files created by Ambari code, they should reside in the tmp 
> directory defined in the Agent's configuration. (Refer: 
> https://reviews.apache.org/r/34296 )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43356: autobootstrap failed on Cenots7

2016-02-09 Thread Dmitro Lisnichenko


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


Ship it!




Ship It!

- Dmitro Lisnichenko


On Feb. 9, 2016, 12:34 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43356/
> ---
> 
> (Updated Feb. 9, 2016, 12:34 p.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-14969
> https://issues.apache.org/jira/browse/AMBARI-14969
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Confirm Hosts step was failed:
> 
> 
> 
> #  
> /os-r7-eeameu-devdeploy-5.novalocal/var/run/ambari-server/bootstrap/1/bootstrap.err
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py", 
> line 35, in 
> from ambari_commons import OSCheck, OSConst
> ImportError: No module named ambari_commons
> 
> 
> Cluster [artifacts](http://linux-jenkins.qe.hortonworks.com/home/jenkins/qe-
> artifacts/os-r7-eeameu-devdeploy/artifacts)
> 
> 
> Diffs
> -
> 
>   ambari-server/src/main/python/bootstrap.py 75bb26a 
> 
> Diff: https://reviews.apache.org/r/43356/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Created] (AMBARI-14970) Remove support for HDP 2.1

Andrew Onischuk created AMBARI-14970:


 Summary: Remove support for HDP 2.1
 Key: AMBARI-14970
 URL: https://issues.apache.org/jira/browse/AMBARI-14970
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.2.2
 Attachments: AMBARI-14970.patch

Disable the HDP 2.1 stack option from Ambari in Ambari 2.2.2 release.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14970) Remove support for HDP 2.1


 [ 
https://issues.apache.org/jira/browse/AMBARI-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Onischuk updated AMBARI-14970:
-
Attachment: AMBARI-14970.patch

> Remove support for HDP 2.1
> --
>
> Key: AMBARI-14970
> URL: https://issues.apache.org/jira/browse/AMBARI-14970
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14970.patch
>
>
> Disable the HDP 2.1 stack option from Ambari in Ambari 2.2.2 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43087: AMBARI-14875 : Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off

2016-02-09 Thread Gautam Borad


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

(Updated Feb. 9, 2016, 9:40 a.m.)


Review request for Ambari, Andriy Babiichuk, Alejandro Fernandez, Jaimin Jetly, 
Mahadev Konar, Sumit Mohanty, Selvamohan Neethiraj, and Velmurugan Periasamy.


Changes
---

Patch needs to be updated, as it has changes in same line of code as in 
AMBARI-14933


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


Repository: ambari


Description (updated)
---

Earlier, Audit to DB related config properties used to be visible for Ranger 
Admin (during installation) as those were mandatory set of properties to 
install Ranger Admin.  As Ranger Admin is now moving away from default Audit to 
DB settings, changes are needed in Ambari stacks as well.

Attached patch has changes in theme_version_2.json to hide Ranger's Audit to DB 
related configuration properties if Audit to DB is disabled.


Diffs (updated)
-

  
ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/themes/theme_version_1.json
 cb5aa78 
  
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/themes/theme_version_2.json
 2c469a9 

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


Testing
---

Installed Ranger and verified toggling of 'Audit to DB flag' hides Audit to DB 
related configuration properties.


Thanks,

Gautam Borad

[jira] [Commented] (AMBARI-14964) AMS cannot be installed on trunk


[ 
https://issues.apache.org/jira/browse/AMBARI-14964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138632#comment-15138632
 ] 

Andrew Onischuk commented on AMBARI-14964:
--

hey [~avijayan], I just commented about this issue in AMBARI-14892 about this. 
The logics for excluding packages changed (due to problematic part of it during 
RU/EU), you just have to do a couple of adjustments to move to the new logics.

regards.

> AMS cannot be installed on trunk
> 
>
> Key: AMBARI-14964
> URL: https://issues.apache.org/jira/browse/AMBARI-14964
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Blocker
> Fix For: 2.4.0
>
>
> Installation of AMS fails due to the following:
> {code}
> stderr: 
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
>  line 65, in 
> AmsGrafana().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 238, in execute
> method(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py",
>  line 28, in install
> self.install_packages(env, exclude_packages = 
> ['ambari-metrics-collector'])
> TypeError: install_packages() got an unexpected keyword argument 
> 'exclude_packages'
>  stdout:
> 2016-02-08 23:55:57,518 - Using hadoop conf dir: 
> /usr/hdp/current/hadoop-client/conf
> 2016-02-08 23:55:57,519 - Group['hadoop'] {}
> 2016-02-08 23:55:57,520 - Group['users'] {}
> 2016-02-08 23:55:57,520 - User['hive'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,520 - User['zookeeper'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,521 - User['ams'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,521 - User['ambari-qa'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'users']}
> 2016-02-08 23:55:57,522 - User['tez'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'users']}
> 2016-02-08 23:55:57,522 - User['hdfs'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,523 - User['yarn'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,523 - User['hcat'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,524 - User['mapred'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,524 - User['hbase'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': [u'hadoop']}
> 2016-02-08 23:55:57,525 - File['/var/lib/ambari-agent/tmp/changeUid.sh'] 
> {'content': StaticFile('changeToSecureUid.sh'), 'mode': 0555}
> 2016-02-08 23:55:57,526 - Execute['/var/lib/ambari-agent/tmp/changeUid.sh 
> ambari-qa 
> /tmp/hadoop-ambari-qa,/tmp/hsperfdata_ambari-qa,/home/ambari-qa,/tmp/ambari-qa,/tmp/sqoop-ambari-qa']
>  {'not_if': '(test $(id -u ambari-qa) -gt 1000) || (false)'}
> 2016-02-08 23:55:57,529 - Skipping 
> Execute['/var/lib/ambari-agent/tmp/changeUid.sh ambari-qa 
> /tmp/hadoop-ambari-qa,/tmp/hsperfdata_ambari-qa,/home/ambari-qa,/tmp/ambari-qa,/tmp/sqoop-ambari-qa']
>  due to not_if
> 2016-02-08 23:55:57,530 - Directory['/tmp/hbase-hbase'] {'owner': 'hbase', 
> 'create_parents': True, 'mode': 0775, 'cd_access': 'a'}
> 2016-02-08 23:55:57,530 - File['/var/lib/ambari-agent/tmp/changeUid.sh'] 
> {'content': StaticFile('changeToSecureUid.sh'), 'mode': 0555}
> 2016-02-08 23:55:57,531 - Execute['/var/lib/ambari-agent/tmp/changeUid.sh 
> hbase /home/hbase,/tmp/hbase,/usr/bin/hbase,/var/log/hbase,/tmp/hbase-hbase'] 
> {'not_if': '(test $(id -u hbase) -gt 1000) || (false)'}
> 2016-02-08 23:55:57,534 - Skipping 
> Execute['/var/lib/ambari-agent/tmp/changeUid.sh hbase 
> /home/hbase,/tmp/hbase,/usr/bin/hbase,/var/log/hbase,/tmp/hbase-hbase'] due 
> to not_if
> 2016-02-08 23:55:57,534 - Group['hdfs'] {}
> 2016-02-08 23:55:57,534 - User['hdfs'] {'fetch_nonlocal_groups': True, 
> 'groups': [u'hadoop', u'hdfs']}
> 2016-02-08 23:55:57,535 - FS Type: 
> 2016-02-08 23:55:57,535 - Directory['/etc/hadoop'] {'mode': 0755}
> 2016-02-08 23:55:57,548 - 
> File['/usr/hdp/current/hadoop-client/conf/hadoop-env.sh'] {'content': 
> InlineTemplate(...), 'owner': 'hdfs', 'group': 'hadoop'}
> 2016-02-08 23:55:57,548 - 
> Directory['/var/lib/ambari-agent/tmp/hadoop_java_io_tmpdir'] {'owner': 
> 'hdfs', 'group': 'hadoop', 'mode': 0777}
> 2016-02-08 23:55:57,557 - Repository['HDP-2.3'] {'base_url': 
> 'http://public-repo-1.hortonworks.com/HDP/ubuntu12/2.x/updates/2.3.4.0', 
>

[jira] [Commented] (AMBARI-14827) HiveViews: Value in cell coming up as null for select query

2016-02-09 Thread Gaurav Nagar (JIRA)


[ 
https://issues.apache.org/jira/browse/AMBARI-14827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138671#comment-15138671
 ] 

Gaurav Nagar commented on AMBARI-14827:
---

Handled null,empty and null value string in following way:
empty string - ""
null - null
string with value null - "null"

> HiveViews: Value in cell coming up as null for select query
> ---
>
> Key: AMBARI-14827
> URL: https://issues.apache.org/jira/browse/AMBARI-14827
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-views
>Affects Versions: 2.2.1
>Reporter: Gaurav Nagar
>Assignee: Gaurav Nagar
> Fix For: 2.2.2
>
> Attachments: AMBARI-14827.2_branch-2.2.patch, 
> AMBARI-14827_branch-2.2.patch, Screen Shot 2016-01-27 at 2.26.23 PM.png
>
>
> Executed the queries in hive view editor in the following order:
> set hive.execution.engine=tez;
> create table testtable61 (PersonID int, NameForSearch varchar(255), Name2 
> varchar(255));
> set hive.execution.engine=tez;
> create table testtable62 (PersonID int, NameForSearch varchar(255), Name2 
> varchar(255));
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values('name','name0','secondname0');
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values(1,'name1','secondname1');
> set hive.execution.engine=tez;
> INSERT INTO TABLE testtable61 values(2,'name2','secondname2');
> set hive.execution.engine=tez;
> SELECT * FROM testtable61;
> returns the three rows but the value 1 in columns1 shows as null. screenshot 
> attached
> For incorrect values being inserted, the expected value in the cell was empty 
> and not null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14562) Ranger : If configured audit store is 'solr', then audit_store value should be 'solr'


[ 
https://issues.apache.org/jira/browse/AMBARI-14562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138675#comment-15138675
 ] 

Gautam Borad commented on AMBARI-14562:
---

Committed to branch-2.2 : 
https://github.com/apache/ambari/commit/c5e6cb75de56375e1a52b75c78cb4ab6f3592339

> Ranger : If configured audit store is 'solr', then audit_store value should 
> be 'solr'
> -
>
> Key: AMBARI-14562
> URL: https://issues.apache.org/jira/browse/AMBARI-14562
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14562.1.patch, AMBARI-14562.patch
>
>
> *Following implementation is required:*
> 1. if solr and db both are enabled in ambari (ranger audit tab) ==> audit 
> source type in advanced tab should be Solr, and audit_store value should be 
> 'solr' in Ranger install.properties
> 2. if only solr is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be Solr, and audit_store value should be 'solr' in 
> Ranger install.properties
> 3. if only db is enabled in ambari (ranger audit tab) ==> audit source type 
> in advanced tab should be DB, and audit_store value should be 'db' in Ranger 
> install.properties
> Ranger install.properties should be updated before Ambari starts Ranger 
> installation scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: (was: BUG-52014_branch-2_2.patch)

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> BUG-52014_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


[ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138703#comment-15138703
 ] 

Antonenko Alexander commented on AMBARI-14967:
--

Since the branch-2.2 patch was uploaded later, Hadoop QA tried to apply the 
patch to trunk, hence the failure.

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> BUG-52014_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: (was: BUG-52014_trunk.patch)

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14957) Paging not working properly when filtering with alerts and hostname

2016-02-09 Thread Andrii Tkach (JIRA)


[ 
https://issues.apache.org/jira/browse/AMBARI-14957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138727#comment-15138727
 ] 

Andrii Tkach commented on AMBARI-14957:
---

committed to trunk and branch-2.2

> Paging not working properly when filtering with alerts and hostname
> ---
>
> Key: AMBARI-14957
> URL: https://issues.apache.org/jira/browse/AMBARI-14957
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-14957.patch, AMBARI-14957_branch-2.2.patch, 
> filter-not-working.mov
>
>
> On 1200 node cluster I enabled filter for alerts and then put in a hostname 
> filter... which showed hosts that did not match the filter. Also, the paging 
> showed 1 - 10 of 11 at bottom, but when I clicked on the right arrow, it 
> still showed the same page (video attached).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14951) Tez Ambari View: Add protocol configuration for YARN

2016-02-09 Thread Sreenath Somarajapuram (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sreenath Somarajapuram updated AMBARI-14951:

Attachment: AMBARI-14951.1.patch

> Tez Ambari View: Add protocol configuration for YARN
> 
>
> Key: AMBARI-14951
> URL: https://issues.apache.org/jira/browse/AMBARI-14951
> Project: Ambari
>  Issue Type: Bug
>Reporter: Sreenath Somarajapuram
>Assignee: Sreenath Somarajapuram
> Attachments: AMBARI-14951.1.patch
>
>
> - Value set in yarn.http.policy is required for creating task attempt log 
> links, and we need a mechanism to get that configuration value at the UI side.
> - As host points to Ambari proxy, there is no way to know the protocol at 
> which yarn daemons are configured to run. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43337: AMBARI-14962 Auto configure AMS UI to use AMS Datasource

2016-02-09 Thread Dmytro Sen


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




ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/metrics_grafana_datasource.json.j2
 (line 5)


I thought, Ambari datasource should hava an ambari server hostname and port 
as an url. Here's working datasource on my cluster


{"id":1,"orgId":1,"name":"ams","type":"ambari","access":"proxy","url":"http://localhost:8080","password":"","user":"","database":"","basicAuth":true,"basicAuthUser":"","basicAuthPassword":"","withCredentials":false,"isDefault":false,"jsonData":null}

Ambari plugin for Grafana uses ambari server API to discover component, 
host and metric names.


- Dmytro Sen


On Фев. 8, 2016, 11:33 п.п., Aravindan Vijayan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43337/
> ---
> 
> (Updated Фев. 8, 2016, 11:33 п.п.)
> 
> 
> Review request for Ambari, Dmytro Sen, Sumit Mohanty, Sid Wagle, and Yusaku 
> Sako.
> 
> 
> Bugs: AMBARI-14962
> https://issues.apache.org/jira/browse/AMBARI-14962
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> TODO
> Invoke Grafana's create datasource REST call to configure the datasource as 
> part of AMS UI lifecycle commands (say "Start").
> 
> IMPLEMENTATION LOGIC
> 
> . During Grafana START
> . Check if AMBARI_METRICS datasource already exists in Grafana.
> . If datasource EXISTS
>   . Check Collector Host is valid.
>   . If not valid, delete obselete datasource entry from Grafana.
>   . If Collector host valid, skip_creating_datasource = True. 
> . If skip_creating_datasource != True
>   . Create datasource with name = AMBARI_METRICS and URL as the current 
> collector URL.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana.py
>  f876036 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/metrics_grafana_util.py
>  PRE-CREATION 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/templates/metrics_grafana_datasource.json.j2
>  PRE-CREATION 
>   
> ambari-server/src/test/python/stacks/2.0.6/AMBARI_METRICS/test_metrics_grafana.py
>  5bc1412 
> 
> Diff: https://reviews.apache.org/r/43337/diff/
> 
> 
> Testing
> ---
> 
> Manual testing done.
> 
> Added Unit tests
> 
> 
> Thanks,
> 
> Aravindan Vijayan
> 
>

Re: Review Request 43266: Config consistency checker

2016-02-09 Thread Myroslav Papirkovskyy


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


Ship it!




Ship It!

- Myroslav Papirkovskyy


On Лют. 6, 2016, 8:43 після полудня, Vitalyi Brodetskyi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43266/
> ---
> 
> (Updated Лют. 6, 2016, 8:43 після полудня)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Myroslav Papirkovskyy.
> 
> 
> Bugs: AMBARI-14948
> https://issues.apache.org/jira/browse/AMBARI-14948
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Command line utility to find inconsistencies in configs
> Services without configs
> Configs without services
> relationship between clusterconfig, serviceconfigmapping, and 
> clusterconfigmapping
> Do outter joins and find missing configs
> At least one should be selected for config type, compare known config types 
> vs expected in the stack, versions are incremental
> 
> 
> Diffs
> -
> 
>   ambari-server/sbin/ambari-server 47e2926 
>   
> ambari-server/src/main/java/org/apache/ambari/server/checks/CheckDatabaseHelper.java
>  PRE-CREATION 
>   ambari-server/src/main/python/ambari-server.py 8be79a5 
>   ambari-server/src/main/python/ambari_server/checkDatabase.py PRE-CREATION 
>   ambari-server/src/main/python/ambari_server/setupActions.py 686ac9a 
> 
> Diff: https://reviews.apache.org/r/43266/diff/
> 
> 
> Testing
> ---
> 
> Will add tests later
> 
> 
> Thanks,
> 
> Vitalyi Brodetskyi
> 
>

Re: Review Request 43326: Support Ambari Server/Agent and HDP install on Amazon Linux.

2016-02-09 Thread Andrew Onischuk



> On Feb. 8, 2016, 1:59 p.m., Sumit Mohanty wrote:
> > ambari-server/src/main/resources/stacks/HDP/2.2/repos/repoinfo.xml, line 32
> > 
> >
> > Could we have avoided introducing a new family and mapping amazon2015 
> > to say rhel6?
> 
> Andrew Onischuk wrote:
> We could put them in the same family if they had the same versioning like 
> oraclelinux and redhat and centos, but since the version is different, doing 
> such is not something we cannot do cleanly without hacking, and adding a 
> mapping for those versions somewhere.
> 
> Sumit Mohanty wrote:
> The OS mapping excercise is interpreting a file and normalizing content 
> using OS specific logic. So mappinng 2015 to 6 will be more of the same. 
> Also, the current solution will not automatically add support for 2016/2017 
> etc without more change. I would vote for reducing number of files to change 
> and not adding extra section to metainfo/repoinfo xml files considering 
> Amazon linux is equivalent to rhel/centos.
> 
> Andrew Onischuk wrote:
> this is not obvious for developer and end-user (that amazon2015 is 
> redhat6), that's what I meant to say. This will probably cause confusion and 
> bugs in future. If you still think we should hack it, please tell me, it's 
> not a problem to implement, I just think it gonna bring maintance problems in 
> future.
> 
> Sumit Mohanty wrote:
> Hmmm! that is a point. If there is a separate repo for Amazon linux then 
> it would be a good reason to keep it separate. But looks like centos6/centos7 
> are what can be used for Amazon/2015 and perhaps Amazon/2016. So the new 
> entry seems like a duplicate.

But os family logic is used all over the code, not only in repoinfo.xml.


- Andrew


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


On Feb. 8, 2016, 11:24 a.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43326/
> ---
> 
> (Updated Feb. 8, 2016, 11:24 a.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-14953
> https://issues.apache.org/jira/browse/AMBARI-14953
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Support Ambari Server/Agent and HDP install on Amazon Linux.
> 
> The issues which got fixed in the patch:
> 1. Python version was choosen incorrectly, causing install failures.
> 2. Postgresql data dir was choosen incorrectly, causing ambari-server start 
> and setup to fail.
> 3. Improve os_check.py to be able to detect amazon os
> 4. Add the entries for amazon2015 to repoinfo,xml and metainfo.xml, rmf.
> 
> 
> Diffs
> -
> 
>   ambari-agent/conf/unix/ambari-agent 50d13b1 
>   ambari-agent/conf/unix/install-helper.sh 35c67fb 
>   ambari-agent/pom.xml 38f436e 
>   ambari-common/src/main/python/ambari_commons/os_check.py 904a23b 
>   ambari-common/src/main/python/ambari_commons/resources/os_family.json 
> c0acc2c 
>   
> ambari-common/src/main/python/resource_management/core/providers/__init__.py 
> abb51c3 
>   
> ambari-common/src/main/python/resource_management/libraries/providers/__init__.py
>  44e9ca1 
>   ambari-common/src/main/unix/ambari-python-wrap 8dab946 
>   ambari-server/conf/unix/ambari-env.sh e463ca6 
>   ambari-server/conf/unix/install-helper.sh 9dbb2b8 
>   ambari-server/pom.xml f129983 
>   ambari-server/sbin/ambari-server 47e2926 
>   ambari-server/src/main/python/ambari_server/utils.py 2afcd1b 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/metainfo.xml
>  6ea4ca5 
>   
> ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/metainfo.xml
>  72f159a 
>   ambari-server/src/main/resources/stacks/HDP/2.2/repos/repoinfo.xml dbf8506 
>   ambari-server/src/main/resources/stacks/HDP/2.3/repos/repoinfo.xml 142b87d 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/services/ACCUMULO/metainfo.xml
>  352341b 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/ATLAS/metainfo.xml 
> fee10d3 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/services/FALCON/metainfo.xml 
> 6fdad8b 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/FLUME/metainfo.xml 
> 5031f85 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/metainfo.xml 
> 90a31f5 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/metainfo.xml 
> ca69195 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/HIVE/metainfo.xml 
> 0756a54 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/metainfo.xml 
> 330b542 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/KNOX/metainfo.xml 
> d1172b1

[jira] [Commented] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


[ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138696#comment-15138696
 ] 

Hadoop QA commented on AMBARI-14967:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12787038/BUG-52014_trunk.patch
  against trunk revision .

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5270//console

This message is automatically generated.

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> BUG-52014_branch-2_2.patch, BUG-52014_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14968) [Ambari Web UI] Hosts list for DataNode is not correct

2016-02-09 Thread Mukhadin Buzdov (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukhadin Buzdov updated AMBARI-14968:
-
Attachment: BUG_DataNode_Hosts.png

Attached screenshot.

> [Ambari Web UI] Hosts list for DataNode is not correct
> --
>
> Key: AMBARI-14968
> URL: https://issues.apache.org/jira/browse/AMBARI-14968
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
> Environment: _Operating system_: CentOS Linux 7 
> {color:gray}(7.1.1503){color}
> _Platform_: HDP 2.3.4.0
>Reporter: Mukhadin Buzdov
>Priority: Minor
> Attachments: BUG_DataNode_Hosts.png
>
>
> 5 nodes _HDP_ cluster: *Node1*, *Node2*, *Node3*, *Node4*, *Node5*.
> _DataNode_ was installed on *Node4* and *Node5*.
> *Steps to reproduce*:
> # Log in to _Ambari Web UI_.
> # Go to _Dashboard_.
> # Select _HDFS_ service from the left menu.
> # Press _DataNodes_ link in the _Summary_ section.
> {color:red}Will show *Node1* and *Node2* instances, which is not 
> correct.{color}
> *Additional information*:
> * Same for _HDFS RegionServer_, _YARN NodeManager_, etc.
> * Please see screenshot attached: *BUG_DataNode_Hosts.png*



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


 [ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonenko Alexander updated AMBARI-14967:
-
Attachment: BUG-52014_branch-2_2.patch

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> BUG-52014_branch-2_2.patch, BUG-52014_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


[ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138695#comment-15138695
 ] 

Andrii Babiichuk commented on AMBARI-14967:
---

+1 for the patch

> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> BUG-52014_branch-2_2.patch, BUG-52014_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14970) Remove support for HDP 2.1


[ 
https://issues.apache.org/jira/browse/AMBARI-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138997#comment-15138997
 ] 

Hudson commented on AMBARI-14970:
-

SUCCESS: Integrated in Ambari-branch-2.2 #307 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/307/])
AMBARI-14970. Remove support for HDP 2.1 (aonishuk) (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e74d08336eaafe8986b9ad3a7f0636fba10a6b0a])
* ambari-server/src/main/resources/stacks/HDP/2.1/metainfo.xml


> Remove support for HDP 2.1
> --
>
> Key: AMBARI-14970
> URL: https://issues.apache.org/jira/browse/AMBARI-14970
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14970.patch
>
>
> Disable the HDP 2.1 stack option from Ambari in Ambari 2.2.2 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14969) autobootstrap failed on Cenots7


[ 
https://issues.apache.org/jira/browse/AMBARI-14969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138998#comment-15138998
 ] 

Hudson commented on AMBARI-14969:
-

SUCCESS: Integrated in Ambari-branch-2.2 #307 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/307/])
AMBARI-14969. autobootstrap failed on Cenots7 (aonishuk) (aonishuk: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a8fd4a660b28f85c7194ea301b6ecbdfbc6bab6a])
* ambari-server/src/main/python/bootstrap.py


> autobootstrap failed on Cenots7
> ---
>
> Key: AMBARI-14969
> URL: https://issues.apache.org/jira/browse/AMBARI-14969
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14969.patch
>
>
> Confirm Hosts step was failed:
> 
> 
> #  
> /os-r7-eeameu-devdeploy-5.novalocal/var/run/ambari-server/bootstrap/1/bootstrap.err
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py", 
> line 35, in 
> from ambari_commons import OSCheck, OSConst
> ImportError: No module named ambari_commons
> 
> Cluster [artifacts](http://linux-jenkins.qe.hortonworks.com/home/jenkins/qe-
> artifacts/os-r7-eeameu-devdeploy/artifacts)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14971) UI - lag in Create Versions page doesn't show confirmation


[ 
https://issues.apache.org/jira/browse/AMBARI-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139009#comment-15139009
 ] 

Hadoop QA commented on AMBARI-14971:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12787066/AMBARI-14971.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
ambari-admin.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5277//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5277//console

This message is automatically generated.

> UI - lag in Create Versions page doesn't show confirmation
> --
>
> Key: AMBARI-14971
> URL: https://issues.apache.org/jira/browse/AMBARI-14971
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin
>Affects Versions: 2.2.1
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14971.patch
>
>
> I've seen this several times where adding a version through the Create 
> Versions page lags.
> I click on the "Save" button, don't get a confirmation, and it actually does 
> end up saving the entity.
> When I click on "Save" again, it shows an error that the version already 
> exists. I remember that before it used to show a confirmation and navigate 
> back to show all of the versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14971) UI - lag in Create Versions page doesn't show confirmation


[ 
https://issues.apache.org/jira/browse/AMBARI-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139068#comment-15139068
 ] 

Andrii Babiichuk commented on AMBARI-14971:
---

tested manually

> UI - lag in Create Versions page doesn't show confirmation
> --
>
> Key: AMBARI-14971
> URL: https://issues.apache.org/jira/browse/AMBARI-14971
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin
>Affects Versions: 2.2.1
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14971.patch
>
>
> I've seen this several times where adding a version through the Create 
> Versions page lags.
> I click on the "Save" button, don't get a confirmation, and it actually does 
> end up saving the entity.
> When I click on "Save" again, it shows an error that the version already 
> exists. I remember that before it used to show a confirmation and navigate 
> back to show all of the versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMBARI-14972) Add PK to servicecomponentdesiredstate Table To Support FK Relationships

2016-02-09 Thread Jonathan Hurley (JIRA)

Jonathan Hurley created AMBARI-14972:


 Summary: Add PK to servicecomponentdesiredstate Table To Support 
FK Relationships
 Key: AMBARI-14972
 URL: https://issues.apache.org/jira/browse/AMBARI-14972
 Project: Ambari
  Issue Type: Task
  Components: ambari-server
Affects Versions: 2.4.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: 2.4.0


The {{servicecomponentdesiredstate}} table currently uses a compound PK based 
off of the cluster ID, service name, and component name. There are several 
problems with this approach:

- Primary Keys should be data that's not part of the business logic of the 
system and not subject to be changed potentially (as strings are).
- Other tables referencing the {{servicecomponentdesiredstate}} table would now 
need knowledge of cluster/service/component in order to make the correct FK 
association. This leads to extra data being tracked as well as data duplication.
- Some databases, such as SQL Server, have problems with the indexing of 
compound PKs and may lead to deadlocks when querying and updating concurrently.

We should change this table so that it uses a simple PK for referencing. FK 
relationships as they exist today can still be maintained as long as a 
{{UNIQUE}} constraint is placed on the table. We should:

- Add a {{UNIQUE}} constraint to the former PK columns
- Add an {{INDEX}} to the former PK columns



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 43360: Add PK to servicecomponentdesiredstate Table To Support FK Relationships

2016-02-09 Thread Jonathan Hurley


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

Review request for Ambari, Dmitro Lisnichenko and Nate Cole.


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


Repository: ambari


Description
---

The {{servicecomponentdesiredstate}} table currently uses a compound PK based 
off of the cluster ID, service name, and component name. There are several 
problems with this approach:

- Primary Keys should be data that's not part of the business logic of the 
system and not subject to be changed potentially (as strings are).
- Other tables referencing the {{servicecomponentdesiredstate}} table would now 
need knowledge of cluster/service/component in order to make the correct FK 
association. This leads to extra data being tracked as well as data duplication.
- Some databases, such as SQL Server, have problems with the indexing of 
compound PKs and may lead to deadlocks when querying and updating concurrently.

We should change this table so that it uses a simple PK for referencing. FK 
relationships as they exist today can still be maintained as long as a 
{{UNIQUE}} constraint is placed on the table. We should:

- Add a {{UNIQUE}} constraint to the former PK columns
- Add an {{INDEX}} to the former PK columns


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ServiceComponentDesiredStateDAO.java
 341d1fd 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentDesiredStateEntity.java
 b57a467 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java
 f1af9b0 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ServiceComponentDesiredStateEntity.java
 bda2543 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ServiceComponentDesiredStateEntityPK.java
 d56e555 
  
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentImpl.java
 7e1dd1d 
  
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
 bfb6214 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog150.java
 b00b0e8 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog170.java
 91de82a 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog200.java
 70b8f9f 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog210.java
 faf4b96 
  ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql e1e2813 
  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 46b1983 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql c320720 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql e6e6103 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
56d0947 
  ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql 542b815 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 885e422 
  
ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java
 ddab65d 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog170Test.java
 6bbcab7 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
 8ff23f8 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog210Test.java
 83018a2 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalogHelper.java
 4c48972 

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


Testing
---

mvn clean test

Tests run: 3827, Failures: 0, Errors: 0, Skipped: 31

[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 30:19 min
[INFO] Finished at: 2016-02-08T23:23:05-05:00
[INFO] Final Memory: 50M/727M
[INFO] 


Thanks,

Jonathan Hurley

[jira] [Commented] (AMBARI-14957) Paging not working properly when filtering with alerts and hostname


[ 
https://issues.apache.org/jira/browse/AMBARI-14957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138996#comment-15138996
 ] 

Hudson commented on AMBARI-14957:
-

SUCCESS: Integrated in Ambari-branch-2.2 #307 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/307/])
AMBARI-14957 Paging not working properly when filtering with alerts and 
(atkach: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1bf225dcf4bff7ac999657ae17aeae7dbcbbc920])
* ambari-web/app/controllers/global/update_controller.js


> Paging not working properly when filtering with alerts and hostname
> ---
>
> Key: AMBARI-14957
> URL: https://issues.apache.org/jira/browse/AMBARI-14957
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-14957.patch, AMBARI-14957_branch-2.2.patch, 
> filter-not-working.mov
>
>
> On 1200 node cluster I enabled filter for alerts and then put in a hostname 
> filter... which showed hosts that did not match the filter. Also, the paging 
> showed 1 - 10 of 11 at bottom, but when I clicked on the right arrow, it 
> still showed the same page (video attached).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14967) Incorrect behavior of period combobox/metrics on Dashboard page after resetting all widgets to default


[ 
https://issues.apache.org/jira/browse/AMBARI-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138999#comment-15138999
 ] 

Hudson commented on AMBARI-14967:
-

SUCCESS: Integrated in Ambari-branch-2.2 #307 (See 
[https://builds.apache.org/job/Ambari-branch-2.2/307/])
AMBARI-14967. Incorrect behavior of period combobox/metrics on Dashboard 
(hiveww: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=4d930ba02025d980a8987738cee355fa50f7c027])
* ambari-web/test/views/main/dashboard/widgets_test.js
* ambari-web/app/views/main/dashboard/widgets.js


> Incorrect behavior of period combobox/metrics on Dashboard page after 
> resetting all widgets to default
> --
>
> Key: AMBARI-14967
> URL: https://issues.apache.org/jira/browse/AMBARI-14967
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: 1weekAfterReset.png, 1weekBeforeReset.png, 
> AMBARI-14967_22.patch, AMBARI-14967_trunk.patch
>
>
> Steps:
> # Go to Dashboard page.
> # Change metrics period to any value ("1 week", for example).
> # Click "Metric Actions">"Edit"->"Reset all widgets to default".
> Result: period combobox has old value (1 week), but metrics are displayed for 
> 1 hour. Also after opening and closing widget window data in widget changes 
> according to period (1 week).
> So, it is not fully clear - period value should be overwritten to "1 hour" as 
> default after "Reset all widgets to default" click or no but then metrics 
> should display correct info.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43360: Add PK to servicecomponentdesiredstate Table To Support FK Relationships

2016-02-09 Thread Jonathan Hurley


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

(Updated Feb. 9, 2016, 9:41 a.m.)


Review request for Ambari, Dmitro Lisnichenko and Nate Cole.


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


Repository: ambari


Description (updated)
---

The {{servicecomponentdesiredstate}} table currently uses a compound PK based 
off of the cluster ID, service name, and component name. There are several 
problems with this approach:

- Primary Keys should be data that's not part of the business logic of the 
system and not subject to be changed potentially (as strings are).
- Other tables referencing the {{servicecomponentdesiredstate}} table would now 
need knowledge of cluster/service/component in order to make the correct FK 
association. This leads to extra data being tracked as well as data duplication.
- Some databases, such as SQL Server, have problems with the indexing of 
compound PKs and may lead to deadlocks when querying and updating concurrently.

We should change this table so that it uses a simple PK for referencing. FK 
relationships as they exist today can still be maintained as long as a 
{{UNIQUE}} constraint is placed on the table. We should:

- Add a {{UNIQUE}} constraint to the former PK columns
- Add an {{INDEX}} to the former PK columns

This change is to enable new tables, such as the patch history table, to be 
able to reference a component without duplicating all of the existing 
information in {{servicecomponentdesiredstate}}


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ServiceComponentDesiredStateDAO.java
 341d1fd 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentDesiredStateEntity.java
 b57a467 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java
 f1af9b0 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ServiceComponentDesiredStateEntity.java
 bda2543 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ServiceComponentDesiredStateEntityPK.java
 d56e555 
  
ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentImpl.java
 7e1dd1d 
  
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
 bfb6214 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog150.java
 b00b0e8 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog170.java
 91de82a 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog200.java
 70b8f9f 
  
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog210.java
 faf4b96 
  ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql e1e2813 
  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 46b1983 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql c320720 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql e6e6103 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 
56d0947 
  ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql 542b815 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 885e422 
  
ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java
 ddab65d 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog170Test.java
 6bbcab7 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
 8ff23f8 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog210Test.java
 83018a2 
  
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalogHelper.java
 4c48972 

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


Testing
---

mvn clean test

Tests run: 3827, Failures: 0, Errors: 0, Skipped: 31

[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 30:19 min
[INFO] Finished at: 2016-02-08T23:23:05-05:00
[INFO] Final Memory: 50M/727M
[INFO] 


Thanks,

Jonathan Hurley

[jira] [Updated] (AMBARI-14972) Add PK to servicecomponentdesiredstate Table To Support FK Relationships

2016-02-09 Thread Jonathan Hurley (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hurley updated AMBARI-14972:
-
Attachment: AMBARI-14972.patch

> Add PK to servicecomponentdesiredstate Table To Support FK Relationships
> 
>
> Key: AMBARI-14972
> URL: https://issues.apache.org/jira/browse/AMBARI-14972
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-14972.patch
>
>
> The {{servicecomponentdesiredstate}} table currently uses a compound PK based 
> off of the cluster ID, service name, and component name. There are several 
> problems with this approach:
> - Primary Keys should be data that's not part of the business logic of the 
> system and not subject to be changed potentially (as strings are).
> - Other tables referencing the {{servicecomponentdesiredstate}} table would 
> now need knowledge of cluster/service/component in order to make the correct 
> FK association. This leads to extra data being tracked as well as data 
> duplication.
> - Some databases, such as SQL Server, have problems with the indexing of 
> compound PKs and may lead to deadlocks when querying and updating 
> concurrently.
> We should change this table so that it uses a simple PK for referencing. FK 
> relationships as they exist today can still be maintained as long as a 
> {{UNIQUE}} constraint is placed on the table. We should:
> - Add a {{UNIQUE}} constraint to the former PK columns
> - Add an {{INDEX}} to the former PK columns



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43331: Ambari overwrites auth_to_local rules in core-site.xml

2016-02-09 Thread Dmitro Lisnichenko

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

(Updated Feb. 9, 2016, 5 p.m.)

Review request for Ambari and Robert Levas.

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

Repository: ambari

Description
---

As part of the kerberization process, a specific auth_to_local ruleset is used.

The customer uses the "Manual" method of Kerbrizing their clusters. The
addition of the custom auth_to_local rules is added as a step in the process.

We found that during certain operations (such as moving the NameNode using the
Ambari wizard), many services such as HDFS fail to restart. Upon examination
of the failure it was revealed that Ambari is overwriting / modifying the
custom auth_to_local rules to something completely different. The change is
getting pushed to the nodes and the services fail to start up.

1) Secure the cluster using the "Manual" process as outlined in the Ambari
documentation.
2) Add the custom auth_to_local rules after the cluster is kerberized.
3) Attempt to peform an operation such as moving a NameNode.

Whenever services try to start / restart they fail. The logs from the
respective services show failures pointing to incorrect auth_to_local settings.

auth_to_local rules do not get modified or overwritten by ambari.

Depending on the failure, we have been able to work around it doing one of two
things:
1) Manually edit the core-site.xml where the service failed to start and start
the service from the command line.
2) Go back into the Ambari UI, fix the auth_to_local rules, save the config,
then restart the respective services.

Diffs (updated)
-

ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
b94da70

ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/configuration/kerberos-env.xml
c76e45a
ambari-web/app/data/HDP2/site_properties.js 7dfdbff

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

Testing
---

mvn clean test

Thanks,

Dmitro Lisnichenko

[jira] [Created] (AMBARI-14971) UI - lag in Create Versions page doesn't show confirmation

Andrii Babiichuk created AMBARI-14971:
-

 Summary: UI - lag in Create Versions page doesn't show confirmation
 Key: AMBARI-14971
 URL: https://issues.apache.org/jira/browse/AMBARI-14971
 Project: Ambari
  Issue Type: Bug
  Components: ambari-admin
Affects Versions: 2.2.1
Reporter: Andrii Babiichuk
Assignee: Andrii Babiichuk
 Fix For: 2.2.2


I've seen this several times where adding a version through the Create Versions 
page lags.
I click on the "Save" button, don't get a confirmation, and it actually does 
end up saving the entity.
When I click on "Save" again, it shows an error that the version already 
exists. I remember that before it used to show a confirmation and navigate back 
to show all of the versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 42712: AMBARI-14753: Capsched view: The view does not show the "effective" permissions of a queue

2016-02-09 Thread Akhil PB


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

(Updated Feb. 9, 2016, 11:58 a.m.)


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


Changes
---

Simplifyied logic of finding effective permission.


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


Repository: ambari


Description
---

Added effective permissions for acl_submit_application and acl_administer_queue 
in capshed.


Diffs (updated)
-

  
contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queue.js 
521b473 
  
contrib/views/capacity-scheduler/src/main/resources/ui/app/styles/application.less
 c0acf4f 
  
contrib/views/capacity-scheduler/src/main/resources/ui/app/templates/queue.hbs 
15550d1 

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


Testing
---

Done some manual unit testing in both ambari operator and non-operator mode.


Thanks,

Akhil PB

[jira] [Commented] (AMBARI-14859) Ranger - Keep all temporary files in the tmp directory defined in the Agent's configuration


[ 
https://issues.apache.org/jira/browse/AMBARI-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138842#comment-15138842
 ] 

Hudson commented on AMBARI-14859:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4297 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4297/])
AMBARI-14859. Ranger - Keep all temporary files in the tmp directory (gautam: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=472d62a7b3c0383ad4d95fe659ac87b4a8da3a1f])
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/ranger_admin.py
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/params.py
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/status_params.py
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/package/scripts/service_check.py


> Ranger - Keep all temporary files in the tmp directory defined in the Agent's 
> configuration
> ---
>
> Key: AMBARI-14859
> URL: https://issues.apache.org/jira/browse/AMBARI-14859
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.3.0
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14859.patch
>
>
> For stack implementation related to Ranger in Ambari : 
> Move temporary files created by Ambari code, they should reside in the tmp 
> directory defined in the Agent's configuration. (Refer: 
> https://reviews.apache.org/r/34296 )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14875) Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off


[ 
https://issues.apache.org/jira/browse/AMBARI-14875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138841#comment-15138841
 ] 

Hudson commented on AMBARI-14875:
-

SUCCESS: Integrated in Ambari-trunk-Commit #4297 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/4297/])
AMBARI-14875. Ranger Smart configs : Need to hide Audit DB properties if 
(gautam: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=12faf8cbae92cfa7836e7508ec2df8f2bd41d286])
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/themes/theme_version_1.json
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/themes/theme_version_2.json


> Ranger Smart configs : Need to hide Audit DB properties if Audit to DB is off
> -
>
> Key: AMBARI-14875
> URL: https://issues.apache.org/jira/browse/AMBARI-14875
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Gautam Borad
>Assignee: Gautam Borad
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-14875.1.patch, AMBARI-14875.patch
>
>
> As Ranger is moving towards allowing Ranger Admin to be installed without 
> using Audit to DB option. 
> Same set of changes will be needed on Ambari stacks to hide Audit to DB 
> related configs if Audit to DB is disabled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14753) Capsched view: The view does not show the "effective" permissions of a queue


[ 
https://issues.apache.org/jira/browse/AMBARI-14753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138889#comment-15138889
 ] 

Hadoop QA commented on AMBARI-14753:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12787057/AMBARI-14753.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
contrib/views/capacity-scheduler.

Test results: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5276//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/5276//console

This message is automatically generated.

> Capsched view: The view does not show the "effective" permissions of a queue
> 
>
> Key: AMBARI-14753
> URL: https://issues.apache.org/jira/browse/AMBARI-14753
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Sreenath Somarajapuram
> Attachments: AMBARI-14753.patch
>
>
> Steps:
> 1. Create a queue
> 2. Select option Custom for Submit Applications
> 3. Enter someuser in the text box below
> At this point you would assume only someuser can submit applications to the 
> queue. In fact, anyone can submit applications to the queue. This is because 
> the root queue allows anyone to submit applications and the effective 
> permissions are the union of the permissions of the queue hierarchy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14852) View: Capacity Scheduler View - Provide dropdown for scheduling calculator

2016-02-09 Thread Akhil PB (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Akhil PB updated AMBARI-14852:
--
Attachment: AMBARI-14852.patch

> View: Capacity Scheduler View - Provide dropdown for scheduling calculator
> --
>
> Key: AMBARI-14852
> URL: https://issues.apache.org/jira/browse/AMBARI-14852
> Project: Ambari
>  Issue Type: Task
>Reporter: Akhil PB
> Attachments: AMBARI-14852.patch
>
>
> *Cluster wide scheduling - Calculator*
> Provide dropdown for Scheduling calculator, with two options today:
> * Use Memory as resource in calculation
> * DRF for using all resources - memory, CPU, disk, network - in calculation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMBARI-14852) View: Capacity Scheduler View - Provide dropdown for scheduling calculator

2016-02-09 Thread Akhil PB (JIRA)


 [ 
https://issues.apache.org/jira/browse/AMBARI-14852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Akhil PB updated AMBARI-14852:
--
Attachment: (was: AMBARI-14852.1.patch)

> View: Capacity Scheduler View - Provide dropdown for scheduling calculator
> --
>
> Key: AMBARI-14852
> URL: https://issues.apache.org/jira/browse/AMBARI-14852
> Project: Ambari
>  Issue Type: Task
>Reporter: Akhil PB
> Attachments: AMBARI-14852.patch
>
>
> *Cluster wide scheduling - Calculator*
> Provide dropdown for Scheduling calculator, with two options today:
> * Use Memory as resource in calculation
> * DRF for using all resources - memory, CPU, disk, network - in calculation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 43009: View: Capacity Scheduler View - Provide dropdown for scheduling calculator

2016-02-09 Thread Akhil PB


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

(Updated Feb. 9, 2016, 1:24 p.m.)


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


Changes
---

Code made more readable


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


Repository: ambari


Description
---

Implement dropdown for scheduling calculator in capacity scheduler view.


Diffs (updated)
-

  
contrib/views/capacity-scheduler/src/main/resources/ui/app/controllers/queues.js
 416ff43 
  
contrib/views/capacity-scheduler/src/main/resources/ui/app/styles/application.less
 c0acf4f 
  
contrib/views/capacity-scheduler/src/main/resources/ui/app/templates/schedulerPanel.hbs
 4419aa0 

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


Testing
---

Done some manual unit testing. The dropdown will be only shown in ambari 
operator mode.


Thanks,

Akhil PB

[jira] [Updated] (AMBARI-14971) UI - lag in Create Versions page doesn't show confirmation


 [ 
https://issues.apache.org/jira/browse/AMBARI-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrii Babiichuk updated AMBARI-14971:
--
Attachment: AMBARI-14971.patch

> UI - lag in Create Versions page doesn't show confirmation
> --
>
> Key: AMBARI-14971
> URL: https://issues.apache.org/jira/browse/AMBARI-14971
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin
>Affects Versions: 2.2.1
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
> Fix For: 2.2.2
>
> Attachments: AMBARI-14971.patch
>
>
> I've seen this several times where adding a version through the Create 
> Versions page lags.
> I click on the "Save" button, don't get a confirmation, and it actually does 
> end up saving the entity.
> When I click on "Save" again, it shows an error that the version already 
> exists. I remember that before it used to show a confirmation and navigate 
> back to show all of the versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMBARI-14970) Remove support for HDP 2.1