[jira] [Created] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

Jaimin D Jetly created AMBARI-13069:
---

 Summary: Attributes of configuration property should be stack API 
driven
 Key: AMBARI-13069
 URL: https://issues.apache.org/jira/browse/AMBARI-13069
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server, ambari-web, stacks
Affects Versions: 2.2.0
Reporter: Jaimin D Jetly
Assignee: Jaimin D Jetly
 Fix For: 2.2.0






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

[jira] [Updated] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13069:

Description: 
*Following attributes of configuration properties should be made stack API 
driven:*
# Visibility of configuration property
# display name of configuration property
# Empty value validity of configuration property
# Restriction of being configured only once on installation
# overridable in config host group
# Name of the property should be hidden

*Achieving this task will be useful in following scenarios:*
# custom services could be added with less changes in ambari-web code
# Any issues related to configuration property attributes encountered on a 
deployed cluster can be addressed by making stack changes rather than 
redeploying ambari-web code with a fix. For example if a property tagged as not 
overridable if later desired to be made overridable on a deployed cluster will 
now require changing a boolean flag in stack configuration property rather than 
changing ambari-web code. 


> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 



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

[jira] [Updated] (AMBARI-12837) Server component should read HCFS type info from stack and propagate it in dictionary for agent and UI to consume

[Vijay Srinivasaraghavan (JIRA)]

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

Vijay Srinivasaraghavan updated AMBARI-12837:
-
Attachment: (was: AMBARI-12837.patch)

> Server component should read HCFS type info from stack and propagate it in 
> dictionary for agent and UI to consume
> -
>
> Key: AMBARI-12837
> URL: https://issues.apache.org/jira/browse/AMBARI-12837
> Project: Ambari
>  Issue Type: Task
>Affects Versions: trunk
>Reporter: Vijay Srinivasaraghavan
>Assignee: Vijay Srinivasaraghavan
> Attachments: AMBARI-12837.patch
>
>
> UI and agent code is using namenode configuration as a validation to check if 
> HDFS is selected or not and perform some HDFS specific operations like 
> creating /tmp directory, reading hadoop-env configurations like 
> hdfs_log_dir_prefix, dropping fast-hdfs-resource.jar etc., because of which 
> the configurations defined for HCFS types are not getting populated. The 
> ambari server component should tarverse thhrough the stack configuration and 
> populate (hadoop-env or cluster-env) dictionary if HCFS file system is 
> asscoated as part of the stack. The dictionary configuration should be used 
> in UI and agent code to allow FS operations require to bootstrap the cluster 
> deployment.



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

[jira] [Updated] (AMBARI-12837) Server component should read HCFS type info from stack and propagate it in dictionary for agent and UI to consume

[Vijay Srinivasaraghavan (JIRA)]

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

Vijay Srinivasaraghavan updated AMBARI-12837:
-
Attachment: AMBARI-12837.patch

> Server component should read HCFS type info from stack and propagate it in 
> dictionary for agent and UI to consume
> -
>
> Key: AMBARI-12837
> URL: https://issues.apache.org/jira/browse/AMBARI-12837
> Project: Ambari
>  Issue Type: Task
>Affects Versions: trunk
>Reporter: Vijay Srinivasaraghavan
>Assignee: Vijay Srinivasaraghavan
> Attachments: AMBARI-12837.patch
>
>
> UI and agent code is using namenode configuration as a validation to check if 
> HDFS is selected or not and perform some HDFS specific operations like 
> creating /tmp directory, reading hadoop-env configurations like 
> hdfs_log_dir_prefix, dropping fast-hdfs-resource.jar etc., because of which 
> the configurations defined for HCFS types are not getting populated. The 
> ambari server component should tarverse thhrough the stack configuration and 
> populate (hadoop-env or cluster-env) dictionary if HCFS file system is 
> asscoated as part of the stack. The dictionary configuration should be used 
> in UI and agent code to allow FS operations require to bootstrap the cluster 
> deployment.



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

[jira] [Updated] (AMBARI-12978) some atlas service properties are not properly displayed by UI

[Srimanth Gunturi (JIRA)]

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

Srimanth Gunturi updated AMBARI-12978:
--
Fix Version/s: 2.1.2

> some atlas service properties are not properly displayed by UI
> --
>
> Key: AMBARI-12978
> URL: https://issues.apache.org/jira/browse/AMBARI-12978
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.1.0
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> there are some property values in the atlas configuration that are modified 
> by the service scripts but those values are not reflected in the UI.  
> Specifically, the following properties should reflect their actual value in 
> the UI:
> 'atlas.http.authentication.kerberos.name.rules'
> 'atlas.server.bind.address'
> This can be achieved by moving their value setting logic to the stack advisor.



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

[jira] [Resolved] (AMBARI-12978) some atlas service properties are not properly displayed by UI

[Srimanth Gunturi (JIRA)]

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

Srimanth Gunturi resolved AMBARI-12978.
---
Resolution: Fixed

Committed to trunk and branch-2.1

> some atlas service properties are not properly displayed by UI
> --
>
> Key: AMBARI-12978
> URL: https://issues.apache.org/jira/browse/AMBARI-12978
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.1.0
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> there are some property values in the atlas configuration that are modified 
> by the service scripts but those values are not reflected in the UI.  
> Specifically, the following properties should reflect their actual value in 
> the UI:
> 'atlas.http.authentication.kerberos.name.rules'
> 'atlas.server.bind.address'
> This can be achieved by moving their value setting logic to the stack advisor.



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

[jira] [Created] (AMBARI-13070) HDP-specific list of packages should be removed from common-services

[Jayush Luniya (JIRA)]

Jayush Luniya created AMBARI-13070:
--

 Summary: HDP-specific list of packages should be removed from 
common-services
 Key: AMBARI-13070
 URL: https://issues.apache.org/jira/browse/AMBARI-13070
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.2
Reporter: Jayush Luniya
Assignee: Jayush Luniya
Priority: Critical
 Fix For: 2.1.2


In common-services/RANGER_KMS/0.5.0.2.3/metainfo.xml we specify the list of hdp 
packages. We should not have this list specific in common-services. We should 
move the list to stacks/HDP

{noformat}
  

  redhat7,redhat6,suse11
  

  ranger_2_3_*-kms
   
  


  debian7,ubuntu12,ubuntu14
  

  ranger-2-3-.*-kms
   
  

  
{noformat}

These cause issues in pluggable stacks. 



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

Re: Review Request 38065: leverage stack advisor to manifest config changes in hive due to atlas availability

[Srimanth Gunturi]

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

Ship it!


To make add-service wizard change configs in Hive also I had to add the extra 
depends-on in 'hive.exec.pre.hooks'

 
hive.exec.pre.hooks
org.apache.hadoop.hive.ql.hooks.ATSHook

  Comma-separated list of pre-execution hooks to be invoked for each 
statement.
  A pre-execution hook is specified as the name of a Java class which 
implements the
  org.apache.hadoop.hive.ql.hooks.ExecuteWithHookContext interface.


  
hive-env
hive_timeline_logging_enabled
  

  

- Srimanth Gunturi


On Sept. 10, 2015, 9:59 p.m., Jonathan Maron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38065/
> ---
> 
> (Updated Sept. 10, 2015, 9:59 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Sumit Mohanty, and Srimanth Gunturi.
> 
> 
> Bugs: AMBARI-12978
> https://issues.apache.org/jira/browse/AMBARI-12978
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Rather than make modifications that are not visible to the user via the 
> service scripts, the config changes that are required for hive when atlas is 
> available in the cluster have been moved to the stack advisor.  Some 
> important points:
> 
> 1)  atlas.cluster.name and atlas.rest.address are now configuration 
> properties that are defined in the service's hive-site.xml.  They therefore 
> appear as advanced hive-site properties in the UI.
> 2)  When atlas is not installed, these two properties are set to a space so 
> that hopefully no values are seen in the UI and the 'require-input' attribute 
> of atlas.cluster.name does not trigger a requirement to specify a value.
> 3)  When atlas is installed, the atlas.cluster.name is set to a null string 
> and the 'require-input' property appears to trigger the expected "value 
> required" logic in the UI.  This is important since the cluster name property 
> defines the namespace for the atlas queries associated with the given cluster 
> (atlas supports multiple hive instances).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  f4e4b25 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  affee98 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> c65e110 
>   ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py 
> bea7d60 
> 
> Diff: https://reviews.apache.org/r/38065/diff/
> 
> 
> Testing
> ---
> 
> - python unit tests
> - installation of clusters:
> 1)  Hive only followed by addition of atlas
> 2)  hive and atlas together
> 
> (NOTE:  still working thru some of the functional cluster test scenarios but 
> wanted to proceed with a review process in parallel)
> 
> 
> Thanks,
> 
> Jonathan Maron
> 
>

Re: Review Request 38065: leverage stack advisor to manifest config changes in hive due to atlas availability

[Srimanth Gunturi]

> On Sept. 11, 2015, 6:15 a.m., Srimanth Gunturi wrote:
> > To make add-service wizard change configs in Hive also I had to add the 
> > extra depends-on in 'hive.exec.pre.hooks'
> > 
> >  
> > hive.exec.pre.hooks
> > org.apache.hadoop.hive.ql.hooks.ATSHook
> > 
> >   Comma-separated list of pre-execution hooks to be invoked for each 
> > statement.
> >   A pre-execution hook is specified as the name of a Java class which 
> > implements the
> >   org.apache.hadoop.hive.ql.hooks.ExecuteWithHookContext interface.
> > 
> > 
> >   
> > hive-env
> > hive_timeline_logging_enabled
> >   
> > 
> >   


hive.exec.post.hooks
org.apache.hadoop.hive.ql.hooks.ATSHook

  Comma-separated list of post-execution hooks to be invoked for each 
statement.
  A post-execution hook is specified as the name of a Java class which 
implements the
  org.apache.hadoop.hive.ql.hooks.ExecuteWithHookContext interface.


  
hive-env
hive_timeline_logging_enabled
  
  
atlast-env
metadata_port
  

  


- Srimanth


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


On Sept. 10, 2015, 9:59 p.m., Jonathan Maron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38065/
> ---
> 
> (Updated Sept. 10, 2015, 9:59 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Sumit Mohanty, and Srimanth Gunturi.
> 
> 
> Bugs: AMBARI-12978
> https://issues.apache.org/jira/browse/AMBARI-12978
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Rather than make modifications that are not visible to the user via the 
> service scripts, the config changes that are required for hive when atlas is 
> available in the cluster have been moved to the stack advisor.  Some 
> important points:
> 
> 1)  atlas.cluster.name and atlas.rest.address are now configuration 
> properties that are defined in the service's hive-site.xml.  They therefore 
> appear as advanced hive-site properties in the UI.
> 2)  When atlas is not installed, these two properties are set to a space so 
> that hopefully no values are seen in the UI and the 'require-input' attribute 
> of atlas.cluster.name does not trigger a requirement to specify a value.
> 3)  When atlas is installed, the atlas.cluster.name is set to a null string 
> and the 'require-input' property appears to trigger the expected "value 
> required" logic in the UI.  This is important since the cluster name property 
> defines the namespace for the atlas queries associated with the given cluster 
> (atlas supports multiple hive instances).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  f4e4b25 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  affee98 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> c65e110 
>   ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py 
> bea7d60 
> 
> Diff: https://reviews.apache.org/r/38065/diff/
> 
> 
> Testing
> ---
> 
> - python unit tests
> - installation of clusters:
> 1)  Hive only followed by addition of atlas
> 2)  hive and atlas together
> 
> (NOTE:  still working thru some of the functional cluster test scenarios but 
> wanted to proceed with a review process in parallel)
> 
> 
> Thanks,
> 
> Jonathan Maron
> 
>

Re: Review Request 38220: [Preview] Stop-and-Start Upgrade: apply configs after all services have been stopped

[Alejandro Fernandez]

> On Sept. 11, 2015, 2:51 p.m., Jonathan Hurley wrote:
> > Why is this change needed for stop-the-world? You've already stopped the 
> > hive server and prevented clients from draining. You should not need to 
> > adjust the ports like we do for normal rolling upgrades.

You're right. Stop-the-World Upgrade doesn't need to temporarily change the 
hive port.


- Alejandro


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


On Sept. 9, 2015, 2:52 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38220/
> ---
> 
> (Updated Sept. 9, 2015, 2:52 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-13048
> https://issues.apache.org/jira/browse/AMBARI-13048
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Goal:
> for STW Upgrade, we'll need to apply configs after all services have been 
> stopped, and before calling hdp-select set all.
> 
> I think, we have to add separate groups before and after restart of HIVE 
> server to enforce config application order during UPGRADE and DONGRADE. Looks 
> like that is the only config change required for 2.2->2.2+ upgrade. Does such 
> upgrade pack definition look good?
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  01022b8 
> 
> Diff: https://reviews.apache.org/r/38220/diff/
> 
> 
> Testing
> ---
> 
> Preview
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38238: Bootstrap HDP 2.1 repo, cluster_version, and host_versions as CURRENT after upgrading Ambari

[Alejandro Fernandez]

> On Sept. 11, 2015, 7:56 a.m., Dmitro Lisnichenko wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java,
> >  line 63
> > 
> >
> > BTW, why we are targeting not upgrade UpgradeCatalog220? As I 
> > understand, changes anyway are not going to go into branch-2.1 and to 
> > current release?

Once we merge to trunk we'll need to call the same function from 
UpgradeCatalog220.


- Alejandro


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


On Sept. 10, 2015, 9:09 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38238/
> ---
> 
> (Updated Sept. 10, 2015, 9:09 p.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jonathan 
> Hurley, Nate Cole, and Sid Wagle.
> 
> 
> Bugs: AMBARI-13001
> https://issues.apache.org/jira/browse/AMBARI-13001
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> In Ambari 2.1, if the stack is HDP 2.1, the user does not even see a Stacks 
> and Versions page.
> The Ambari upgrade will have to bootstrap the versions by
> * Inserting repo_vesion for HDP 2.1
> * Inserting cluster_vesion as CURRENT
> * Inserting host_versions as CURRENT
> 
> This will then allow clicking on the "Perform Upgrade" button to call the 
> Upgrades endpoint correctly, which needs to know the source version in order 
> to calculate the upgrade pack and configs to use.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  2c9714e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ClusterVersionDAO.java
>  d3326b1 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/dao/CrudDAO.java 
> 4382f59 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostVersionDAO.java
>  a2ff211 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  6919e64 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog212Test.java
>  6268f91 
> 
> Diff: https://reviews.apache.org/r/38238/diff/
> 
> 
> Testing
> ---
> 
> Installed Ambari 2.1.1 with HDP 2.1.0.0
> Upgraded Ambari to 2.1.2 using my build, which updated the schema, and also 
> populated the repo_version, cluster_version, and host_version.
> In my install, only the repo_version had an id in the ambari_sequences table, 
> so I also tested that a value was inserted if not already present for all 3 
> entities.
> 
> I also added a basic upgrade pack for HDP 2.1 -> 2.3 for basic testing, which 
> can be started using a curl call.
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

[jira] [Commented] (AMBARI-13071) Unit test failure test_recommendAmsConfigurations

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13071:
-

FAILURE: Integrated in Ambari-trunk-Commit #3427 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3427/])
AMBARI-13071 Unit test failure test_recommendAmsConfigurations (dsen) (dsen: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=544f96e85e1c755032f75f7615dae8c574f1ceed)
* ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py


> Unit test failure test_recommendAmsConfigurations
> -
>
> Key: AMBARI-13071
> URL: https://issues.apache.org/jira/browse/AMBARI-13071
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks, test
>Affects Versions: 2.1.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13071.patch
>
>
> {code}
> ailed tests:
> FAIL: test_recommendAmsConfigurations 
> (test_stack_advisor.TestHDP22StackAdvisor)
> --
> Traceback (most recent call last):
>   File 
> "/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", 
> line 1999, in test_recommendAmsConfigurations
> self.assertEquals(configurations, expected)
> AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
> '512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
> {'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
>   {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
>'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
>'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
> '134217728',
>  
> 'hbase.regionserver.global.memstore.lowerLimit': '0.3',
>  
> 'hbase.regionserver.global.memstore.upperLimit': '0.35',
>  'hbase.rootdir': 
> 'file:///var/lib/ambari-metrics-collector/hbase',
>  'hbase.tmp.dir': 
> '/var/lib/ambari-metrics-collector/hbase-tmp',
>  'hbase_master_xmn_size': '128m',
>  'hfile.block.cache.size': '0.3'}},
> -  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': ' ',
> ? 
> -
> +  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': '',
> -  'timeline.metrics.host.aggregate.splitpoints': 
> ' ',
> ? 
>  -
> +  'timeline.metrics.host.aggregate.splitpoints': 
> '',
>'timeline.metrics.host.aggregator.ttl': 
> '86400'}}}
> {code}



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

[jira] [Commented] (AMBARI-13071) Unit test failure test_recommendAmsConfigurations

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13071:
-

SUCCESS: Integrated in Ambari-branch-2.1 #518 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/518/])
AMBARI-13071 Unit test failure test_recommendAmsConfigurations (dsen) (dsen: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=cfa8023d59288dd15d33612a6df182681a6c3938)
* ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py


> Unit test failure test_recommendAmsConfigurations
> -
>
> Key: AMBARI-13071
> URL: https://issues.apache.org/jira/browse/AMBARI-13071
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks, test
>Affects Versions: 2.1.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13071.patch
>
>
> {code}
> ailed tests:
> FAIL: test_recommendAmsConfigurations 
> (test_stack_advisor.TestHDP22StackAdvisor)
> --
> Traceback (most recent call last):
>   File 
> "/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", 
> line 1999, in test_recommendAmsConfigurations
> self.assertEquals(configurations, expected)
> AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
> '512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
> {'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
>   {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
>'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
>'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
> '134217728',
>  
> 'hbase.regionserver.global.memstore.lowerLimit': '0.3',
>  
> 'hbase.regionserver.global.memstore.upperLimit': '0.35',
>  'hbase.rootdir': 
> 'file:///var/lib/ambari-metrics-collector/hbase',
>  'hbase.tmp.dir': 
> '/var/lib/ambari-metrics-collector/hbase-tmp',
>  'hbase_master_xmn_size': '128m',
>  'hfile.block.cache.size': '0.3'}},
> -  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': ' ',
> ? 
> -
> +  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': '',
> -  'timeline.metrics.host.aggregate.splitpoints': 
> ' ',
> ? 
>  -
> +  'timeline.metrics.host.aggregate.splitpoints': 
> '',
>'timeline.metrics.host.aggregator.ttl': 
> '86400'}}}
> {code}



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

[jira] [Updated] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13069:

Description: 
*Following attributes of configuration properties should be made stack API 
driven:*
# Visibility of configuration property
# display name of configuration property
# Empty value validity of configuration property
# Restriction of being configured only once on installation
# overridable in config host group
# Name of the property should be hidden

*Achieving this task will be useful in following scenarios:*
# custom services could be added with less changes in ambari-web code
# Any issues related to configuration property attributes encountered on a 
deployed cluster can be addressed by making stack changes rather than 
redeploying ambari-web code with a fix. For example if a property tagged as not 
overridable if later desired to be made overridable on a deployed cluster will 
now require changing a boolean flag in stack configuration property rather than 
changing ambari-web code. 
# Config property only in a specific stack can be attributed without writing 
stack specific logic in ambari-web

  was:
*Following attributes of configuration properties should be made stack API 
driven:*
# Visibility of configuration property
# display name of configuration property
# Empty value validity of configuration property
# Restriction of being configured only once on installation
# overridable in config host group
# Name of the property should be hidden

*Achieving this task will be useful in following scenarios:*
# custom services could be added with less changes in ambari-web code
# Any issues related to configuration property attributes encountered on a 
deployed cluster can be addressed by making stack changes rather than 
redeploying ambari-web code with a fix. For example if a property tagged as not 
overridable if later desired to be made overridable on a deployed cluster will 
now require changing a boolean flag in stack configuration property rather than 
changing ambari-web code. 



> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
> Attachments: AMBARI-13069.patch
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 
> # Config property only in a specific stack can be attributed without writing 
> stack specific logic in ambari-web



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

Re: Review Request 38310: RU: Debian7 fails with multiple service check issues

[Jayush Luniya]

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

Ship it!


Ship It!

- Jayush Luniya


On Sept. 11, 2015, 5:40 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38310/
> ---
> 
> (Updated Sept. 11, 2015, 5:40 p.m.)
> 
> 
> Review request for Ambari and Mahadev Konar.
> 
> 
> Bugs: AMBARI-13077
> https://issues.apache.org/jira/browse/AMBARI-13077
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> -
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/service_check.py
>  e633dcb 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_service_check.py 
> bb0ce90 
> 
> Diff: https://reviews.apache.org/r/38310/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Created] (AMBARI-13077) RU: Debian7 fails with multiple service check issues

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-13077:


 Summary: RU: Debian7 fails with multiple service check issues
 Key: AMBARI-13077
 URL: https://issues.apache.org/jira/browse/AMBARI-13077
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.1.2


Cluster:  \- please stop when not needed - label
ambari-heavyrolling-upg-deb7-9475-split5  
Artifacts: 

There may be some config issues this is new test. So please report if there
are some.





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

Review Request 38310: RU: Debian7 fails with multiple service check issues

[Andrew Onischuk]

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

Review request for Ambari and Mahadev Konar.


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


Repository: ambari


Description
---

Cluster:  \- please stop when not needed - label
ambari-heavyrolling-upg-deb7-9475-split5  
Artifacts: 

There may be some config issues this is new test. So please report if there
are some.


Diffs
-

  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/service_check.py
 e633dcb 
  ambari-server/src/test/python/stacks/2.1/FALCON/test_service_check.py bb0ce90 

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


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

[jira] [Updated] (AMBARI-13074) Failure to restart HiveServer2

[Angel Villasmil (JIRA)]

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

Angel Villasmil updated AMBARI-13074:
-
Description: 
I'm super newbie using hadoop, it's my first installation, excuse my bad 
English, but I need your help, Hive service does not start properly, showing 
the following error:

{code}
*strong*stderr:   /var/lib/ambari-agent/data/errors-1504.txt*strong*
2015-09-10 21:20:47,928 - Error while executing command 'restart':
Traceback (most recent call last):
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 214, in execute
method(env)
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 371, in restart
self.start(env)
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 61, in start
rolling_restart=rolling_restart )
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_service.py",
 line 101, in hive_service
raise Fail("Connection to Hive server %s on port %s failed after %d 
seconds" % (address, port, elapsed_time))
Fail: Connection to Hive server bodazhdp1.cloudapp.net on port 1 failed 
after 140 seconds{code}

  was:
I'm super rookie using hadoop, it's my first installation, excuse my bad 
English, but I need your help, Hive service does not start properly, showing 
the following error:

{code}
*strong*stderr:   /var/lib/ambari-agent/data/errors-1504.txt*strong*
2015-09-10 21:20:47,928 - Error while executing command 'restart':
Traceback (most recent call last):
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 214, in execute
method(env)
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 371, in restart
self.start(env)
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 61, in start
rolling_restart=rolling_restart )
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_service.py",
 line 101, in hive_service
raise Fail("Connection to Hive server %s on port %s failed after %d 
seconds" % (address, port, elapsed_time))
Fail: Connection to Hive server bodazhdp1.cloudapp.net on port 1 failed 
after 140 seconds{code}


> Failure to restart HiveServer2
> --
>
> Key: AMBARI-13074
> URL: https://issues.apache.org/jira/browse/AMBARI-13074
> Project: Ambari
>  Issue Type: Bug
>  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
> Configs
>Affects Versions: 2.0.0
> Environment: - 4 Machines Azure A7 (1 Master and 3 slaves)
> - Ubuntu 12.04 LTS
> - HDP 2.2
>Reporter: Angel Villasmil
>  Labels: ambari, azure, hive, hortonworks, newbie, ubuntu
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> I'm super newbie using hadoop, it's my first installation, excuse my bad 
> English, but I need your help, Hive service does not start properly, showing 
> the following error:
> {code}
> *strong*stderr:   /var/lib/ambari-agent/data/errors-1504.txt*strong*
> 2015-09-10 21:20:47,928 - Error while executing command 'restart':
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 214, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 371, in restart
> self.start(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
>  line 61, in start
> rolling_restart=rolling_restart )
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_service.py",
>  line 101, in hive_service
> raise Fail("Connection to Hive server %s on port %s failed after %d 
> seconds" % (address, port, elapsed_time))
> Fail: Connection to Hive server bodazhdp1.cloudapp.net on port 1 failed 
> after 140 seconds{code}



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

[jira] [Commented] (AMBARI-13076) Incorrect UI behaviour if host registration request fails

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-13076:
--

+1  for the patch

> Incorrect UI behaviour if host registration request fails
> -
>
> Key: AMBARI-13076
> URL: https://issues.apache.org/jira/browse/AMBARI-13076
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13076.patch
>
>
> If host bootstrap request on step 3 of installer fails, UI should show popup 
> with this infornation and link to reload page and retry that request certain 
> number of times with certain interval. The repeated request is sent to wrong 
> URL (root level). Hence bootstrap results aren't processed, and user can 
> neither proceed nor go back from the current step.



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

Re: Review Request 38310: RU: Debian7 fails with multiple service check issues

[Mahadev Konar]

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

Ship it!


Ship It!

- Mahadev Konar


On Sept. 11, 2015, 5:40 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38310/
> ---
> 
> (Updated Sept. 11, 2015, 5:40 p.m.)
> 
> 
> Review request for Ambari and Mahadev Konar.
> 
> 
> Bugs: AMBARI-13077
> https://issues.apache.org/jira/browse/AMBARI-13077
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> -
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/service_check.py
>  e633dcb 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_service_check.py 
> bb0ce90 
> 
> Diff: https://reviews.apache.org/r/38310/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

Re: Review Request 38310: RU: Debian7 fails with multiple service check issues

[Mahadev Konar]

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


Please make sure HDP 2.2 works fine with these changes.

- Mahadev Konar


On Sept. 11, 2015, 5:40 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38310/
> ---
> 
> (Updated Sept. 11, 2015, 5:40 p.m.)
> 
> 
> Review request for Ambari and Mahadev Konar.
> 
> 
> Bugs: AMBARI-13077
> https://issues.apache.org/jira/browse/AMBARI-13077
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> -
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/service_check.py
>  e633dcb 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_service_check.py 
> bb0ce90 
> 
> Diff: https://reviews.apache.org/r/38310/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Updated] (AMBARI-13071) Unit test failure test_recommendAmsConfigurations

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-13071:

Attachment: AMBARI-13071.patch

> Unit test failure test_recommendAmsConfigurations
> -
>
> Key: AMBARI-13071
> URL: https://issues.apache.org/jira/browse/AMBARI-13071
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks, test
>Affects Versions: 2.1.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13071.patch
>
>
> {code}
> ailed tests:
> FAIL: test_recommendAmsConfigurations 
> (test_stack_advisor.TestHDP22StackAdvisor)
> --
> Traceback (most recent call last):
>   File 
> "/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", 
> line 1999, in test_recommendAmsConfigurations
> self.assertEquals(configurations, expected)
> AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
> '512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
> {'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
>   {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
>'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
>'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
> '134217728',
>  
> 'hbase.regionserver.global.memstore.lowerLimit': '0.3',
>  
> 'hbase.regionserver.global.memstore.upperLimit': '0.35',
>  'hbase.rootdir': 
> 'file:///var/lib/ambari-metrics-collector/hbase',
>  'hbase.tmp.dir': 
> '/var/lib/ambari-metrics-collector/hbase-tmp',
>  'hbase_master_xmn_size': '128m',
>  'hfile.block.cache.size': '0.3'}},
> -  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': ' ',
> ? 
> -
> +  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': '',
> -  'timeline.metrics.host.aggregate.splitpoints': 
> ' ',
> ? 
>  -
> +  'timeline.metrics.host.aggregate.splitpoints': 
> '',
>'timeline.metrics.host.aggregator.ttl': 
> '86400'}}}
> {code}



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

[jira] [Created] (AMBARI-13071) Unit test failure test_recommendAmsConfigurations

[Dmytro Sen (JIRA)]

Dmytro Sen created AMBARI-13071:
---

 Summary: Unit test failure test_recommendAmsConfigurations
 Key: AMBARI-13071
 URL: https://issues.apache.org/jira/browse/AMBARI-13071
 Project: Ambari
  Issue Type: Bug
  Components: stacks, test
Affects Versions: 2.1.2
Reporter: Dmytro Sen
Assignee: Dmytro Sen
Priority: Critical
 Fix For: 2.1.2


{code}
ailed tests:
FAIL: test_recommendAmsConfigurations (test_stack_advisor.TestHDP22StackAdvisor)
--
Traceback (most recent call last):
  File 
"/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", line 
1999, in test_recommendAmsConfigurations
self.assertEquals(configurations, expected)
AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
'512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
{'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
  {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
   'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
   'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
'134217728',
 
'hbase.regionserver.global.memstore.lowerLimit': '0.3',
 
'hbase.regionserver.global.memstore.upperLimit': '0.35',
 'hbase.rootdir': 
'file:///var/lib/ambari-metrics-collector/hbase',
 'hbase.tmp.dir': 
'/var/lib/ambari-metrics-collector/hbase-tmp',
 'hbase_master_xmn_size': '128m',
 'hfile.block.cache.size': '0.3'}},
-  'ams-site': {'properties': 
{'timeline.metrics.cluster.aggregate.splitpoints': ' ',
?   
  -

+  'ams-site': {'properties': 
{'timeline.metrics.cluster.aggregate.splitpoints': '',
-  'timeline.metrics.host.aggregate.splitpoints': ' 
',
?  -

+  'timeline.metrics.host.aggregate.splitpoints': 
'',
   'timeline.metrics.host.aggregator.ttl': 
'86400'}}}
{code}



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

[jira] [Commented] (AMBARI-12978) some atlas service properties are not properly displayed by UI

[Hudson (JIRA)]

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

Hudson commented on AMBARI-12978:
-

FAILURE: Integrated in Ambari-branch-2.1 #515 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/515/])
AMBARI-12978. some atlas service properties are not properly displayed by UI 
(Jonathan Maron via srimanth) (sgunturi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=219501f82f5d91795e14580b9830c2f11463b2dc)
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
* ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py
* ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py


> some atlas service properties are not properly displayed by UI
> --
>
> Key: AMBARI-12978
> URL: https://issues.apache.org/jira/browse/AMBARI-12978
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.1.0
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> there are some property values in the atlas configuration that are modified 
> by the service scripts but those values are not reflected in the UI.  
> Specifically, the following properties should reflect their actual value in 
> the UI:
> 'atlas.http.authentication.kerberos.name.rules'
> 'atlas.server.bind.address'
> This can be achieved by moving their value setting logic to the stack advisor.



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

[jira] [Commented] (AMBARI-12978) some atlas service properties are not properly displayed by UI

[Hudson (JIRA)]

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

Hudson commented on AMBARI-12978:
-

FAILURE: Integrated in Ambari-trunk-Commit #3424 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3424/])
AMBARI-12978. some atlas service properties are not properly displayed by UI 
(Jonathan Maron via srimanth) (sgunturi: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=36c135c29a98ef8516599eec74fa59787ffac4df)
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
* ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py
* ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml


> some atlas service properties are not properly displayed by UI
> --
>
> Key: AMBARI-12978
> URL: https://issues.apache.org/jira/browse/AMBARI-12978
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks
>Affects Versions: 2.1.0
>Reporter: Jonathan Maron
>Assignee: Jonathan Maron
> Fix For: 2.1.2
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> there are some property values in the atlas configuration that are modified 
> by the service scripts but those values are not reflected in the UI.  
> Specifically, the following properties should reflect their actual value in 
> the UI:
> 'atlas.http.authentication.kerberos.name.rules'
> 'atlas.server.bind.address'
> This can be achieved by moving their value setting logic to the stack advisor.



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

[jira] [Updated] (AMBARI-13024) Disable MetricsDataTransferMethodFactory for AMS

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-13024:

Attachment: (was: AMBARI-13024_2.patch)

> Disable MetricsDataTransferMethodFactory for AMS
> 
>
> Key: AMBARI-13024
> URL: https://issues.apache.org/jira/browse/AMBARI-13024
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.1.1
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.1.2
>
> Attachments: AMBARI-13024_4.patch
>
>
> Some metrics are double-edited(on MetricsDataTransferMethodFactory and 
> sink/monitor side)
> For instance, cpu-metrics are multiplied by 100 on monitor side, but divided 
> by MetricsDataTransferMethodFactory



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

[jira] [Updated] (AMBARI-13024) Disable MetricsDataTransferMethodFactory for AMS

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-13024:

Attachment: AMBARI-13024_4.patch

> Disable MetricsDataTransferMethodFactory for AMS
> 
>
> Key: AMBARI-13024
> URL: https://issues.apache.org/jira/browse/AMBARI-13024
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.1.1
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.1.2
>
> Attachments: AMBARI-13024_4.patch
>
>
> Some metrics are double-edited(on MetricsDataTransferMethodFactory and 
> sink/monitor side)
> For instance, cpu-metrics are multiplied by 100 on monitor side, but divided 
> by MetricsDataTransferMethodFactory



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

Review Request 38295: Unit test failure test_recommendAmsConfigurations

[Dmytro Sen]

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

Review request for Ambari and Vitalyi Brodetskyi.


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


Repository: ambari


Description
---

ailed tests:
FAIL: test_recommendAmsConfigurations (test_stack_advisor.TestHDP22StackAdvisor)
--
Traceback (most recent call last):
  File 
"/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", line 
1999, in test_recommendAmsConfigurations
self.assertEquals(configurations, expected)
AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
'512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
{'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
  {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
   'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
   'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
'134217728',
 
'hbase.regionserver.global.memstore.lowerLimit': '0.3',
 
'hbase.regionserver.global.memstore.upperLimit': '0.35',
 'hbase.rootdir': 
'file:///var/lib/ambari-metrics-collector/hbase',
 'hbase.tmp.dir': 
'/var/lib/ambari-metrics-collector/hbase-tmp',
 'hbase_master_xmn_size': '128m',
 'hfile.block.cache.size': '0.3'}},
-  'ams-site': {'properties': 
{'timeline.metrics.cluster.aggregate.splitpoints': ' ',
?   
  -

+  'ams-site': {'properties': 
{'timeline.metrics.cluster.aggregate.splitpoints': '',
-  'timeline.metrics.host.aggregate.splitpoints': ' 
',
?  -


Diffs
-

  ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py 6ce40ea 

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


Testing
---

--
Ran 240 tests in 8.148s

OK
--
Total run:793
Total errors:0
Total failures:0
OK


Thanks,

Dmytro Sen

[jira] [Commented] (AMBARI-13004) Fix Storm sink compile time deps with latest version updates

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13004:
-

FAILURE: Integrated in Ambari-trunk-Commit #3423 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3423/])
AMBARI-13004. Fix Storm sink compile time deps with latest version updates. 
Build number changed. (swagle) (swagle: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=bf8f798bce5ca7ec6cc7cf6f586f424f239da963)
* ambari-metrics/ambari-metrics-storm-sink/pom.xml
Revert "AMBARI-13004. Reverting unwanted commit. Fix Storm sink compile time 
deps with latest version updates. Build number changed. (swagle)" (swagle: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a13ae6ada55487dcd6757d83b3958e88b83660d2)
* ambari-metrics/ambari-metrics-storm-sink/pom.xml


> Fix Storm sink compile time deps with latest version updates
> 
>
> Key: AMBARI-13004
> URL: https://issues.apache.org/jira/browse/AMBARI-13004
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 2.1.2
>Reporter: Siddharth Wagle
>Assignee: Siddharth Wagle
> Fix For: 2.1.2
>
> Attachments: AMBARI-13004.patch
>
>
> Exception in storm logs due to dep changes in new version.
> {code}
> java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
> at 
> org.apache.hadoop.metrics2.sink.relocated.commons.httpclient.HttpMethodBase.(HttpMethodBase.java:220)
>  ~[ambari-metrics-storm-sink-with-common-2.1.2.183.jar:?]
> at 
> org.apache.hadoop.metrics2.sink.relocated.commons.httpclient.methods.ExpectContinueMethod.(ExpectContinueMethod.java:93)
>  ~[ambari-metrics-storm-sink-with-common-2.1.2.183.jar:?]
> at 
> org.apache.hadoop.metrics2.sink.relocated.commons.httpclient.methods.EntityEnclosingMethod.(EntityEnclosingMethod.java:119)
>  ~[ambari-metrics-storm-sink-with-common-2.1.2.183.jar:?]
> at 
> org.apache.hadoop.metrics2.sink.relocated.commons.httpclient.methods.PostMethod.(PostMethod.java:106)
>  ~[ambari-metrics-storm-sink-with-common-2.1.2.183.jar:?]
> at 
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.emitMetrics(AbstractTimelineMetricsSink.java:68)
>  ~[ambari-metrics-storm-sink-with-common-2.1.2.183.jar:?]
> at 
> org.apache.hadoop.metrics2.sink.storm.StormTimelineMetricsReporter.reportMetrics(StormTimelineMetricsReporter.java:139)
>  ~[ambari-metrics-storm-sink-with-common-2.1.2.183.jar:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_40]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_40]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_40]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_40]
> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93) 
> ~[clojure-1.6.0.jar:?]
> at 
> clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:313) 
> ~[clojure-1.6.0.jar:?]
> at 
> backtype.storm.ui.core$start_ganglia_reporter_BANG_$fn__10257.invoke(core.clj:1110)
>  ~[storm-core-0.10.0.2.3.2.0-2766.jar:0.10.0.2.3.2.0-2766]
> at 
> backtype.storm.timer$schedule_recurring$this__4156.invoke(timer.clj:99) 
> ~[storm-core-0.10.0.2.3.2.0-2766.jar:0.10.0.2.3.2.0-2766]
> at 
> backtype.storm.timer$mk_timer$fn__4139$fn__4140.invoke(timer.clj:50) 
> ~[storm-core-0.10.0.2.3.2.0-2766.jar:0.10.0.2.3.2.0-2766]
> at backtype.storm.timer$mk_timer$fn__4139.invoke(timer.clj:42) 
> ~[storm-core-0.10.0.2.3.2.0-2766.jar:0.10.0.2.3.2.0-2766]
> at clojure.lang.AFn.run(AFn.java:22) ~[clojure-1.6.0.jar:?]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_40]
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.codec.DecoderException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> ~[?:1.8.0_40]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_40]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> ~[?:1.8.0_40]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_40]
> ... 18 more
> {code}



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

Re: Review Request 38295: Unit test failure test_recommendAmsConfigurations

[Vitalyi Brodetskyi]

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

Ship it!


Ship It!

- Vitalyi Brodetskyi


On Вер. 11, 2015, 9:51 до полудня, Dmytro Sen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38295/
> ---
> 
> (Updated Вер. 11, 2015, 9:51 до полудня)
> 
> 
> Review request for Ambari and Vitalyi Brodetskyi.
> 
> 
> Bugs: AMBARI-13071
> https://issues.apache.org/jira/browse/AMBARI-13071
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> ailed tests:
> FAIL: test_recommendAmsConfigurations 
> (test_stack_advisor.TestHDP22StackAdvisor)
> --
> Traceback (most recent call last):
>   File 
> "/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", 
> line 1999, in test_recommendAmsConfigurations
> self.assertEquals(configurations, expected)
> AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
> '512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
> {'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
>   {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
>'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
>'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
> '134217728',
>  
> 'hbase.regionserver.global.memstore.lowerLimit': '0.3',
>  
> 'hbase.regionserver.global.memstore.upperLimit': '0.35',
>  'hbase.rootdir': 
> 'file:///var/lib/ambari-metrics-collector/hbase',
>  'hbase.tmp.dir': 
> '/var/lib/ambari-metrics-collector/hbase-tmp',
>  'hbase_master_xmn_size': '128m',
>  'hfile.block.cache.size': '0.3'}},
> -  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': ' ',
> ? 
> -
> 
> +  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': '',
> -  'timeline.metrics.host.aggregate.splitpoints': 
> ' ',
> ? 
>  -
> 
> 
> Diffs
> -
> 
>   ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py 
> 6ce40ea 
> 
> Diff: https://reviews.apache.org/r/38295/diff/
> 
> 
> Testing
> ---
> 
> --
> Ran 240 tests in 8.148s
> 
> OK
> --
> Total run:793
> Total errors:0
> Total failures:0
> OK
> 
> 
> Thanks,
> 
> Dmytro Sen
> 
>

Re: Review Request 38238: Bootstrap HDP 2.1 repo, cluster_version, and host_versions as CURRENT after upgrading Ambari

[Dmitro Lisnichenko]

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

Ship it!



ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
 (line 63)


BTW, why we are targeting not upgrade UpgradeCatalog220? As I understand, 
changes anyway are not going to go into branch-2.1 and to current release?


- Dmitro Lisnichenko


On Sept. 10, 2015, 9:09 p.m., Alejandro Fernandez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38238/
> ---
> 
> (Updated Sept. 10, 2015, 9:09 p.m.)
> 
> 
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, Jonathan 
> Hurley, Nate Cole, and Sid Wagle.
> 
> 
> Bugs: AMBARI-13001
> https://issues.apache.org/jira/browse/AMBARI-13001
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> In Ambari 2.1, if the stack is HDP 2.1, the user does not even see a Stacks 
> and Versions page.
> The Ambari upgrade will have to bootstrap the versions by
> * Inserting repo_vesion for HDP 2.1
> * Inserting cluster_vesion as CURRENT
> * Inserting host_versions as CURRENT
> 
> This will then allow clicking on the "Perform Upgrade" button to call the 
> Upgrades endpoint correctly, which needs to know the source version in order 
> to calculate the upgrade pack and configs to use.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  2c9714e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ClusterVersionDAO.java
>  d3326b1 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/dao/CrudDAO.java 
> 4382f59 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostVersionDAO.java
>  a2ff211 
>   
> ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog212.java
>  6919e64 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/upgrades/nonrolling-upgrade-2.3.xml
>  PRE-CREATION 
>   
> ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog212Test.java
>  6268f91 
> 
> Diff: https://reviews.apache.org/r/38238/diff/
> 
> 
> Testing
> ---
> 
> Installed Ambari 2.1.1 with HDP 2.1.0.0
> Upgraded Ambari to 2.1.2 using my build, which updated the schema, and also 
> populated the repo_version, cluster_version, and host_version.
> In my install, only the repo_version had an id in the ambari_sequences table, 
> so I also tested that a value was inserted if not already present for all 3 
> entities.
> 
> I also added a basic upgrade pack for HDP 2.1 -> 2.3 for basic testing, which 
> can be started using a curl call.
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>

[jira] [Commented] (AMBARI-12837) Server component should read HCFS type info from stack and propagate it in dictionary for agent and UI to consume

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-12837:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Server component should read HCFS type info from stack and propagate it in 
> dictionary for agent and UI to consume
> -
>
> Key: AMBARI-12837
> URL: https://issues.apache.org/jira/browse/AMBARI-12837
> Project: Ambari
>  Issue Type: Task
>Affects Versions: trunk
>Reporter: Vijay Srinivasaraghavan
>Assignee: Vijay Srinivasaraghavan
> Attachments: AMBARI-12837.patch
>
>
> UI and agent code is using namenode configuration as a validation to check if 
> HDFS is selected or not and perform some HDFS specific operations like 
> creating /tmp directory, reading hadoop-env configurations like 
> hdfs_log_dir_prefix, dropping fast-hdfs-resource.jar etc., because of which 
> the configurations defined for HCFS types are not getting populated. The 
> ambari server component should tarverse thhrough the stack configuration and 
> populate (hadoop-env or cluster-env) dictionary if HCFS file system is 
> asscoated as part of the stack. The dictionary configuration should be used 
> in UI and agent code to allow FS operations require to bootstrap the cluster 
> deployment.



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

Re: Review Request 38310: RU: Debian7 fails with multiple service check issues

[Andrew Onischuk]

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

(Updated Sept. 11, 2015, 6:44 p.m.)


Review request for Ambari and Mahadev Konar.


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


Repository: ambari


Description
---

-


Diffs (updated)
-

  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
 38c806b 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
 793a44b 
  
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py
 2cee73e 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py d2fa8ab 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py c4ff3dc 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py 
59f8a8f 
  ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py 
1711f69 
  ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_client.py 4fcfb33 
  ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py 3341511 
  ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_client.py 17c6137 
  ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_server.py 11570ed 

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


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

[jira] [Commented] (AMBARI-13076) Incorrect UI behaviour if host registration request fails

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13076:
-

FAILURE: Integrated in Ambari-trunk-Commit #3428 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3428/])
AMBARI-13076. Incorrect UI behaviour if host registration request fails 
(alexantonenko) (hiveww: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8cd6cfc6f01f224195a76e3ad362be41e69d17bb)
* ambari-web/app/controllers/wizard/step3_controller.js
* ambari-web/test/controllers/wizard/step7_test.js
* ambari-web/app/utils/polling.js
* ambari-web/test/mixins/common/reload_popup_test.js
* ambari-web/app/mixins/common/reload_popup.js
* ambari-web/test/controllers/wizard/step6_test.js
* ambari-web/test/controllers/wizard/step9_test.js
* ambari-web/app/controllers/wizard/step9_controller.js
* ambari-web/test/controllers/wizard/step8_test.js
* ambari-web/test/controllers/wizard/step3_test.js


> Incorrect UI behaviour if host registration request fails
> -
>
> Key: AMBARI-13076
> URL: https://issues.apache.org/jira/browse/AMBARI-13076
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.1
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 2.2.0
>
> Attachments: AMBARI-13076.patch
>
>
> If host bootstrap request on step 3 of installer fails, UI should show popup 
> with this infornation and link to reload page and retry that request certain 
> number of times with certain interval. The repeated request is sent to wrong 
> URL (root level). Hence bootstrap results aren't processed, and user can 
> neither proceed nor go back from the current step.



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

[jira] [Commented] (AMBARI-13075) Make ambari-server robust/debuggable if user accidentally adds a config type to a config groups when it does not exist as base type

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13075:
-

SUCCESS: Integrated in Ambari-branch-2.1 #519 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/519/])
AMBARI-13075. Make ambari-server robust/debuggable if user accidentally adds a 
config type to a config groups when it does not exist as base type (aonishuk) 
(aonishuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=28689a80be836d4242867af3c9ff61ab76a0a311)
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProvider.java
* 
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProviderTest.java


> Make ambari-server robust/debuggable if user accidentally adds a config type 
> to a config groups when it does not exist as base type
> ---
>
> Key: AMBARI-13075
> URL: https://issues.apache.org/jira/browse/AMBARI-13075
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>
> This was reported by a customer. Customer accidentally added a config of type
> `hivesite` to a config group.
> **Call**
> 
> 
> 
> curl 'http://ambhost:8080/api/v1/clusters/TSGHDP/config_groups/3' -X PUT 
> -H "X-Requested-By: ambari" --user admin:admin --data 
> '[{"ConfigGroup":{"id":3,"cluster_name":"HDP","group_name":"Hive_custom_group","tag":"HIVE","description":"","hosts":[{"host_name":"abc.local"}],"service_config_version_note":"hive
>  custom group tx timeout 
> property 
> change","desired_configs":[{"type":"hivesite","tag":"newversionforjdbcurl","properties":{"hive.txn.timeout":"310","javax.jdo.option.ConnectionURL":"jdbc:mysql://abc.local/hive2?createDatabaseIfNotExist=true"}}]}}]'
>  --compressed
> 
> This resulted in ambari-server failing to process agent heartbeat and throwing
> NPE.
> 
> 
> 
> 13 Aug 2015 10:36:28,961  WARN [ambari-hearbeat-monitor] 
> HeartbeatMonitor:129 - Exception received
> java.lang.NullPointerException
>   at 
> org.apache.ambari.server.state.host.HostImpl.getDesiredHostConfigs(HostImpl.java:1349)
>   at 
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:109)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.createStatusCommand(HeartbeatMonitor.java:253)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.generateStatusCommands(HeartbeatMonitor.java:218)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.doWork(HeartbeatMonitor.java:190)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.run(HeartbeatMonitor.java:121)
>   at java.lang.Thread.run(Thread.java:745)
> 



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

Re: Review Request 38310: RU: Debian7 fails with multiple service check issues

[Andrew Onischuk]

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


Uploaded a new patch, because I was told that some other SC failed. Included 
that into this one.
Tested on 2.2 and 2.3

- Andrew Onischuk


On Sept. 11, 2015, 6:44 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38310/
> ---
> 
> (Updated Sept. 11, 2015, 6:44 p.m.)
> 
> 
> Review request for Ambari and Mahadev Konar.
> 
> 
> Bugs: AMBARI-13077
> https://issues.apache.org/jira/browse/AMBARI-13077
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> -
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
>  38c806b 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
>  793a44b 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py
>  2cee73e 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py 
> d2fa8ab 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py 
> c4ff3dc 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py 
> 59f8a8f 
>   
> ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py 
> 1711f69 
>   ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_client.py 
> 4fcfb33 
>   ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py 
> 3341511 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_client.py 
> 17c6137 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_server.py 
> 11570ed 
> 
> Diff: https://reviews.apache.org/r/38310/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

Re: Review Request 38312: Upgrade Packs Should Define Skippable Failed Slave/Clients

[Alejandro Fernandez]

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

Ship it!


Ship It!

- Alejandro Fernandez


On Sept. 11, 2015, 6:43 p.m., Jonathan Hurley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38312/
> ---
> 
> (Updated Sept. 11, 2015, 6:43 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez and Nate Cole.
> 
> 
> Bugs: AMBARI-13078
> https://issues.apache.org/jira/browse/AMBARI-13078
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Although the upgrade endpoint can be used to marked failures as being 
> automatically skipped:
> 
> {code:title=POST api/v1/clusters/c1/upgrades}
> {
>   "Upgrade": {
> "repository_version": "2.3.0.0-2545",
> "skip_failures": true
>   }
> }
> {code}
> 
> The upgrade packs should also allow this behavior by default:
> 
> {code}
>   false
>   false
> {code}
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
>  d087945 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/entities/UpgradeGroupEntity.java
>  7b57184 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/stack/UpgradePack.java
>  9691292 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.2.xml 
> d67671c 
>   ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
> 04befaf 
>   ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
> 4719558 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java
>  7d2c117 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/stack/UpgradePackTest.java
>  e073b43 
>   
> ambari-server/src/test/resources/stacks/HDP/2.2.0/upgrades/upgrade_test_skip_failures.xml
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/38312/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

[jira] [Updated] (AMBARI-13060) Kerberos: Allow user to specify additional realms for auth-to-local rules

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-13060:
--
Description: 
Allow user to specify additional realms for auth-to-local rules. This will add 
_default_ rules for the specified realm(s) to the generated auth-to-local rule 
sets. For example:

{noformat}
RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
{noformat}

The value should be a (comma) delimited list of realm names set in set of 
global properties in the Kerberos Descriptor.

  was:
Allow user to specify additional realms for auth-to-local rules. This will add 
_default_ rules for the specified realm(s) to the generated auth-to-local rule 
sets. For example:

{noformat}
RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
{noformat}

The value should be a (comma) delimited list of realm names set in 
{{kerberos-env/user_realms}}.


> Kerberos: Allow user to specify additional realms for auth-to-local rules
> -
>
> Key: AMBARI-13060
> URL: https://issues.apache.org/jira/browse/AMBARI-13060
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos, kerberos-wizard
> Fix For: 2.1.2
>
> Attachments: AMBARI-13060_branch-2.1_01.patch, 
> AMBARI-13060_trunk_01.patch
>
>
> Allow user to specify additional realms for auth-to-local rules. This will 
> add _default_ rules for the specified realm(s) to the generated auth-to-local 
> rule sets. For example:
> {noformat}
> RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
> {noformat}
> The value should be a (comma) delimited list of realm names set in set of 
> global properties in the Kerberos Descriptor.



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

[jira] [Commented] (AMBARI-13077) RU: Debian7 fails with multiple service check issues

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13077:
-

FAILURE: Integrated in Ambari-trunk-Commit #3429 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3429/])
AMBARI-13077. RU: Debian7 fails with multiple service check issues (aonishuk) 
(aonishuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=542bbf22e801b01a52229ab12c07f5ef5d7a7f21)
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py
* ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_client.py
* ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py
* 
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py
* 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
* ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_server.py
* ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_client.py


> RU: Debian7 fails with multiple service check issues
> 
>
> Key: AMBARI-13077
> URL: https://issues.apache.org/jira/browse/AMBARI-13077
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>
> Cluster:  \- please stop when not needed - label
> ambari-heavyrolling-upg-deb7-9475-split5  
> Artifacts:  /ambari-heavyrolling-upg-deb7-9475-split5/ambari-heavyrolling-upg-1441985459/a
> rtifacts/screenshots/com.hw.ambari.ui.tests.monitoring.admin_page.TestRollingU
> pgrade/test060_StartPerformUpgrade/>
> There may be some config issues this is new test. So please report if there
> are some.



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

[jira] [Updated] (AMBARI-13060) Kerberos: Allow user to specify additional realms for auth-to-local rules

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-13060:
--
Attachment: AMBARI-13060_trunk_01.patch
AMBARI-13060_branch-2.1_01.patch

> Kerberos: Allow user to specify additional realms for auth-to-local rules
> -
>
> Key: AMBARI-13060
> URL: https://issues.apache.org/jira/browse/AMBARI-13060
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos, kerberos-wizard
> Fix For: 2.1.2
>
> Attachments: AMBARI-13060_branch-2.1_01.patch, 
> AMBARI-13060_trunk_01.patch
>
>
> Allow user to specify additional realms for auth-to-local rules. This will 
> add _default_ rules for the specified realm(s) to the generated auth-to-local 
> rule sets. For example:
> {noformat}
> RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
> {noformat}
> The value should be a (comma) delimited list of realm names set in set of 
> global properties in the Kerberos Descriptor.



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

Review Request 38312: Upgrade Packs Should Define Skippable Failed Slave/Clients

[Jonathan Hurley]

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

Review request for Ambari, Alejandro Fernandez and Nate Cole.


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


Repository: ambari


Description
---

Although the upgrade endpoint can be used to marked failures as being 
automatically skipped:

{code:title=POST api/v1/clusters/c1/upgrades}
{
  "Upgrade": {
"repository_version": "2.3.0.0-2545",
"skip_failures": true
  }
}
{code}

The upgrade packs should also allow this behavior by default:

{code}
  false
  false
{code}


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeResourceProvider.java
 d087945 
  
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/UpgradeGroupEntity.java
 7b57184 
  
ambari-server/src/main/java/org/apache/ambari/server/state/stack/UpgradePack.java
 9691292 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.2.xml 
d67671c 
  ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/upgrade-2.3.xml 
04befaf 
  ambari-server/src/main/resources/stacks/HDP/2.3/upgrades/upgrade-2.3.xml 
4719558 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/UpgradeResourceProviderTest.java
 7d2c117 
  
ambari-server/src/test/java/org/apache/ambari/server/state/stack/UpgradePackTest.java
 e073b43 
  
ambari-server/src/test/resources/stacks/HDP/2.2.0/upgrades/upgrade_test_skip_failures.xml
 PRE-CREATION 

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


Testing
---

mvn clean test


Thanks,

Jonathan Hurley

[jira] [Commented] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13069:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
> Attachments: AMBARI-13069.patch
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 
> # Config property only in a specific stack can be attributed without writing 
> stack specific logic in ambari-web



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

[jira] [Resolved] (AMBARI-13077) RU: Debian7 fails with multiple service check issues

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk resolved AMBARI-13077.
--
Resolution: Fixed

Committed to trunk and branch-2.1

> RU: Debian7 fails with multiple service check issues
> 
>
> Key: AMBARI-13077
> URL: https://issues.apache.org/jira/browse/AMBARI-13077
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>
> Cluster:  \- please stop when not needed - label
> ambari-heavyrolling-upg-deb7-9475-split5  
> Artifacts:  /ambari-heavyrolling-upg-deb7-9475-split5/ambari-heavyrolling-upg-1441985459/a
> rtifacts/screenshots/com.hw.ambari.ui.tests.monitoring.admin_page.TestRollingU
> pgrade/test060_StartPerformUpgrade/>
> There may be some config issues this is new test. So please report if there
> are some.



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

[jira] [Commented] (AMBARI-13070) HDP-specific list of packages should be removed from common-services

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-13070:


Trunk:
commit e8f2f2fd767bab5fff67c163d672ee7fdf2d5054
Author: Jayush Luniya 
Date:   Fri Sep 11 12:45:41 2015 -0700

AMBARI-13070: HDP-specific list of packages should be removed from 
common-services (jluniya)


Branch-2.1
commit 16a09064357ae9e207152a49cd171ad74b882c5c
Author: Jayush Luniya 
Date:   Fri Sep 11 12:45:41 2015 -0700

AMBARI-13070: HDP-specific list of packages should be removed from 
common-services (jluniya)

> HDP-specific list of packages should be removed from common-services
> 
>
> Key: AMBARI-13070
> URL: https://issues.apache.org/jira/browse/AMBARI-13070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.2
>
>
> In common-services/RANGER_KMS/0.5.0.2.3/metainfo.xml we specify the list of 
> hdp packages. We should not have this list specific in common-services. We 
> should move the list to stacks/HDP
> {noformat}
>   
> 
>   redhat7,redhat6,suse11
>   
> 
>   ranger_2_3_*-kms
>
>   
> 
> 
>   debian7,ubuntu12,ubuntu14
>   
> 
>   ranger-2-3-.*-kms
>
>   
> 
>   
> {noformat}
> These cause issues in pluggable stacks. 



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

Issue with building Ambari 2.1.0 from the source

[Obradovic, Milos (Contractor)]

Hello All,

I'm trying to build Ambari 2.1.0  from the source

wget 
http://www.apache.org/dist/ambari/ambari-2.1.0/apache-ambari-2.1.0-src.tar.gz
tar xfvz apache-ambari-2.1.0-src.tar.gz
cd apache-ambari-2.1.0-src
mvn versions:set -DnewVersion=2.1.0

pushd ambari-metrics
mvn versions:set -DnewVersion=2.1.0
popd

//Then when try to execute
mvn -B clean install package jdeb:jdeb -DnewVersion=2.1.0 -DskipTests 
-Dpython.ver="python >= 2.6"

//I'm getting  this error

[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec 
(compile-npm) on project ambari-web: Command execution failed. Cannot run 
program "npm" (in directory 
"/home/obrad/Desktop/apache-ambari-2.1.0-src/ambari-web"): error=2, No such 
file or directory -> [Help 1]
Do you have any idea what should I do to fix this issue?

Thanks,
Milos

Re: Issue with building Ambari 2.1.0 from the source

[Jonathan Hurley]

It looks like you don’t have npm installed to build the web client. You can 
follow the instructions here: 
https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Development to help 
you get your development environment setup.


On Sep 11, 2015, at 3:22 PM, Obradovic, Milos (Contractor) 
> wrote:

Hello All,

I'm trying to build Ambari 2.1.0  from the source

wget 
http://www.apache.org/dist/ambari/ambari-2.1.0/apache-ambari-2.1.0-src.tar.gz
tar xfvz apache-ambari-2.1.0-src.tar.gz
cd apache-ambari-2.1.0-src
mvn versions:set -DnewVersion=2.1.0

pushd ambari-metrics
mvn versions:set -DnewVersion=2.1.0
popd

//Then when try to execute
mvn -B clean install package jdeb:jdeb -DnewVersion=2.1.0 -DskipTests 
-Dpython.ver="python >= 2.6"

//I'm getting  this error

[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec 
(compile-npm) on project ambari-web: Command execution failed. Cannot run 
program "npm" (in directory 
"/home/obrad/Desktop/apache-ambari-2.1.0-src/ambari-web"): error=2, No such 
file or directory -> [Help 1]
Do you have any idea what should I do to fix this issue?

Thanks,
Milos

[jira] [Created] (AMBARI-13079) atlas web ui alert is triggered if default port is changed

[Jonathan Maron (JIRA)]

Jonathan Maron created AMBARI-13079:
---

 Summary: atlas web ui alert is triggered if default port is changed
 Key: AMBARI-13079
 URL: https://issues.apache.org/jira/browse/AMBARI-13079
 Project: Ambari
  Issue Type: Bug
  Components: stacks
Affects Versions: 2.1.0
Reporter: Jonathan Maron


If the default HTTP port is modified for atlas, the web UI alert is triggered 
since the alert appears to still attempt to connect to the default port.  
Though the alerts.json definition file for Atlas appears to be correct, there 
is obviously an issue in the alert definition.



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

Review Request 38314: leverage atlas configured port properties for server

[Jonathan Maron]

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

Review request for Ambari, Erik Bergenholtz, Sumit Mohanty, and Srimanth 
Gunturi.


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


Repository: ambari


Description
---

Atlas now has persisted properties for both the HTTP and HTTPS listener ports.  
Rather than using the command line port option, change the service definition 
to leverage these persisted properties.


Diffs
-

  ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/alerts.json 
f324707 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/application-properties.xml
 386fbdc 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/configuration/atlas-env.xml
 991d7fe 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/metadata_server.py
 6c5a87e 
  
ambari-server/src/main/resources/common-services/ATLAS/0.1.0.2.3/package/scripts/params.py
 a7c6d7a 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
 2783b78 
  
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml
 5811e4f 
  ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
dd287b2 
  ambari-server/src/test/python/stacks/2.3/ATLAS/test_metadata_server.py 
cff446f 
  ambari-server/src/test/python/stacks/2.3/configs/default.json 688065c 
  ambari-web/app/models/quick_links.js b1f95d6 

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


Testing
---

python unit tests:

--
Ran 230 tests in 6.879s

OK
--
Total run:784
Total errors:0
Total failures:0
OK

Tested property change in an installed ambari cluster.


Thanks,

Jonathan Maron

Re: Review Request 38310: RU: Debian7 fails with multiple service check issues

[Andrew Onischuk]

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


Also found some commoness between those failure. Seems it was only missing 
permissions for -env.sh files. Seems like they wasn't packaged with the 
package. That's why when they were created with umask 027 with Ambari, the 
issue happened.

- Andrew Onischuk


On Sept. 11, 2015, 6:44 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38310/
> ---
> 
> (Updated Sept. 11, 2015, 6:44 p.m.)
> 
> 
> Review request for Ambari and Mahadev Konar.
> 
> 
> Bugs: AMBARI-13077
> https://issues.apache.org/jira/browse/AMBARI-13077
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> -
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py
>  38c806b 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
>  793a44b 
>   
> ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py
>  2cee73e 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py 
> d2fa8ab 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py 
> c4ff3dc 
>   ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py 
> 59f8a8f 
>   
> ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py 
> 1711f69 
>   ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_client.py 
> 4fcfb33 
>   ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py 
> 3341511 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_client.py 
> 17c6137 
>   ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_server.py 
> 11570ed 
> 
> Diff: https://reviews.apache.org/r/38310/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Commented] (AMBARI-13007) Stopping ambari-server may kill ambari-agent running on the same machine in some cases

[Jayush Luniya (JIRA)]

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

Jayush Luniya commented on AMBARI-13007:


commit 02fcea6c3c38f2fff4e73bdc3d235cf87477d4e2
Author: Jayush Luniya 
Date:   Fri Sep 11 13:08:25 2015 -0700

AMBARI-13007: Stopping ambari-server may kill ambari-agent running on the 
same machine in some cases (Nahappan Somasundaram via jluniya)

> Stopping ambari-server may kill ambari-agent running on the same machine in 
> some cases
> --
>
> Key: AMBARI-13007
> URL: https://issues.apache.org/jira/browse/AMBARI-13007
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.2.0
>
>
> Launch multinode Ambari clusters using a simple python script. It logs in to 
> every node via ssh and runs a shell script:
> {code}
> #!/usr/bin/env bash
> while [[ $# > 0 ]]
> do
>   key="$1"
>   case ${key} in
>   --server)
> ASERVER="$2"# Server hostname
> shift # past argument
>   ;;
>   --noserver)
> NOSERVER="NOSERVER"  # Don't install/start server
>   ;;
>   *)
> echo unknown option
> exit 1
>   ;;
>   esac
>   shift # past argument or value
> done
> yum clean all
> curl 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos6/2.x/latest/trunk/ambaribn.repo
>  > /etc/yum.repos.d/ambari.repo
> # server
> if [ "${ASERVER}" = $(hostname -f) ] && [ -z "${NOSERVER}" ] ; then
>   yum install sudo postgresql-server wget -y
>   rpm -i /tmp/rpms/ambari-server*.rpm
>   # Disable iptables
>   iptables -F
>   ambari-server setup -s
>   # Enable remote debug
>   sed -rie 's/-server -XX:NewRatio/-server 
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 
> -XX:NewRatio/g'  /usr/sbin/ambari_server_main.py
>   ## Sleep until debugger connects
>   # sed -rie 
> 's/dt_socket,server=y,suspend=.,address=5005/dt_socket,server=y,suspend=y,address=5005/g'
>  /usr/sbin/ambari-server.py
>   # Fix an issue with UI client version
>   gunzip /usr/lib/ambari-server/web/javascripts/app.js.gz
>   amb=$(ambari-server --version); sed -i "s/App\.version = '';/App.version = 
> '$amb';/" /usr/lib/ambari-server/web/javascripts/app.js
>   gzip /usr/lib/ambari-server/web/javascripts/app.js
>   # Increase task timeout
>   sed -ri 
> 's/agent.package.install.task.timeout=1800/agent.package.install.task.timeout=3600/g'
>  /etc/ambari-server/conf/ambari.properties
>   find /var/lib/ambari-server/resources/ -name metainfo.xml | xargs -L 1 sed 
> -ri 's/[[:digit:]]+[[:digit:]]*<\//1800<\//g'
>   # Start the server
>   ambari-server start -v || exit 1
> fi
> # Agent
> iptables -F
> yum clean all
> yum install -y wget
> rpm -i /tmp/rpms/ambari-agent*.rpm
> # Replace server hostname
> sed -rie "s/hostname=localhost/hostname=$ASERVER/g" 
> /etc/ambari-agent/conf/ambari-agent.ini
> # Enable debug mode at agent
> # sed -rie 's/=INFO/=DEBUG/g' /etc/ambari-agent/conf/ambari-agent.ini
> ambari-agent start || exit 1
> {code}
> When I restart ambari-server, agent running on the same node is killed with 
> 100% probability. That is because it is launched in the same process group 
> with ambari-server, and ambari-server kills everything that belongs to it's 
> process group. I assume that this situation is common for launching 
> ambari-server and ambari-agent from the same shell script via ssh, or maybe 
> also via configuration management tools like puppet/chef/etc. (did not check 
> this assumption).
> *More info:*
> {code}
> [root@dlysnichenko-ru3-1 ~]# ps -ejH
>   PID  PGID   SID TTY  TIME CMD
>  1584  1584  1584 ?00:00:00   sshd
>  2659  2659  2659 ?00:00:00 sshd
>  2662  2662  2662 pts/000:00:00   bash
>  3268  3268  2662 pts/000:00:00 ps
>  2056  2041  2041 ?00:00:00   postmaster
>  2058  2058  2058 ?00:00:00 postmaster
>  2060  2060  2060 ?00:00:00 postmaster
>  2061  2061  2061 ?00:00:00 postmaster
>  2062  2062  2062 ?00:00:00 postmaster
>  2063  2063  2063 ?00:00:00 postmaster
>  2380  2380  2380 ?00:00:00 postmaster
>  2397  2397  2397 ?00:00:00 postmaster
>  2649  2649  2649 ?00:00:01 postmaster
>  2654  2654  2654 ?00:00:00 postmaster
>  2655  2655  2655 ?00:00:00 postmaster
>  2656  2656  2656 ?00:00:00 postmaster
>  2360  1644  1644 ?00:00:59   java
>  2507  1644  1644 ?00:00:00   python2.6
>  2515  1644  1644 ?00:00:01 python2.6
>  3230  3230  3230 ?00:00:00   anacron
> 

[jira] [Commented] (AMBARI-13070) HDP-specific list of packages should be removed from common-services

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13070:
-

SUCCESS: Integrated in Ambari-branch-2.1 #520 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/520/])
AMBARI-13070: HDP-specific list of packages should be removed from 
common-services (jluniya) (jluniya: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=16a09064357ae9e207152a49cd171ad74b882c5c)
* ambari-server/src/main/resources/common-services/SPARK/1.3.1.2.3/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/services/SPARK/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/services/OOZIE/metainfo.xml
* ambari-server/src/main/resources/common-services/OOZIE/4.2.0.2.3/metainfo.xml
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/metainfo.xml
* ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/metainfo.xml
* ambari-server/src/main/resources/common-services/SPARK/1.2.0.2.2/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/SPARK/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/metainfo.xml
* 
ambari-server/src/main/resources/common-services/SLIDER/0.60.0.2.2/metainfo.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER_KMS/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/KAFKA/metainfo.xml
* ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/KNOX/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/SLIDER/metainfo.xml
* ambari-common/src/main/python/pluggable_stack_definition/configs/SAPHD.json
* ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml
* 
ambari-common/src/main/python/pluggable_stack_definition/resources/PHD/custom_stack_map.js


> HDP-specific list of packages should be removed from common-services
> 
>
> Key: AMBARI-13070
> URL: https://issues.apache.org/jira/browse/AMBARI-13070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.2
>
>
> In common-services/RANGER_KMS/0.5.0.2.3/metainfo.xml we specify the list of 
> hdp packages. We should not have this list specific in common-services. We 
> should move the list to stacks/HDP
> {noformat}
>   
> 
>   redhat7,redhat6,suse11
>   
> 
>   ranger_2_3_*-kms
>
>   
> 
> 
>   debian7,ubuntu12,ubuntu14
>   
> 
>   ranger-2-3-.*-kms
>
>   
> 
>   
> {noformat}
> These cause issues in pluggable stacks. 



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

[jira] [Commented] (AMBARI-13077) RU: Debian7 fails with multiple service check issues

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13077:
-

SUCCESS: Integrated in Ambari-branch-2.1 #520 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/520/])
AMBARI-13077. RU: Debian7 fails with multiple service check issues (aonishuk) 
(aonishuk: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3c4ae9cc77c0ebbbf3b49b61488c35f549fa93c9)
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_regionserver.py
* 
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py
* ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_server.py
* ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_client.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_client.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_phoenix_queryserver.py
* 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/hbase.py
* ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py
* ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_client.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/falcon.py


> RU: Debian7 fails with multiple service check issues
> 
>
> Key: AMBARI-13077
> URL: https://issues.apache.org/jira/browse/AMBARI-13077
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>
> Cluster:  \- please stop when not needed - label
> ambari-heavyrolling-upg-deb7-9475-split5  
> Artifacts:  /ambari-heavyrolling-upg-deb7-9475-split5/ambari-heavyrolling-upg-1441985459/a
> rtifacts/screenshots/com.hw.ambari.ui.tests.monitoring.admin_page.TestRollingU
> pgrade/test060_StartPerformUpgrade/>
> There may be some config issues this is new test. So please report if there
> are some.



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

[jira] [Updated] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13069:

Attachment: AMBARI-13069_3.patch

Attaching [^AMBARI-13069_3.patch] as the previous patch revision has FE merge 
conflicts on the latest trunk due to another recent commit.

Verified that ambari-web unit tests passes after resolving merge conflicts:


  9439 tests complete (12 seconds)
  95 tests pending




> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
> Attachments: AMBARI-13069.patch, AMBARI-13069_2.patch, 
> AMBARI-13069_3.patch
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 
> # Config property only in a specific stack can be attributed without writing 
> stack specific logic in ambari-web



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

[jira] [Updated] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13069:

Attachment: AMBARI-13069_2.patch

[^AMBARI-13069_2.patch] does *unit* attribute externalization correctly and 
resolves makes property name for some *log4j files* hidden as they were 
previously.

> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
> Attachments: AMBARI-13069.patch, AMBARI-13069_2.patch
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 
> # Config property only in a specific stack can be attributed without writing 
> stack specific logic in ambari-web



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

Re: Review Request 38303: Attributes of configuration property should be stack API driven

[Jaimin Jetly]

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

(Updated Sept. 11, 2015, 11:28 p.m.)


Review request for Ambari, Srimanth Gunturi and Yusaku Sako.


Changes
---

2nd revision of the patch does unit attribute externalization correctly and 
resolves makes property name for some log4j files hidden as they were 
previously. Also resolves merge conflicts on the latest trunk


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


Repository: ambari


Description
---

*Following attributes of configuration properties should be made stack API 
driven:*
# Visibility of configuration property exposed from API as visible value 
attribute
# display name of configuration property exposed from API as display_name 
# Empty value validity of configuration property exposed from API as 
empty_value_valid value attribute
# Restriction of being configured only once on installation exposed from API as 
editable_only_at_install value attribute
# overridable in config host group exposed from aPI as overridable vlaue 
attribute
# Name of the property should be hidden exposed from API as show_property_name 
value attribute

*Achieving this task will be useful in following scenarios:*
# custom services could be added with less changes in ambari-web code
# Any issues related to configuration property attributes encountered on a 
deployed cluster can be addressed by making stack changes rather than 
redeploying ambari-web code with a fix. For example if a property tagged as not 
overridable if later desired to be made overridable on a deployed cluster will 
now require changing a boolean flag in stack configuration property rather than 
changing ambari-web code.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackLevelConfigurationResourceProvider.java
 0525488 
  
ambari-server/src/main/java/org/apache/ambari/server/state/ValueAttributesInfo.java
 8054c54 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-env.xml
 67da50e 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-log4j.xml
 e8f6e56 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-site.xml
 2a7e083 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-env.xml
 e84193c 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-log4j.xml
 64cc9d3 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-security-site.xml
 6f60736 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-log4j.xml
 6d3703e 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml
 5c7a39b 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml
 75178d2 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-startup.properties.xml
 451ebb5 
  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-conf.xml
 8ff764b 
  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-env.xml
 e150478 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-env.xml
 03db5df 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-log4j.xml
 64cc9d3 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-site.xml
 b224bef 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
 4cb2274 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-log4j.xml
 08822eb 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
 dc7f661 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-env.xml
 2d0a182 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-exec-log4j.xml
 fb852f7 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-log4j.xml
 a978ef7 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
 2783b78 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-log4j.xml
 0ded4d4 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-site.xml
 33f7f21 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/configuration/kafka-env.xml
 94f4975 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/configuration/kafka-log4j.xml
 901859e 
  

Review Request 38318: Kerberos: Allow user to specify additional realms for auth-to-local rules

[Robert Levas]

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

Review request for Ambari, Jaimin Jetly, Jonathan Hurley, and Robert Nettleton.


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


Repository: ambari


Description
---

Allow user to specify additional realms for auth-to-local rules. This will add 
_default_ rules for the specified realm(s) to the generated auth-to-local rule 
sets. For example:

```
RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
```

The value should be a (comma) delimited list of realm names set in set of 
global properties in the Kerberos Descriptor.


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/AuthToLocalBuilder.java
 00e8291 
  
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
 11f578f 
  ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/kerberos.json 
df99bce 
  ambari-server/src/main/resources/stacks/HDP/2.0.6/kerberos.json 03198dc 
  
ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java
 14c66a2 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/AuthToLocalBuilderTest.java
 9e65b5e 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
 f28a19b 
  ambari-server/src/test/resources/stacks/HDP/2.0.8/kerberos.json cf49786 
  ambari-web/app/mixins/wizard/addSecurityConfigs.js d14d09e 

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


Testing
---

Manually tested existing KDC and manual options, both with various additional 
realm specifications (empty, single, multiple, multiple with random spaces 
between). Updated realms after enabling Kerberos.

Local test results: PASSED

Jenkins test results: *PENDING*


Thanks,

Robert Levas

[jira] [Commented] (AMBARI-13059) Alerts: HDFS Finalized alert needs to be for HDFS service

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13059:
-

FAILURE: Integrated in Ambari-branch-2.1 #516 (See 
[https://builds.apache.org/job/Ambari-branch-2.1/516/])
AMBARI-13059 Alerts: HDFS Finalized alert needs to be for HDFS service 
(dlysnichenko) (dlysnichenko: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=13b9f0f45119ed73a55834f0f7d354e9612ee230)
* ambari-server/src/main/resources/alerts.json
* 
ambari-server/src/test/java/org/apache/ambari/server/alerts/HDFSUpgradeFinalizedStatusRunnableTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/metadata/AgentAlertDefinitionsTest.java
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/alerts/alert_upgrade_finalized.py
* 
ambari-server/src/main/java/org/apache/ambari/server/alerts/HDFSUpgradeFinalizedStatusRunnable.java
* 
ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java
* ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/alerts.json


> Alerts: HDFS Finalized alert needs to be for HDFS service
> -
>
> Key: AMBARI-13059
> URL: https://issues.apache.org/jira/browse/AMBARI-13059
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.2
>
> Attachments: AMBARI-13059.patch
>
>
> Why is the HDFS finalized alert an ambari server alert? And not HDFS, for the 
> NameNode? Could it be SCRIPT alert, or metric alert on HDFS? Just seems very 
> strange to be on AMbari server, because then it always getting registered, 
> even in clusters w/o HDFS.
> {code}
> {
>   "href" : 
> "http://server:8080/api/v1/clusters/MyCluster/alert_definitions/40;,
>   "AlertDefinition" : {
> "cluster_name" : "MyCluster",
> "component_name" : "AMBARI_SERVER",
> "description" : "This service-level alert is triggered if HDFS is not in 
> the finalized state",
> "enabled" : true,
> "id" : 40,
> "ignore_host" : false,
> "interval" : 10,
> "label" : "HDFS Upgrade Finalized State",
> "name" : "ambari_upgrade_finalized_state",
> "scope" : "SERVICE",
> "service_name" : "AMBARI",
> "source" : {
>   "class" : 
> "org.apache.ambari.server.alerts.HDFSUpgradeFinalizedStatusRunnable",
>   "type" : "SERVER"
> }
>   }
> }
> {code}



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

[jira] [Commented] (AMBARI-13071) Unit test failure test_recommendAmsConfigurations

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13071:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Unit test failure test_recommendAmsConfigurations
> -
>
> Key: AMBARI-13071
> URL: https://issues.apache.org/jira/browse/AMBARI-13071
> Project: Ambari
>  Issue Type: Bug
>  Components: stacks, test
>Affects Versions: 2.1.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13071.patch
>
>
> {code}
> ailed tests:
> FAIL: test_recommendAmsConfigurations 
> (test_stack_advisor.TestHDP22StackAdvisor)
> --
> Traceback (most recent call last):
>   File 
> "/ambari-server/src/test/python/stacks/2.2/common/test_stack_advisor.py", 
> line 1999, in test_recommendAmsConfigurations
> self.assertEquals(configurations, expected)
> AssertionError: {'ams-env': {'properties': {'metrics_collector_heapsize': 
> '512m'}}, 'ams-hbase-e [truncated]... != {'ams-env': {'properties': 
> {'metrics_collector_heapsize': '512m'}}, 'ams-hbase-e [truncated]...
>   {'ams-env': {'properties': {'metrics_collector_heapsize': '512m'}},
>'ams-hbase-env': {'properties': {'hbase_master_heapsize': '540m'}},
>'ams-hbase-site': {'properties': {'hbase.hregion.memstore.flush.size': 
> '134217728',
>  
> 'hbase.regionserver.global.memstore.lowerLimit': '0.3',
>  
> 'hbase.regionserver.global.memstore.upperLimit': '0.35',
>  'hbase.rootdir': 
> 'file:///var/lib/ambari-metrics-collector/hbase',
>  'hbase.tmp.dir': 
> '/var/lib/ambari-metrics-collector/hbase-tmp',
>  'hbase_master_xmn_size': '128m',
>  'hfile.block.cache.size': '0.3'}},
> -  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': ' ',
> ? 
> -
> +  'ams-site': {'properties': 
> {'timeline.metrics.cluster.aggregate.splitpoints': '',
> -  'timeline.metrics.host.aggregate.splitpoints': 
> ' ',
> ? 
>  -
> +  'timeline.metrics.host.aggregate.splitpoints': 
> '',
>'timeline.metrics.host.aggregator.ttl': 
> '86400'}}}
> {code}



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

[jira] [Commented] (AMBARI-13024) Disable MetricsDataTransferMethodFactory for AMS

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13024:


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

{color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

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

This message is automatically generated.

> Disable MetricsDataTransferMethodFactory for AMS
> 
>
> Key: AMBARI-13024
> URL: https://issues.apache.org/jira/browse/AMBARI-13024
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server
>Affects Versions: 2.1.1
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
> Fix For: 2.1.2
>
> Attachments: AMBARI-13024_4.patch
>
>
> Some metrics are double-edited(on MetricsDataTransferMethodFactory and 
> sink/monitor side)
> For instance, cpu-metrics are multiplied by 100 on monitor side, but divided 
> by MetricsDataTransferMethodFactory



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

Re: Review Request 38298: Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitro Lisnichenko]

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

(Updated Sept. 11, 2015, 2:14 p.m.)


Review request for Ambari, Andrew Onischuk and Dmytro Sen.


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


Repository: ambari


Description
---

Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites
Need to backport AMBARI-12935 to 2.0.maint


Diffs
-

  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params.py
 29e8dfb 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py
 0736663 
  ambari-server/src/test/python/stacks/2.0.6/YARN/test_nodemanager.py 0956565 
  ambari-server/src/test/python/stacks/2.0.6/YARN/test_resourcemanager.py 
d32fc1a 

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


Testing
---

in progress


Thanks,

Dmitro Lisnichenko

Re: Review Request 38065: leverage stack advisor to manifest config changes in hive due to atlas availability

[Jonathan Maron]

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


Is it spelled correctly in the actual file?



   atlast-env
   metadata_port

  
The code snippet you pasted indicates "atlast-env"...

- Jonathan Maron


On Sept. 10, 2015, 9:59 p.m., Jonathan Maron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38065/
> ---
> 
> (Updated Sept. 10, 2015, 9:59 p.m.)
> 
> 
> Review request for Ambari, John Speidel, Sumit Mohanty, and Srimanth Gunturi.
> 
> 
> Bugs: AMBARI-12978
> https://issues.apache.org/jira/browse/AMBARI-12978
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Rather than make modifications that are not visible to the user via the 
> service scripts, the config changes that are required for hive when atlas is 
> available in the cluster have been moved to the stack advisor.  Some 
> important points:
> 
> 1)  atlas.cluster.name and atlas.rest.address are now configuration 
> properties that are defined in the service's hive-site.xml.  They therefore 
> appear as advanced hive-site properties in the UI.
> 2)  When atlas is not installed, these two properties are set to a space so 
> that hopefully no values are seen in the UI and the 'require-input' attribute 
> of atlas.cluster.name does not trigger a requirement to specify a value.
> 3)  When atlas is installed, the atlas.cluster.name is set to a null string 
> and the 'require-input' property appears to trigger the expected "value 
> required" logic in the UI.  This is important since the cluster name property 
> defines the namespace for the atlas queries associated with the given cluster 
> (atlas supports multiple hive instances).
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  f4e4b25 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
>  affee98 
>   ambari-server/src/main/resources/stacks/HDP/2.3/services/stack_advisor.py 
> c65e110 
>   ambari-server/src/test/python/stacks/2.3/common/test_stack_advisor.py 
> bea7d60 
> 
> Diff: https://reviews.apache.org/r/38065/diff/
> 
> 
> Testing
> ---
> 
> - python unit tests
> - installation of clusters:
> 1)  Hive only followed by addition of atlas
> 2)  hive and atlas together
> 
> (NOTE:  still working thru some of the functional cluster test scenarios but 
> wanted to proceed with a review process in parallel)
> 
> 
> Thanks,
> 
> Jonathan Maron
> 
>

[jira] [Commented] (AMBARI-13072) 'All Datanodes' not present for HDFS in Create Widget Wizard

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-13072:
---

committed to trunk and branch-2.1

> 'All Datanodes' not present for HDFS in Create Widget Wizard
> 
>
> Key: AMBARI-13072
> URL: https://issues.apache.org/jira/browse/AMBARI-13072
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13072.patch, Screen Shot 2015-09-10 at 10.36.07 
> AM.png
>
>
> Please see the screenshot attached. 'All Datanodes' was present in the list 
> for HDFS which is missing now. 



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

[jira] [Commented] (AMBARI-13059) Alerts: HDFS Finalized alert needs to be for HDFS service

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13059:
-

FAILURE: Integrated in Ambari-trunk-Commit #3425 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3425/])
AMBARI-13059 Alerts: HDFS Finalized alert needs to be for HDFS service 
(dlysnichenko) (dlysnichenko: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f41ed7f1e67b21b4463d4330da8ed8090f222e29)
* 
ambari-server/src/test/java/org/apache/ambari/server/metadata/AgentAlertDefinitionsTest.java
* 
ambari-server/src/test/java/org/apache/ambari/server/alerts/HDFSUpgradeFinalizedStatusRunnableTest.java
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/alerts/alert_upgrade_finalized.py
* ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/alerts.json
* 
ambari-server/src/test/java/org/apache/ambari/server/api/services/AmbariMetaInfoTest.java
* 
ambari-server/src/main/java/org/apache/ambari/server/alerts/HDFSUpgradeFinalizedStatusRunnable.java
* ambari-server/src/main/resources/alerts.json


> Alerts: HDFS Finalized alert needs to be for HDFS service
> -
>
> Key: AMBARI-13059
> URL: https://issues.apache.org/jira/browse/AMBARI-13059
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.2
>
> Attachments: AMBARI-13059.patch
>
>
> Why is the HDFS finalized alert an ambari server alert? And not HDFS, for the 
> NameNode? Could it be SCRIPT alert, or metric alert on HDFS? Just seems very 
> strange to be on AMbari server, because then it always getting registered, 
> even in clusters w/o HDFS.
> {code}
> {
>   "href" : 
> "http://server:8080/api/v1/clusters/MyCluster/alert_definitions/40;,
>   "AlertDefinition" : {
> "cluster_name" : "MyCluster",
> "component_name" : "AMBARI_SERVER",
> "description" : "This service-level alert is triggered if HDFS is not in 
> the finalized state",
> "enabled" : true,
> "id" : 40,
> "ignore_host" : false,
> "interval" : 10,
> "label" : "HDFS Upgrade Finalized State",
> "name" : "ambari_upgrade_finalized_state",
> "scope" : "SERVICE",
> "service_name" : "AMBARI",
> "source" : {
>   "class" : 
> "org.apache.ambari.server.alerts.HDFSUpgradeFinalizedStatusRunnable",
>   "type" : "SERVER"
> }
>   }
> }
> {code}



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

[jira] [Created] (AMBARI-13073) Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitry Lysnichenko (JIRA)]

Dmitry Lysnichenko created AMBARI-13073:
---

 Summary: Backport Request - Ambari is overwriting ownership of 
yarn.local.dir with yarn:hadoop in Kerberized cluster
 Key: AMBARI-13073
 URL: https://issues.apache.org/jira/browse/AMBARI-13073
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.1.2
Reporter: Dmitry Lysnichenko
Assignee: Dmitry Lysnichenko
 Fix For: 2.1.2


 Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites



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

[jira] [Updated] (AMBARI-13073) Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13073:

Description: 
 Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites

Need to backport AMBARI-12935 to 2.0.maint

  was:
 Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites

Need to backport AMBARI-12935 to 2.0


> Backport Request - Ambari is overwriting ownership of yarn.local.dir with 
> yarn:hadoop in Kerberized cluster
> ---
>
> Key: AMBARI-13073
> URL: https://issues.apache.org/jira/browse/AMBARI-13073
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.2
>
> Attachments: AMBARI-13073.patch
>
>
>  Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
> Kerberized cluster when it should be owned by running user . This happens at 
> restart of a nodemanager through Ambari. Only solution was to recreate 
> yarn.local.dir at which point it makes correct ownership of files. Restart 
> via Ambari then overwrites
> Need to backport AMBARI-12935 to 2.0.maint



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

[jira] [Updated] (AMBARI-13073) Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13073:

Description: 
 Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites

Need to backport AMBARI-12935 to 2.0

  was: Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites


> Backport Request - Ambari is overwriting ownership of yarn.local.dir with 
> yarn:hadoop in Kerberized cluster
> ---
>
> Key: AMBARI-13073
> URL: https://issues.apache.org/jira/browse/AMBARI-13073
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.2
>
> Attachments: AMBARI-13073.patch
>
>
>  Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
> Kerberized cluster when it should be owned by running user . This happens at 
> restart of a nodemanager through Ambari. Only solution was to recreate 
> yarn.local.dir at which point it makes correct ownership of files. Restart 
> via Ambari then overwrites
> Need to backport AMBARI-12935 to 2.0



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

[jira] [Updated] (AMBARI-13073) Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-13073:

Attachment: AMBARI-13073.patch

> Backport Request - Ambari is overwriting ownership of yarn.local.dir with 
> yarn:hadoop in Kerberized cluster
> ---
>
> Key: AMBARI-13073
> URL: https://issues.apache.org/jira/browse/AMBARI-13073
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.1.2
>
> Attachments: AMBARI-13073.patch
>
>
>  Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
> Kerberized cluster when it should be owned by running user . This happens at 
> restart of a nodemanager through Ambari. Only solution was to recreate 
> yarn.local.dir at which point it makes correct ownership of files. Restart 
> via Ambari then overwrites
> Need to backport AMBARI-12935 to 2.0.maint



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

Review Request 38298: Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Dmitro Lisnichenko]

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

Review request for Ambari, Andrew Onischuk and Dmytro Sen.


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


Repository: ambari


Description
---

Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
Kerberized cluster when it should be owned by running user . This happens at 
restart of a nodemanager through Ambari. Only solution was to recreate 
yarn.local.dir at which point it makes correct ownership of files. Restart via 
Ambari then overwrites
Need to backport AMBARI-12935 to 2.0.maint


Diffs
-

  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params.py
 29e8dfb 
  
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py
 0736663 
  ambari-server/src/test/python/stacks/2.0.6/YARN/test_nodemanager.py 0956565 
  ambari-server/src/test/python/stacks/2.0.6/YARN/test_resourcemanager.py 
d32fc1a 

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


Testing
---

in progress


Thanks,

Dmitro Lisnichenko

[jira] [Created] (AMBARI-13074) Failure to restart HiveServer2

[Angel Villasmil (JIRA)]

Angel Villasmil created AMBARI-13074:


 Summary: Failure to restart HiveServer2
 Key: AMBARI-13074
 URL: https://issues.apache.org/jira/browse/AMBARI-13074
 Project: Ambari
  Issue Type: Bug
  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
Configs
Affects Versions: 2.0.0
 Environment: -4 Maquinas Azure A7 (1 Maestro y 3 Esclavos)
-Ubuntu 12.04 LTS
-HDP 2.2
Reporter: Angel Villasmil


I'm super rookie using hadoop, it's my first installation, excuse my bad 
English, but I need your help, Hive service does not start properly, showing 
the following error:

{code}
*strong*stderr:   /var/lib/ambari-agent/data/errors-1504.txt*strong*
2015-09-10 21:20:47,928 - Error while executing command 'restart':
Traceback (most recent call last):
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 214, in execute
method(env)
  File 
"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
 line 371, in restart
self.start(env)
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 61, in start
rolling_restart=rolling_restart )
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_service.py",
 line 101, in hive_service
raise Fail("Connection to Hive server %s on port %s failed after %d 
seconds" % (address, port, elapsed_time))
Fail: Connection to Hive server bodazhdp1.cloudapp.net on port 1 failed 
after 140 seconds{code}



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

Re: Review Request 38299: [ HADOOP-11764] NodeManager should use directory other than tmp for extracting and loading leveldbjni

[Dmitro Lisnichenko]

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

Ship it!


Ship It!

- Dmitro Lisnichenko


On Sept. 11, 2015, 2:11 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38299/
> ---
> 
> (Updated Sept. 11, 2015, 2:11 p.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: HADOOP-11764
> https://issues.apache.org/jira/browse/HADOOP-11764
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/yarn-env.xml
>  a1dfa57 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
>  70ae4b8 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-ANY/scripts/params.py
>  8abd72b 
>   
> ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-ANY/scripts/shared_initialization.py
>  bd44caf 
>   
> ambari-server/src/main/resources/stacks/HDP/2.1/services/YARN/configuration/yarn-env.xml
>  4c99823 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/services/YARN/configuration-mapred/mapred-env.xml
>  b5280ce 
>   
> ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/yarn-env.xml
>  44f3dc2 
>   
> ambari-server/src/test/python/stacks/2.0.6/hooks/before-ANY/test_before_any.py
>  39fd3d5 
> 
> Diff: https://reviews.apache.org/r/38299/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Commented] (AMBARI-12915) Make agent hostname configurable

[Jeffrey E Rodriguez (JIRA)]

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

Jeffrey E  Rodriguez commented on AMBARI-12915:
---

Hi Greg. For the record, can you are more details?
What JVM were you using when you were trying suggestion?
Not all version of JVM have fixed this issue. and the JDK workaround adding 
only apply to sun/openjdk releases that added this.
You can still check DH length using openssl are suggested.

> Make agent hostname configurable
> 
>
> Key: AMBARI-12915
> URL: https://issues.apache.org/jira/browse/AMBARI-12915
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-agent
>Affects Versions: 2.1.0
>Reporter: Greg Hill
>Assignee: Greg Hill
>Priority: Minor
> Attachments: AMBARI-12915.patch
>
>
> Currently the agent can either get the hostname from the local system, or you 
> can inject a script to tell it what hostname to use using the 
> 'hostname_script' config value.  I would like to add a 'hostname' config 
> value to the agent section of the agent config so we can just tell the agent 
> what hostname to use.
> The scenario this comes up in is that our Ambari setup uses a local DNS 
> domain for internal traffic, but the Ambari API has a public FQDN that we use 
> for the API.  It would be much cleaner for us to just specify the hostname in 
> the config rather than jumping through hoops to generate a script to use to 
> derive it.
> https://github.com/apache/ambari/blob/087d9003ecf6af33890e4f48743d7237a30d6438/ambari-agent/src/main/python/ambari_agent/hostname.py#L40



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

[jira] [Created] (AMBARI-13078) Upgrade Packs Should Define Skippable Failed Slave/Clients

[Jonathan Hurley (JIRA)]

Jonathan Hurley created AMBARI-13078:


 Summary: Upgrade Packs Should Define Skippable Failed Slave/Clients
 Key: AMBARI-13078
 URL: https://issues.apache.org/jira/browse/AMBARI-13078
 Project: Ambari
  Issue Type: Task
  Components: ambari-server
Affects Versions: 2.1.0
Reporter: Jonathan Hurley
Assignee: Jonathan Hurley
Priority: Critical
 Fix For: 2.1.2


Although the upgrade endpoint can be used to marked failures as being 
automatically skipped:

{code:title=POST api/v1/clusters/c1/upgrades}
{
  "Upgrade": {
"repository_version": "2.3.0.0-2545",
"skip_failures": true
  }
}
{code}

The upgrade packs should also allow this behavior by default:

{code}
  false
  false
{code}




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

[jira] [Created] (AMBARI-13072) 'All Datanodes' not present for HDFS in Create Widget Wizard

[Andrii Tkach (JIRA)]

Andrii Tkach created AMBARI-13072:
-

 Summary: 'All Datanodes' not present for HDFS in Create Widget 
Wizard
 Key: AMBARI-13072
 URL: https://issues.apache.org/jira/browse/AMBARI-13072
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.2
Reporter: Andrii Tkach
Assignee: Andrii Tkach
Priority: Critical
 Fix For: 2.1.2
 Attachments: Screen Shot 2015-09-10 at 10.36.07 AM.png

Please see the screenshot attached. 'All Datanodes' was present in the list for 
HDFS which is missing now. 



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

[jira] [Updated] (AMBARI-13072) 'All Datanodes' not present for HDFS in Create Widget Wizard

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-13072:
--
Attachment: Screen Shot 2015-09-10 at 10.36.07 AM.png

> 'All Datanodes' not present for HDFS in Create Widget Wizard
> 
>
> Key: AMBARI-13072
> URL: https://issues.apache.org/jira/browse/AMBARI-13072
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: Screen Shot 2015-09-10 at 10.36.07 AM.png
>
>
> Please see the screenshot attached. 'All Datanodes' was present in the list 
> for HDFS which is missing now. 



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

[jira] [Updated] (AMBARI-13072) 'All Datanodes' not present for HDFS in Create Widget Wizard

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-13072:
--
Attachment: AMBARI-13072.patch

> 'All Datanodes' not present for HDFS in Create Widget Wizard
> 
>
> Key: AMBARI-13072
> URL: https://issues.apache.org/jira/browse/AMBARI-13072
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13072.patch, Screen Shot 2015-09-10 at 10.36.07 
> AM.png
>
>
> Please see the screenshot attached. 'All Datanodes' was present in the list 
> for HDFS which is missing now. 



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

[jira] [Commented] (AMBARI-13072) 'All Datanodes' not present for HDFS in Create Widget Wizard

[Aleksandr Kovalenko (JIRA)]

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

Aleksandr Kovalenko commented on AMBARI-13072:
--

+1 for the patch

> 'All Datanodes' not present for HDFS in Create Widget Wizard
> 
>
> Key: AMBARI-13072
> URL: https://issues.apache.org/jira/browse/AMBARI-13072
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13072.patch, Screen Shot 2015-09-10 at 10.36.07 
> AM.png
>
>
> Please see the screenshot attached. 'All Datanodes' was present in the list 
> for HDFS which is missing now. 



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

[jira] [Commented] (AMBARI-13072) 'All Datanodes' not present for HDFS in Create Widget Wizard

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-13072:
---

  6748 tests complete (12 seconds)
  94 tests pending


> 'All Datanodes' not present for HDFS in Create Widget Wizard
> 
>
> Key: AMBARI-13072
> URL: https://issues.apache.org/jira/browse/AMBARI-13072
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.1.2
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
>Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13072.patch, Screen Shot 2015-09-10 at 10.36.07 
> AM.png
>
>
> Please see the screenshot attached. 'All Datanodes' was present in the list 
> for HDFS which is missing now. 



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

[jira] [Updated] (AMBARI-13052) Stop-and-Start Upgrade: HDP 2.1->2.3 needs to stop services using 2.1, and start using 2.3

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-13052:
-
Summary: Stop-and-Start Upgrade: HDP 2.1->2.3 needs to stop services using 
2.1, and start using 2.3  (was: Stop-and-Start Upgrade: HDP 2.1->2.3 needs to 
stop services using 2.1, and start using 2.3.)

> Stop-and-Start Upgrade: HDP 2.1->2.3 needs to stop services using 2.1, and 
> start using 2.3
> --
>
> Key: AMBARI-13052
> URL: https://issues.apache.org/jira/browse/AMBARI-13052
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Alejandro Fernandez
>Assignee: Alejandro Fernandez
> Fix For: 2.2.0
>
>
> For a Stop-and-Start Upgrade from HDP 2.1 -> 2.3, we need to stop all 
> services using the scripts for HDP 2.1, and then start them using HDP 2.3.
> Today, during an Upgrade, we currently set the desired stack id when we 
> process Upgrade Pack and insert the upgrade record. That means that all 
> start/stop commands use the scripts from the desired stack.
> Instead, we need a Server Side Action to be called right before we run 
> "hdp-select set all" that will change the desired stack id to the new 
> version; this will permit stopping on the old version, and starting on the 
> new version.
> When we downgrade, we commence the orchestration again, and we again call the 
> Server Side Action to change the desired stack id, this time to the starting 
> version.



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

[jira] [Updated] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly updated AMBARI-13069:

Attachment: AMBARI-13069_4.patch

> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
> Attachments: AMBARI-13069.patch, AMBARI-13069_2.patch, 
> AMBARI-13069_3.patch, AMBARI-13069_4.patch
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 
> # Config property only in a specific stack can be attributed without writing 
> stack specific logic in ambari-web



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

Re: Review Request 38303: Attributes of configuration property should be stack API driven

[Yusaku Sako]

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

Ship it!


Ship It!

- Yusaku Sako


On Sept. 12, 2015, 1 a.m., Jaimin Jetly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38303/
> ---
> 
> (Updated Sept. 12, 2015, 1 a.m.)
> 
> 
> Review request for Ambari, Srimanth Gunturi and Yusaku Sako.
> 
> 
> Bugs: AMBARI-13069
> https://issues.apache.org/jira/browse/AMBARI-13069
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property exposed from API as visible value 
> attribute
> # display name of configuration property exposed from API as display_name 
> # Empty value validity of configuration property exposed from API as 
> empty_value_valid value attribute
> # Restriction of being configured only once on installation exposed from API 
> as editable_only_at_install value attribute
> # overridable in config host group exposed from aPI as overridable vlaue 
> attribute
> # Name of the property should be hidden exposed from API as 
> show_property_name value attribute
> 
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code.
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackLevelConfigurationResourceProvider.java
>  0525488 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ValueAttributesInfo.java
>  8054c54 
>   
> ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-env.xml
>  67da50e 
>   
> ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-log4j.xml
>  e8f6e56 
>   
> ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-site.xml
>  2a7e083 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-env.xml
>  e84193c 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-log4j.xml
>  64cc9d3 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-security-site.xml
>  6f60736 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-log4j.xml
>  6d3703e 
>   
> ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml
>  5c7a39b 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml
>  75178d2 
>   
> ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-startup.properties.xml
>  451ebb5 
>   
> ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-conf.xml
>  8ff764b 
>   
> ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-env.xml
>  e150478 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-env.xml
>  03db5df 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-log4j.xml
>  64cc9d3 
>   
> ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-site.xml
>  b224bef 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
>  4cb2274 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-log4j.xml
>  08822eb 
>   
> ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
>  dc7f661 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-env.xml
>  2d0a182 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-exec-log4j.xml
>  fb852f7 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-log4j.xml
>  a978ef7 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
>  2783b78 
>   
> ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-log4j.xml
>  0ded4d4 
>   
> 

[jira] [Resolved] (AMBARI-12774) Stack deployment should not assume the availability of hdfs-site

[Vijay Srinivasaraghavan (JIRA)]

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

Vijay Srinivasaraghavan resolved AMBARI-12774.
--
   Resolution: Fixed
Fix Version/s: trunk

Addressed in AMBARI-12837

> Stack deployment should not assume the availability of hdfs-site
> 
>
> Key: AMBARI-12774
> URL: https://issues.apache.org/jira/browse/AMBARI-12774
> Project: Ambari
>  Issue Type: Bug
>Reporter: Vijay Srinivasaraghavan
>Assignee: Vijay Srinivasaraghavan
> Fix For: trunk
>
>
> While deploying a stack, when the default FS (HDFS) is replaced by an 
> alternate HCFS then it is possible to not have hdfs-site for the cluster. The 
> stack deployment code for services other than HDFS should not assume the 
> availability of hdfs-site as the UI will also not have the means to let user 
> specify one.



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

[jira] [Commented] (AMBARI-13070) HDP-specific list of packages should be removed from common-services

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13070:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3430 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3430/])
AMBARI-13070: HDP-specific list of packages should be removed from 
common-services (jluniya) (jluniya: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e8f2f2fd767bab5fff67c163d672ee7fdf2d5054)
* ambari-common/src/main/python/pluggable_stack_definition/configs/SAPHD.json
* ambari-server/src/main/resources/common-services/SPARK/1.3.1.2.3/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/services/SPARK/metainfo.xml
* 
ambari-server/src/main/resources/common-services/SLIDER/0.60.0.2.2/metainfo.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER_KMS/metainfo.xml
* ambari-metrics/ambari-metrics-storm-sink/pom.xml
* ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/metainfo.xml
* 
ambari-common/src/main/python/pluggable_stack_definition/resources/PHD/custom_stack_map.js
* ambari-server/src/main/resources/stacks/HDP/2.2/services/SLIDER/metainfo.xml
* ambari-server/src/main/resources/common-services/RANGER/0.4.0/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/KAFKA/metainfo.xml
* ambari-server/src/main/resources/common-services/OOZIE/4.2.0.2.3/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.3/services/OOZIE/metainfo.xml
* 
ambari-server/src/main/resources/common-services/RANGER_KMS/0.5.0.2.3/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/RANGER/metainfo.xml
* ambari-server/src/main/resources/common-services/SPARK/1.2.0.2.2/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/KNOX/metainfo.xml
* ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/metainfo.xml
* ambari-server/src/main/resources/stacks/HDP/2.2/services/SPARK/metainfo.xml


> HDP-specific list of packages should be removed from common-services
> 
>
> Key: AMBARI-13070
> URL: https://issues.apache.org/jira/browse/AMBARI-13070
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.1.2
>
>
> In common-services/RANGER_KMS/0.5.0.2.3/metainfo.xml we specify the list of 
> hdp packages. We should not have this list specific in common-services. We 
> should move the list to stacks/HDP
> {noformat}
>   
> 
>   redhat7,redhat6,suse11
>   
> 
>   ranger_2_3_*-kms
>
>   
> 
> 
>   debian7,ubuntu12,ubuntu14
>   
> 
>   ranger-2-3-.*-kms
>
>   
> 
>   
> {noformat}
> These cause issues in pluggable stacks. 



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

[jira] [Commented] (AMBARI-13007) Stopping ambari-server may kill ambari-agent running on the same machine in some cases

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13007:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3430 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3430/])
AMBARI-13007: Stopping ambari-server may kill ambari-agent running on the same 
machine in some cases (Nahappan Somasundaram via jluniya) (jluniya: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=02fcea6c3c38f2fff4e73bdc3d235cf87477d4e2)
* ambari-server/src/main/python/ambari_server_main.py


> Stopping ambari-server may kill ambari-agent running on the same machine in 
> some cases
> --
>
> Key: AMBARI-13007
> URL: https://issues.apache.org/jira/browse/AMBARI-13007
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
> Fix For: 2.2.0
>
>
> Launch multinode Ambari clusters using a simple python script. It logs in to 
> every node via ssh and runs a shell script:
> {code}
> #!/usr/bin/env bash
> while [[ $# > 0 ]]
> do
>   key="$1"
>   case ${key} in
>   --server)
> ASERVER="$2"# Server hostname
> shift # past argument
>   ;;
>   --noserver)
> NOSERVER="NOSERVER"  # Don't install/start server
>   ;;
>   *)
> echo unknown option
> exit 1
>   ;;
>   esac
>   shift # past argument or value
> done
> yum clean all
> curl 
> http://s3.amazonaws.com/dev.hortonworks.com/ambari/centos6/2.x/latest/trunk/ambaribn.repo
>  > /etc/yum.repos.d/ambari.repo
> # server
> if [ "${ASERVER}" = $(hostname -f) ] && [ -z "${NOSERVER}" ] ; then
>   yum install sudo postgresql-server wget -y
>   rpm -i /tmp/rpms/ambari-server*.rpm
>   # Disable iptables
>   iptables -F
>   ambari-server setup -s
>   # Enable remote debug
>   sed -rie 's/-server -XX:NewRatio/-server 
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 
> -XX:NewRatio/g'  /usr/sbin/ambari_server_main.py
>   ## Sleep until debugger connects
>   # sed -rie 
> 's/dt_socket,server=y,suspend=.,address=5005/dt_socket,server=y,suspend=y,address=5005/g'
>  /usr/sbin/ambari-server.py
>   # Fix an issue with UI client version
>   gunzip /usr/lib/ambari-server/web/javascripts/app.js.gz
>   amb=$(ambari-server --version); sed -i "s/App\.version = '';/App.version = 
> '$amb';/" /usr/lib/ambari-server/web/javascripts/app.js
>   gzip /usr/lib/ambari-server/web/javascripts/app.js
>   # Increase task timeout
>   sed -ri 
> 's/agent.package.install.task.timeout=1800/agent.package.install.task.timeout=3600/g'
>  /etc/ambari-server/conf/ambari.properties
>   find /var/lib/ambari-server/resources/ -name metainfo.xml | xargs -L 1 sed 
> -ri 's/[[:digit:]]+[[:digit:]]*<\//1800<\//g'
>   # Start the server
>   ambari-server start -v || exit 1
> fi
> # Agent
> iptables -F
> yum clean all
> yum install -y wget
> rpm -i /tmp/rpms/ambari-agent*.rpm
> # Replace server hostname
> sed -rie "s/hostname=localhost/hostname=$ASERVER/g" 
> /etc/ambari-agent/conf/ambari-agent.ini
> # Enable debug mode at agent
> # sed -rie 's/=INFO/=DEBUG/g' /etc/ambari-agent/conf/ambari-agent.ini
> ambari-agent start || exit 1
> {code}
> When I restart ambari-server, agent running on the same node is killed with 
> 100% probability. That is because it is launched in the same process group 
> with ambari-server, and ambari-server kills everything that belongs to it's 
> process group. I assume that this situation is common for launching 
> ambari-server and ambari-agent from the same shell script via ssh, or maybe 
> also via configuration management tools like puppet/chef/etc. (did not check 
> this assumption).
> *More info:*
> {code}
> [root@dlysnichenko-ru3-1 ~]# ps -ejH
>   PID  PGID   SID TTY  TIME CMD
>  1584  1584  1584 ?00:00:00   sshd
>  2659  2659  2659 ?00:00:00 sshd
>  2662  2662  2662 pts/000:00:00   bash
>  3268  3268  2662 pts/000:00:00 ps
>  2056  2041  2041 ?00:00:00   postmaster
>  2058  2058  2058 ?00:00:00 postmaster
>  2060  2060  2060 ?00:00:00 postmaster
>  2061  2061  2061 ?00:00:00 postmaster
>  2062  2062  2062 ?00:00:00 postmaster
>  2063  2063  2063 ?00:00:00 postmaster
>  2380  2380  2380 ?00:00:00 postmaster
>  2397  2397  2397 ?00:00:00 postmaster
>  2649  2649  2649 ?00:00:01 postmaster
>  2654  2654  2654 ?00:00:00 postmaster
>  2655  2655  2655 ?00:00:00 postmaster
>  2656  2656  2656 ?00:00:00 postmaster
>  2360  1644  1644 ?00:00:59   java
>  2507  1644  1644 ?

[jira] [Commented] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Jaimin D Jetly (JIRA)]

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

Jaimin D Jetly commented on AMBARI-13069:
-

Attached [^AMBARI-13069_4.patch] with additional fixes.

> Attributes of configuration property should be stack API driven
> ---
>
> Key: AMBARI-13069
> URL: https://issues.apache.org/jira/browse/AMBARI-13069
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, ambari-web, stacks
>Affects Versions: 2.2.0
>Reporter: Jaimin D Jetly
>Assignee: Jaimin D Jetly
> Fix For: 2.2.0
>
> Attachments: AMBARI-13069.patch, AMBARI-13069_2.patch, 
> AMBARI-13069_3.patch, AMBARI-13069_4.patch
>
>
> *Following attributes of configuration properties should be made stack API 
> driven:*
> # Visibility of configuration property
> # display name of configuration property
> # Empty value validity of configuration property
> # Restriction of being configured only once on installation
> # overridable in config host group
> # Name of the property should be hidden
> *Achieving this task will be useful in following scenarios:*
> # custom services could be added with less changes in ambari-web code
> # Any issues related to configuration property attributes encountered on a 
> deployed cluster can be addressed by making stack changes rather than 
> redeploying ambari-web code with a fix. For example if a property tagged as 
> not overridable if later desired to be made overridable on a deployed cluster 
> will now require changing a boolean flag in stack configuration property 
> rather than changing ambari-web code. 
> # Config property only in a specific stack can be attributed without writing 
> stack specific logic in ambari-web



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

[jira] [Commented] (AMBARI-13060) Kerberos: Allow user to specify additional realms for auth-to-local rules

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-13060:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12755490/AMBARI-13060_trunk_01.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 4 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-server.

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

This message is automatically generated.

> Kerberos: Allow user to specify additional realms for auth-to-local rules
> -
>
> Key: AMBARI-13060
> URL: https://issues.apache.org/jira/browse/AMBARI-13060
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>  Labels: kerberos, kerberos-wizard
> Fix For: 2.1.2
>
> Attachments: AMBARI-13060_branch-2.1_01.patch, 
> AMBARI-13060_trunk_01.patch
>
>
> Allow user to specify additional realms for auth-to-local rules. This will 
> add _default_ rules for the specified realm(s) to the generated auth-to-local 
> rule sets. For example:
> {noformat}
> RULE:[1:$1@$0](.*@USER_REALM.COM)s/@.*//
> {noformat}
> The value should be a (comma) delimited list of realm names set in set of 
> global properties in the Kerberos Descriptor.



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

[jira] [Commented] (AMBARI-12837) Server component should read HCFS type info from stack and propagate it in dictionary for agent and UI to consume

[Hudson (JIRA)]

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

Hudson commented on AMBARI-12837:
-

FAILURE: Integrated in Ambari-trunk-Commit #3431 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3431/])
AMBARI-12837. Propogate service type information to dictionary (Vijay 
Srinivasaraghavan via smohanty) (smohanty: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=93a2106a6edb8ae26dc30a0b277ec0de586b8d05)
* ambari-web/app/data/HDP2/site_properties.js
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-START/scripts/shared_initialization.py
* ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_service_check.py
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
* ambari-server/src/test/python/stacks/2.3/MAHOUT/test_mahout_service_check.py
* ambari-server/src/test/python/stacks/2.1/TEZ/test_service_check.py
* 
ambari-server/src/main/resources/common-services/SPARK/1.2.0.2.2/package/scripts/params.py
* 
ambari-server/src/main/resources/common-services/TEZ/0.4.0.2.1/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-ANY/scripts/hook.py
* ambari-server/src/test/python/stacks/2.0.6/HDFS/test_namenode.py
* 
ambari-server/src/test/python/stacks/2.0.6/AMBARI_METRICS/test_metrics_collector.py
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/params_linux.py
* ambari-server/src/test/python/stacks/2.0.6/HDFS/test_service_check.py
* 
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/package/scripts/hbase.py
* ambari-server/src/test/python/stacks/2.0.6/YARN/test_historyserver.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-START/scripts/params.py
* 
ambari-server/src/test/python/stacks/2.0.6/YARN/test_mapreduce2_service_check.py
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/after-INSTALL/scripts/shared_initialization.py
* 
contrib/fast-hdfs-resource/src/main/java/org/apache/ambari/fast_hdfs_resource/Runner.java
* 
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/params_linux.py
* 
ambari-common/src/main/python/resource_management/libraries/resources/hdfs_resource.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-ANY/scripts/params.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/before-ANY/scripts/shared_initialization.py
* ambari-server/src/test/python/stacks/2.0.6/HIVE/test_hive_service_check.py
* ambari-server/src/test/python/stacks/2.2/SPARK/test_job_history_server.py
* 
ambari-server/src/main/resources/common-services/PIG/0.12.0.2.0/package/scripts/params_linux.py
* ambari-server/src/test/python/stacks/2.0.6/HBASE/test_hbase_master.py
* 
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/params_linux.py
* 
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params_linux.py
* ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py
* ambari-server/src/test/python/stacks/2.1/FALCON/test_falcon_server.py
* 
ambari-server/src/main/resources/common-services/MAHOUT/1.0.0.2.3/package/scripts/params.py
* 
ambari-common/src/main/python/resource_management/libraries/providers/hdfs_resource.py
* 
ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariCustomCommandExecutionHelper.java
* ambari-server/src/test/python/stacks/2.0.6/HIVE/test_hive_server.py
* ambari-server/src/test/python/stacks/2.2/PIG/test_pig_service_check.py
* 
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/mapred_service_check.py
* ambari-server/src/test/python/stacks/2.0.6/PIG/test_pig_service_check.py
* 
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/package/scripts/params.py
* 
ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks/after-INSTALL/scripts/params.py


> Server component should read HCFS type info from stack and propagate it in 
> dictionary for agent and UI to consume
> -
>
> Key: AMBARI-12837
> URL: https://issues.apache.org/jira/browse/AMBARI-12837
> Project: Ambari
>  Issue Type: Task
>Affects Versions: trunk
>Reporter: Vijay Srinivasaraghavan
>Assignee: Vijay Srinivasaraghavan
> Attachments: AMBARI-12837.patch
>
>
> UI and agent code is using namenode configuration as a validation to check if 

[jira] [Commented] (AMBARI-13069) Attributes of configuration property should be stack API driven

[Hudson (JIRA)]

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

Hudson commented on AMBARI-13069:
-

SUCCESS: Integrated in Ambari-trunk-Commit #3432 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/3432/])
AMBARI-13069. Attributes of configuration property should be stack API driven. 
(jaimin) (jaimin: 
http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=70ca85005b49a93970164af9a047bebd2b290427)
* 
ambari-server/src/main/resources/common-services/RANGER/0.4.0/configuration/usersync-properties.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.3/services/TEZ/configuration/tez-site.xml
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/topology.xml
* 
ambari-server/src/main/resources/common-services/SPARK/1.2.0.2.2/configuration/spark-log4j-properties.xml
* 
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/YARN/configuration/ranger-yarn-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-log4j.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.3/services/OOZIE/configuration/oozie-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/core-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.1/services/YARN/configuration/yarn-env.xml
* 
ambari-server/src/main/java/org/apache/ambari/server/state/ValueAttributesInfo.java
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.1/services/FLUME/configuration/flume-conf.xml
* 
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-conf.xml
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/gateway-log4j.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.2/services/HBASE/configuration/hbase-env.xml
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/TEZ/configuration/tez-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-env.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HDFS/configuration/hadoop-env.xml
* ambari-web/app/data/HDP2.3/site_properties.js
* 
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-exec-log4j.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3.GlusterFS/services/OOZIE/configuration/oozie-site.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.3/services/HDFS/configuration/hdfs-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/STORM/configuration/ranger-storm-audit.xml
* 
ambari-server/src/main/resources/common-services/KNOX/0.5.0.2.2/configuration/users-ldif.xml
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.1/services/OOZIE/configuration/oozie-site.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.3/services/STORM/configuration/storm-site.xml
* 
ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/configuration/oozie-log4j.xml
* ambari-web/app/data/HDP2/site_properties.js
* 
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration/yarn-log4j.xml
* ambari-web/test/data/HDP2.2/site_properties_test.js
* ambari-web/app/assets/test/tests.js
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/configuration/ranger-admin-site.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.2/services/HBASE/configuration/hbase-env.xml
* 
ambari-server/src/main/resources/common-services/SLIDER/0.60.0.2.2/configuration/slider-log4j.xml
* 
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-log4j.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HDFS/configuration/hadoop-env.xml
* 
ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/configuration/krb5-conf.xml
* 
ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/configuration-mapred/mapred-env.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/HBASE/configuration/ranger-hbase-audit.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/KAFKA/configuration/ranger-kafka-plugin-properties.xml
* 
ambari-server/src/main/resources/stacks/HDPWIN/2.1/services/OOZIE/configuration/oozie-env.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/RANGER/configuration/ranger-env.xml
* 
ambari-server/src/main/resources/stacks/HDP/2.3/services/ACCUMULO/configuration/accumulo-log4j.xml
* ambari-web/test/data/HDP2.3/site_properties_test.js
* 

Re: Review Request 38303: Attributes of configuration property should be stack API driven

[Jaimin Jetly]

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

(Updated Sept. 12, 2015, 1 a.m.)


Review request for Ambari, Srimanth Gunturi and Yusaku Sako.


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


Repository: ambari


Description
---

*Following attributes of configuration properties should be made stack API 
driven:*
# Visibility of configuration property exposed from API as visible value 
attribute
# display name of configuration property exposed from API as display_name 
# Empty value validity of configuration property exposed from API as 
empty_value_valid value attribute
# Restriction of being configured only once on installation exposed from API as 
editable_only_at_install value attribute
# overridable in config host group exposed from aPI as overridable vlaue 
attribute
# Name of the property should be hidden exposed from API as show_property_name 
value attribute

*Achieving this task will be useful in following scenarios:*
# custom services could be added with less changes in ambari-web code
# Any issues related to configuration property attributes encountered on a 
deployed cluster can be addressed by making stack changes rather than 
redeploying ambari-web code with a fix. For example if a property tagged as not 
overridable if later desired to be made overridable on a deployed cluster will 
now require changing a boolean flag in stack configuration property rather than 
changing ambari-web code.


Diffs (updated)
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StackLevelConfigurationResourceProvider.java
 0525488 
  
ambari-server/src/main/java/org/apache/ambari/server/state/ValueAttributesInfo.java
 8054c54 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-env.xml
 67da50e 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-log4j.xml
 e8f6e56 
  
ambari-server/src/main/resources/common-services/ACCUMULO/1.6.1.2.2.0/configuration/accumulo-site.xml
 2a7e083 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-env.xml
 e84193c 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-log4j.xml
 64cc9d3 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-hbase-security-site.xml
 6f60736 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-log4j.xml
 6d3703e 
  
ambari-server/src/main/resources/common-services/AMBARI_METRICS/0.1.0/configuration/ams-site.xml
 5c7a39b 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-env.xml
 75178d2 
  
ambari-server/src/main/resources/common-services/FALCON/0.5.0.2.1/configuration/falcon-startup.properties.xml
 451ebb5 
  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-conf.xml
 8ff764b 
  
ambari-server/src/main/resources/common-services/FLUME/1.4.0.2.0/configuration/flume-env.xml
 e150478 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-env.xml
 03db5df 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-log4j.xml
 64cc9d3 
  
ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/configuration/hbase-site.xml
 b224bef 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-env.xml
 4cb2274 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-log4j.xml
 08822eb 
  
ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hdfs-site.xml
 dc7f661 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-env.xml
 2d0a182 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-exec-log4j.xml
 fb852f7 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-log4j.xml
 a978ef7 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/hive-site.xml
 2783b78 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-log4j.xml
 0ded4d4 
  
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/configuration/webhcat-site.xml
 33f7f21 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/configuration/kafka-env.xml
 94f4975 
  
ambari-server/src/main/resources/common-services/KAFKA/0.8.1.2.2/configuration/kafka-log4j.xml
 901859e 
  
ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/configuration/kerberos-env.xml
 60df2e0 
  
ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/configuration/krb5-conf.xml
 5cf0960 
  

[jira] [Resolved] (AMBARI-12851) The definition and hadling of hadoop-env should not be restrictive to HDFS

[Vijay Srinivasaraghavan (JIRA)]

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

Vijay Srinivasaraghavan resolved AMBARI-12851.
--
   Resolution: Fixed
Fix Version/s: trunk

Addressed in AMBARI-12837

> The definition and hadling of hadoop-env should not be restrictive to HDFS
> --
>
> Key: AMBARI-12851
> URL: https://issues.apache.org/jira/browse/AMBARI-12851
> Project: Ambari
>  Issue Type: Bug
>Reporter: Vijay Srinivasaraghavan
>Assignee: Sumit Mohanty
> Fix For: trunk
>
>
> Hadoop Env configuration defined at the stack level is managed only if HDFS  
> service is slected as part of the deployment. If HDFS is disabled and any 
> alternate FS includes hadoop-env in the stack, the configuration should be 
> understood by the Ambari code and corresponding hadoop-env.sh should be 
> created properly on the hadoop/ambari agent machines.



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

[jira] [Updated] (AMBARI-13074) Failure to restart HiveServer2

[Angel Villasmil (JIRA)]

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

Angel Villasmil updated AMBARI-13074:
-
Remaining Estimate: 12h  (was: 1h)
 Original Estimate: 12h  (was: 1h)

> Failure to restart HiveServer2
> --
>
> Key: AMBARI-13074
> URL: https://issues.apache.org/jira/browse/AMBARI-13074
> Project: Ambari
>  Issue Type: Bug
>  Components:  HiveServer2, Metastore, and Client Heap Sizes to Smart 
> Configs
>Affects Versions: 2.0.0
> Environment: - 4 Machines Azure A7 (1 Master and 3 slaves)
> - Ubuntu 12.04 LTS
> - HDP 2.2
>Reporter: Angel Villasmil
>  Labels: ambari, azure, hive, hortonworks, newbie, ubuntu
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> I'm super rookie using hadoop, it's my first installation, excuse my bad 
> English, but I need your help, Hive service does not start properly, showing 
> the following error:
> {code}
> *strong*stderr:   /var/lib/ambari-agent/data/errors-1504.txt*strong*
> 2015-09-10 21:20:47,928 - Error while executing command 'restart':
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 214, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 371, in restart
> self.start(env)
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
>  line 61, in start
> rolling_restart=rolling_restart )
>   File 
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_service.py",
>  line 101, in hive_service
> raise Fail("Connection to Hive server %s on port %s failed after %d 
> seconds" % (address, port, elapsed_time))
> Fail: Connection to Hive server bodazhdp1.cloudapp.net on port 1 failed 
> after 140 seconds{code}



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

[jira] [Commented] (AMBARI-12393) Ambari Server is vulnerable to logjam

[Greg Hill (JIRA)]

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

Greg Hill commented on AMBARI-12393:


We have the same issue and the above suggestion did not fix it.  Chrome and 
Firefox are both now blocking access by default with no option to bypass.

> Ambari Server is vulnerable to logjam
> -
>
> Key: AMBARI-12393
> URL: https://issues.apache.org/jira/browse/AMBARI-12393
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
> Environment: Red Hat Enterprise Linux Server release 6.6 
>Reporter: Jeffrey E  Rodriguez
>Priority: Critical
> Fix For: 2.1.2
>
>
> All Ambari servers running in Jetty server as well as the Ambari server 
> itself are vulnerable to LogJam  see details.
> https://weakdh.org/
> Test setting up Ambari SSL.
> 1. create certificate 
> openssl genrsa -out $wserver.key 2048 
>  openssl req -new -key $wserver.key -out $wserver.csr  
>   openssl x509 -req -days 365 -in $wserver.csr -signkey $wserver.key -out 
> $wserver.crt
> where #wscver is hostname of ambari server.
> 2. run ambari-server setup-security
> 3. Run openssl to check DH key lenght
> penssl s_client -connect bdvs1390.svl.ibm.com:8444 -cipher "EDH" | grep 
> "Server Temp Key"
> depth=0 C = US, ST = CA, L = San Jose, O = IBM, OU = BI, CN = sever.com, 
> emailAddress = test
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = US, ST = CA, L = San Jose, O = IBM, OU = BI, CN = server.com, 
> emailAddress = test
> verify return:1
> Server Temp Key: DH, 1024 bits
> Furthermore, some versions of Firefox would reject the certificate so Ambari 
> server would not be accessible from browser.
> Jira https://issues.apache.org/jira/browse/KNOX-566 has already been open for 
> Knox.



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

Review Request 38301: Make ambari-server robust/debuggable if user accidentally adds a config type to a config groups when it does not exist as base type

[Andrew Onischuk]

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

Review request for Ambari and Dmitro Lisnichenko.


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


Repository: ambari


Description
---

This was reported by a customer. Customer accidentally added a config of type
`hivesite` to a config group.

**Call**



curl 'http://ambhost:8080/api/v1/clusters/TSGHDP/config_groups/3' -X PUT -H 
"X-Requested-By: ambari" --user admin:admin --data 
'[{"ConfigGroup":{"id":3,"cluster_name":"HDP","group_name":"Hive_custom_group","tag":"HIVE","description":"","hosts":[{"host_name":"abc.local"}],"service_config_version_note":"hive
 custom group tx timeout 
property 
change","desired_configs":[{"type":"hivesite","tag":"newversionforjdbcurl","properties":{"hive.txn.timeout":"310","javax.jdo.option.ConnectionURL":"jdbc:mysql://abc.local/hive2?createDatabaseIfNotExist=true"}}]}}]'
 --compressed


This resulted in ambari-server failing to process agent heartbeat and throwing
NPE.




13 Aug 2015 10:36:28,961  WARN [ambari-hearbeat-monitor] 
HeartbeatMonitor:129 - Exception received
java.lang.NullPointerException
at 
org.apache.ambari.server.state.host.HostImpl.getDesiredHostConfigs(HostImpl.java:1349)
at 
org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:109)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.createStatusCommand(HeartbeatMonitor.java:253)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.generateStatusCommands(HeartbeatMonitor.java:218)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.doWork(HeartbeatMonitor.java:190)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.run(HeartbeatMonitor.java:121)
at java.lang.Thread.run(Thread.java:745)


Diffs
-

  
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProvider.java
 30bcc86 
  ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java 
916bc49 
  
ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
 4fe24e9 
  ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java 
e20cd25 
  
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProviderTest.java
 753daec 

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


Testing
---

mvn clean test


Thanks,

Andrew Onischuk

Re: Review Request 38298: Backport Request - Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in Kerberized cluster

[Andrew Onischuk]

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

Ship it!


Ship It!

- Andrew Onischuk


On Sept. 11, 2015, 2:14 p.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38298/
> ---
> 
> (Updated Sept. 11, 2015, 2:14 p.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk and Dmytro Sen.
> 
> 
> Bugs: AMBARI-13073
> https://issues.apache.org/jira/browse/AMBARI-13073
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Ambari is overwriting ownership of yarn.local.dir with yarn:hadoop in 
> Kerberized cluster when it should be owned by running user . This happens at 
> restart of a nodemanager through Ambari. Only solution was to recreate 
> yarn.local.dir at which point it makes correct ownership of files. Restart 
> via Ambari then overwrites
> Need to backport AMBARI-12935 to 2.0.maint
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/params.py
>  29e8dfb 
>   
> ambari-server/src/main/resources/common-services/YARN/2.1.0.2.0/package/scripts/yarn.py
>  0736663 
>   ambari-server/src/test/python/stacks/2.0.6/YARN/test_nodemanager.py 0956565 
>   ambari-server/src/test/python/stacks/2.0.6/YARN/test_resourcemanager.py 
> d32fc1a 
> 
> Diff: https://reviews.apache.org/r/38298/diff/
> 
> 
> Testing
> ---
> 
> in progress
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

Re: Review Request 38220: [Preview] Stop-and-Start Upgrade: apply configs after all services have been stopped

[Jonathan Hurley]

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


Why is this change needed for stop-the-world? You've already stopped the hive 
server and prevented clients from draining. You should not need to adjust the 
ports like we do for normal rolling upgrades.

- Jonathan Hurley


On Sept. 9, 2015, 10:52 a.m., Dmitro Lisnichenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38220/
> ---
> 
> (Updated Sept. 9, 2015, 10:52 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Dmytro Grinenko, Jonathan 
> Hurley, and Nate Cole.
> 
> 
> Bugs: AMBARI-13048
> https://issues.apache.org/jira/browse/AMBARI-13048
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> Goal:
> for STW Upgrade, we'll need to apply configs after all services have been 
> stopped, and before calling hdp-select set all.
> 
> I think, we have to add separate groups before and after restart of HIVE 
> server to enforce config application order during UPGRADE and DONGRADE. Looks 
> like that is the only config change required for 2.2->2.2+ upgrade. Does such 
> upgrade pack definition look good?
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/resources/stacks/HDP/2.2/upgrades/nonrolling-upgrade-2.2.xml
>  01022b8 
> 
> Diff: https://reviews.apache.org/r/38220/diff/
> 
> 
> Testing
> ---
> 
> Preview
> 
> 
> Thanks,
> 
> Dmitro Lisnichenko
> 
>

[jira] [Created] (AMBARI-13075) Make ambari-server robust/debuggable if user accidentally adds a config type to a config groups when it does not exist as base type

[Andrew Onischuk (JIRA)]

Andrew Onischuk created AMBARI-13075:


 Summary: Make ambari-server robust/debuggable if user accidentally 
adds a config type to a config groups when it does not exist as base type
 Key: AMBARI-13075
 URL: https://issues.apache.org/jira/browse/AMBARI-13075
 Project: Ambari
  Issue Type: Bug
Reporter: Andrew Onischuk
Assignee: Andrew Onischuk
 Fix For: 2.1.2


This was reported by a customer. Customer accidentally added a config of type
`hivesite` to a config group.

**Call**



curl 'http://ambhost:8080/api/v1/clusters/TSGHDP/config_groups/3' -X PUT -H 
"X-Requested-By: ambari" --user admin:admin --data 
'[{"ConfigGroup":{"id":3,"cluster_name":"HDP","group_name":"Hive_custom_group","tag":"HIVE","description":"","hosts":[{"host_name":"abc.local"}],"service_config_version_note":"hive
 custom group tx timeout 
property 
change","desired_configs":[{"type":"hivesite","tag":"newversionforjdbcurl","properties":{"hive.txn.timeout":"310","javax.jdo.option.ConnectionURL":"jdbc:mysql://abc.local/hive2?createDatabaseIfNotExist=true"}}]}}]'
 --compressed


This resulted in ambari-server failing to process agent heartbeat and throwing
NPE.




13 Aug 2015 10:36:28,961  WARN [ambari-hearbeat-monitor] 
HeartbeatMonitor:129 - Exception received
java.lang.NullPointerException
at 
org.apache.ambari.server.state.host.HostImpl.getDesiredHostConfigs(HostImpl.java:1349)
at 
org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:109)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.createStatusCommand(HeartbeatMonitor.java:253)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.generateStatusCommands(HeartbeatMonitor.java:218)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.doWork(HeartbeatMonitor.java:190)
at 
org.apache.ambari.server.agent.HeartbeatMonitor.run(HeartbeatMonitor.java:121)
at java.lang.Thread.run(Thread.java:745)






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

Re: Review Request 38301: Make ambari-server robust/debuggable if user accidentally adds a config type to a config groups when it does not exist as base type

[Dmitro Lisnichenko]

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

Ship it!


Ship It!

- Dmitro Lisnichenko


On Sept. 11, 2015, 2:24 p.m., Andrew Onischuk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38301/
> ---
> 
> (Updated Sept. 11, 2015, 2:24 p.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-13075
> https://issues.apache.org/jira/browse/AMBARI-13075
> 
> 
> Repository: ambari
> 
> 
> Description
> ---
> 
> This was reported by a customer. Customer accidentally added a config of type
> `hivesite` to a config group.
> 
> **Call**
> 
> 
> 
> curl 'http://ambhost:8080/api/v1/clusters/TSGHDP/config_groups/3' -X PUT 
> -H "X-Requested-By: ambari" --user admin:admin --data 
> '[{"ConfigGroup":{"id":3,"cluster_name":"HDP","group_name":"Hive_custom_group","tag":"HIVE","description":"","hosts":[{"host_name":"abc.local"}],"service_config_version_note":"hive
>  custom group tx timeout 
> property 
> change","desired_configs":[{"type":"hivesite","tag":"newversionforjdbcurl","properties":{"hive.txn.timeout":"310","javax.jdo.option.ConnectionURL":"jdbc:mysql://abc.local/hive2?createDatabaseIfNotExist=true"}}]}}]'
>  --compressed
> 
> 
> This resulted in ambari-server failing to process agent heartbeat and throwing
> NPE.
> 
> 
> 
> 
> 13 Aug 2015 10:36:28,961  WARN [ambari-hearbeat-monitor] 
> HeartbeatMonitor:129 - Exception received
> java.lang.NullPointerException
>   at 
> org.apache.ambari.server.state.host.HostImpl.getDesiredHostConfigs(HostImpl.java:1349)
>   at 
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:109)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.createStatusCommand(HeartbeatMonitor.java:253)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.generateStatusCommands(HeartbeatMonitor.java:218)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.doWork(HeartbeatMonitor.java:190)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.run(HeartbeatMonitor.java:121)
>   at java.lang.Thread.run(Thread.java:745)
> 
> 
> Diffs
> -
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProvider.java
>  30bcc86 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java 
> 916bc49 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  4fe24e9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/host/HostImpl.java 
> e20cd25 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ConfigGroupResourceProviderTest.java
>  753daec 
> 
> Diff: https://reviews.apache.org/r/38301/diff/
> 
> 
> Testing
> ---
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

[jira] [Commented] (AMBARI-12393) Ambari Server is vulnerable to logjam

[Greg Hill (JIRA)]

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

Greg Hill commented on AMBARI-12393:


I didn't move the end quote in ambari-env.sh to cover the new setting.  
/facepalm  Testing it again now.

> Ambari Server is vulnerable to logjam
> -
>
> Key: AMBARI-12393
> URL: https://issues.apache.org/jira/browse/AMBARI-12393
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
> Environment: Red Hat Enterprise Linux Server release 6.6 
>Reporter: Jeffrey E  Rodriguez
>Priority: Critical
> Fix For: 2.1.2
>
>
> All Ambari servers running in Jetty server as well as the Ambari server 
> itself are vulnerable to LogJam  see details.
> https://weakdh.org/
> Test setting up Ambari SSL.
> 1. create certificate 
> openssl genrsa -out $wserver.key 2048 
>  openssl req -new -key $wserver.key -out $wserver.csr  
>   openssl x509 -req -days 365 -in $wserver.csr -signkey $wserver.key -out 
> $wserver.crt
> where #wscver is hostname of ambari server.
> 2. run ambari-server setup-security
> 3. Run openssl to check DH key lenght
> penssl s_client -connect bdvs1390.svl.ibm.com:8444 -cipher "EDH" | grep 
> "Server Temp Key"
> depth=0 C = US, ST = CA, L = San Jose, O = IBM, OU = BI, CN = sever.com, 
> emailAddress = test
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = US, ST = CA, L = San Jose, O = IBM, OU = BI, CN = server.com, 
> emailAddress = test
> verify return:1
> Server Temp Key: DH, 1024 bits
> Furthermore, some versions of Firefox would reject the certificate so Ambari 
> server would not be accessible from browser.
> Jira https://issues.apache.org/jira/browse/KNOX-566 has already been open for 
> Knox.



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

[jira] [Resolved] (AMBARI-13075) Make ambari-server robust/debuggable if user accidentally adds a config type to a config groups when it does not exist as base type

[Andrew Onischuk (JIRA)]

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

Andrew Onischuk resolved AMBARI-13075.
--
Resolution: Fixed

Committed to trunk and branch-2.1

> Make ambari-server robust/debuggable if user accidentally adds a config type 
> to a config groups when it does not exist as base type
> ---
>
> Key: AMBARI-13075
> URL: https://issues.apache.org/jira/browse/AMBARI-13075
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.1.2
>
>
> This was reported by a customer. Customer accidentally added a config of type
> `hivesite` to a config group.
> **Call**
> 
> 
> 
> curl 'http://ambhost:8080/api/v1/clusters/TSGHDP/config_groups/3' -X PUT 
> -H "X-Requested-By: ambari" --user admin:admin --data 
> '[{"ConfigGroup":{"id":3,"cluster_name":"HDP","group_name":"Hive_custom_group","tag":"HIVE","description":"","hosts":[{"host_name":"abc.local"}],"service_config_version_note":"hive
>  custom group tx timeout 
> property 
> change","desired_configs":[{"type":"hivesite","tag":"newversionforjdbcurl","properties":{"hive.txn.timeout":"310","javax.jdo.option.ConnectionURL":"jdbc:mysql://abc.local/hive2?createDatabaseIfNotExist=true"}}]}}]'
>  --compressed
> 
> This resulted in ambari-server failing to process agent heartbeat and throwing
> NPE.
> 
> 
> 
> 13 Aug 2015 10:36:28,961  WARN [ambari-hearbeat-monitor] 
> HeartbeatMonitor:129 - Exception received
> java.lang.NullPointerException
>   at 
> org.apache.ambari.server.state.host.HostImpl.getDesiredHostConfigs(HostImpl.java:1349)
>   at 
> org.apache.ambari.server.state.ConfigHelper.getEffectiveDesiredTags(ConfigHelper.java:109)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.createStatusCommand(HeartbeatMonitor.java:253)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.generateStatusCommands(HeartbeatMonitor.java:218)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.doWork(HeartbeatMonitor.java:190)
>   at 
> org.apache.ambari.server.agent.HeartbeatMonitor.run(HeartbeatMonitor.java:121)
>   at java.lang.Thread.run(Thread.java:745)
> 



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

[jira] [Commented] (AMBARI-12393) Ambari Server is vulnerable to logjam

[Greg Hill (JIRA)]

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

Greg Hill commented on AMBARI-12393:


Looks like the setting isn't needed, just an update to the jdk.

> Ambari Server is vulnerable to logjam
> -
>
> Key: AMBARI-12393
> URL: https://issues.apache.org/jira/browse/AMBARI-12393
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.0
> Environment: Red Hat Enterprise Linux Server release 6.6 
>Reporter: Jeffrey E  Rodriguez
>Priority: Critical
> Fix For: 2.1.2
>
>
> All Ambari servers running in Jetty server as well as the Ambari server 
> itself are vulnerable to LogJam  see details.
> https://weakdh.org/
> Test setting up Ambari SSL.
> 1. create certificate 
> openssl genrsa -out $wserver.key 2048 
>  openssl req -new -key $wserver.key -out $wserver.csr  
>   openssl x509 -req -days 365 -in $wserver.csr -signkey $wserver.key -out 
> $wserver.crt
> where #wscver is hostname of ambari server.
> 2. run ambari-server setup-security
> 3. Run openssl to check DH key lenght
> penssl s_client -connect bdvs1390.svl.ibm.com:8444 -cipher "EDH" | grep 
> "Server Temp Key"
> depth=0 C = US, ST = CA, L = San Jose, O = IBM, OU = BI, CN = sever.com, 
> emailAddress = test
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 C = US, ST = CA, L = San Jose, O = IBM, OU = BI, CN = server.com, 
> emailAddress = test
> verify return:1
> Server Temp Key: DH, 1024 bits
> Furthermore, some versions of Firefox would reject the certificate so Ambari 
> server would not be accessible from browser.
> Jira https://issues.apache.org/jira/browse/KNOX-566 has already been open for 
> Knox.



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

[jira] [Created] (AMBARI-13076) Incorrect UI behaviour if host registration request fails

[Antonenko Alexander (JIRA)]

Antonenko Alexander created AMBARI-13076:


 Summary: Incorrect UI behaviour if host registration request fails
 Key: AMBARI-13076
 URL: https://issues.apache.org/jira/browse/AMBARI-13076
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.1.1
Reporter: Antonenko Alexander
Assignee: Antonenko Alexander
Priority: Critical
 Fix For: 2.2.0


If host bootstrap request on step 3 of installer fails, UI should show popup 
with this infornation and link to reload page and retry that request certain 
number of times with certain interval. The repeated request is sent to wrong 
URL (root level). Hence bootstrap results aren't processed, and user can 
neither proceed nor go back from the current step.




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