[jira] [Created] (AMBARI-18535) Ambari is not picking up the latest repo for HDP-2.4

[Zhe (Joe) Wang (JIRA)]

Zhe (Joe) Wang created AMBARI-18535:
---

 Summary: Ambari is not picking up the latest repo for HDP-2.4
 Key: AMBARI-18535
 URL: https://issues.apache.org/jira/browse/AMBARI-18535
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.5.0
Reporter: Zhe (Joe) Wang
Assignee: Zhe (Joe) Wang
 Fix For: 2.5.0


During fresh deployment, if HDP-2.4 is chosen then Ambari does not default to 
the latest 2.4 release, HDP-2.4.2. This is likely because VDF files do not 
exist for HDP-2.4 release and the older mechanism of picking the latest repo 
URL form the hdp_urlinfo.json does not work. HDP-2.4.0 is chosen where as the 
latest is HDP-2.4.2



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

[jira] [Updated] (AMBARI-18534) Advanced storm-atlas-application.properties panel is not opened by default upon filtering

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian updated AMBARI-18534:

Status: Patch Available  (was: In Progress)

> Advanced storm-atlas-application.properties panel is not opened by default 
> upon filtering
> -
>
> Key: AMBARI-18534
> URL: https://issues.apache.org/jira/browse/AMBARI-18534
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Dhanya Balasundaran
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.0
>
> Attachments: AMBARI-18534.v0.patch
>
>
> - Navigate to Storm configs page
> - Type "hook" in the property filter
> - Its expected that Advanced storm-atlas-application.properties panel opens 
> up by default
> - Actual: its still closed. please see the screenshot attached



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

[jira] [Updated] (AMBARI-18534) Advanced storm-atlas-application.properties panel is not opened by default upon filtering

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian updated AMBARI-18534:

Fix Version/s: 2.5.0

> Advanced storm-atlas-application.properties panel is not opened by default 
> upon filtering
> -
>
> Key: AMBARI-18534
> URL: https://issues.apache.org/jira/browse/AMBARI-18534
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Dhanya Balasundaran
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.0
>
> Attachments: AMBARI-18534.v0.patch
>
>
> - Navigate to Storm configs page
> - Type "hook" in the property filter
> - Its expected that Advanced storm-atlas-application.properties panel opens 
> up by default
> - Actual: its still closed. please see the screenshot attached



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

[jira] [Updated] (AMBARI-18534) Advanced storm-atlas-application.properties panel is not opened by default upon filtering

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian updated AMBARI-18534:

Affects Version/s: 2.4.0

> Advanced storm-atlas-application.properties panel is not opened by default 
> upon filtering
> -
>
> Key: AMBARI-18534
> URL: https://issues.apache.org/jira/browse/AMBARI-18534
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Dhanya Balasundaran
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.0
>
> Attachments: AMBARI-18534.v0.patch
>
>
> - Navigate to Storm configs page
> - Type "hook" in the property filter
> - Its expected that Advanced storm-atlas-application.properties panel opens 
> up by default
> - Actual: its still closed. please see the screenshot attached



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

[jira] [Updated] (AMBARI-18534) Advanced storm-atlas-application.properties panel is not opened by default upon filtering

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian updated AMBARI-18534:

Attachment: AMBARI-18534.v0.patch

> Advanced storm-atlas-application.properties panel is not opened by default 
> upon filtering
> -
>
> Key: AMBARI-18534
> URL: https://issues.apache.org/jira/browse/AMBARI-18534
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Dhanya Balasundaran
>Assignee: Vivek Ratnavel Subramanian
> Fix For: 2.5.0
>
> Attachments: AMBARI-18534.v0.patch
>
>
> - Navigate to Storm configs page
> - Type "hook" in the property filter
> - Its expected that Advanced storm-atlas-application.properties panel opens 
> up by default
> - Actual: its still closed. please see the screenshot attached



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

[jira] [Assigned] (AMBARI-18534) Advanced storm-atlas-application.properties panel is not opened by default upon filtering

[Vivek Ratnavel Subramanian (JIRA)]

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

Vivek Ratnavel Subramanian reassigned AMBARI-18534:
---

Assignee: Vivek Ratnavel Subramanian

> Advanced storm-atlas-application.properties panel is not opened by default 
> upon filtering
> -
>
> Key: AMBARI-18534
> URL: https://issues.apache.org/jira/browse/AMBARI-18534
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Reporter: Dhanya Balasundaran
>Assignee: Vivek Ratnavel Subramanian
>
> - Navigate to Storm configs page
> - Type "hook" in the property filter
> - Its expected that Advanced storm-atlas-application.properties panel opens 
> up by default
> - Actual: its still closed. please see the screenshot attached



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

[jira] [Created] (AMBARI-18534) Advanced storm-atlas-application.properties panel is not opened by default upon filtering

[Dhanya Balasundaran (JIRA)]

Dhanya Balasundaran created AMBARI-18534:


 Summary: Advanced storm-atlas-application.properties panel is not 
opened by default upon filtering
 Key: AMBARI-18534
 URL: https://issues.apache.org/jira/browse/AMBARI-18534
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Reporter: Dhanya Balasundaran


- Navigate to Storm configs page
- Type "hook" in the property filter
- Its expected that Advanced storm-atlas-application.properties panel opens up 
by default
- Actual: its still closed. please see the screenshot attached



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

[jira] [Commented] (AMBARI-18519) Enable Add/Remove JournalNode on NNHA Wizard Step 2

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18519:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #108 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/108/])
AMBARI-18519 - Enable Add/Remove JournalNode on NNHA Wizard Step 2 (rzang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=3b8a9db3678da527e5b9a1de88194105b46b5ba5])
* (edit) ambari-web/app/templates/main/admin/highAvailability/nameNode/step3.hbs
* (edit) 
ambari-web/app/controllers/main/admin/highAvailability/nameNode/step2_controller.js


> Enable Add/Remove JournalNode on NNHA Wizard Step 2
> ---
>
> Key: AMBARI-18519
> URL: https://issues.apache.org/jira/browse/AMBARI-18519
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18519.patch
>
>
> Enable Add/Remove JournalNode on NNHA Wizard Step 2



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

[jira] [Commented] (AMBARI-18519) Enable Add/Remove JournalNode on NNHA Wizard Step 2

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18519:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5759 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5759/])
AMBARI-18519 - Enable Add/Remove JournalNode on NNHA Wizard Step 2 (rzang: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=a442efbde22ac635b60b5650df397fd06c147ae1])
* (edit) 
ambari-web/app/controllers/main/admin/highAvailability/nameNode/step2_controller.js
* (edit) ambari-web/app/templates/main/admin/highAvailability/nameNode/step3.hbs


> Enable Add/Remove JournalNode on NNHA Wizard Step 2
> ---
>
> Key: AMBARI-18519
> URL: https://issues.apache.org/jira/browse/AMBARI-18519
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18519.patch
>
>
> Enable Add/Remove JournalNode on NNHA Wizard Step 2



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

[jira] [Updated] (AMBARI-18533) Removal of users.ldap_user & groups.ldap_group columns

[Vishal Ghugare (JIRA)]

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

Vishal Ghugare updated AMBARI-18533:

Description: 
This task is to remove 
-ldap_user column from users table & 
-ldap_group column from groups table.

These columns are not necessary after having user_type in users & group_type in 
groups table.

This task should also make sure ambari-server code is updated accordingly.

  was:
This task is to remove 
-ldap_user column from users table & 
-ldap_group column from groups table.

These columns are not necessary after having user_type in users & group_type in 
groups column.

This task should also make sure appropriate changes to ambari-server code.


> Removal of users.ldap_user & groups.ldap_group columns
> --
>
> Key: AMBARI-18533
> URL: https://issues.apache.org/jira/browse/AMBARI-18533
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Vishal Ghugare
>Assignee: Vishal Ghugare
>
> This task is to remove 
> -ldap_user column from users table & 
> -ldap_group column from groups table.
> These columns are not necessary after having user_type in users & group_type 
> in groups table.
> This task should also make sure ambari-server code is updated accordingly.



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

[jira] [Created] (AMBARI-18533) Removal of users.ldap_user & groups.ldap_group columns

[Vishal Ghugare (JIRA)]

Vishal Ghugare created AMBARI-18533:
---

 Summary: Removal of users.ldap_user & groups.ldap_group columns
 Key: AMBARI-18533
 URL: https://issues.apache.org/jira/browse/AMBARI-18533
 Project: Ambari
  Issue Type: Task
  Components: ambari-server
Reporter: Vishal Ghugare
Assignee: Vishal Ghugare


This task is to remove 
-ldap_user column from users table & 
-ldap_group column from groups table.

These columns are not necessary after having user_type in users & group_type in 
groups column.

This task should also make sure appropriate changes to ambari-server code.



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

[jira] [Updated] (AMBARI-18520) Ambari usernames should not be converted to lowercase before storing in the DB.

[Nahappan Somasundaram (JIRA)]

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

Nahappan Somasundaram updated AMBARI-18520:
---
Fix Version/s: 2.5.0
   Status: Patch Available  (was: Open)

> Ambari usernames should not be converted to lowercase before storing in the 
> DB.
> ---
>
> Key: AMBARI-18520
> URL: https://issues.apache.org/jira/browse/AMBARI-18520
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: rb52500.patch
>
>
> AMBARI-17383 searches the username in a case-insensitive way but introduced a 
> regression by storing the usernames in lowercase in the DB. Usernames should 
> be stored as-is.



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

[jira] [Updated] (AMBARI-18520) Ambari usernames should not be converted to lowercase before storing in the DB.

[Nahappan Somasundaram (JIRA)]

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

Nahappan Somasundaram updated AMBARI-18520:
---
Status: Open  (was: Patch Available)

> Ambari usernames should not be converted to lowercase before storing in the 
> DB.
> ---
>
> Key: AMBARI-18520
> URL: https://issues.apache.org/jira/browse/AMBARI-18520
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: rb52500.patch
>
>
> AMBARI-17383 searches the username in a case-insensitive way but introduced a 
> regression by storing the usernames in lowercase in the DB. Usernames should 
> be stored as-is.



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

[jira] [Updated] (AMBARI-18532) blueprint_setting table incorrectly defines blueprint_name column in DDL for MySQL

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-18532:
---
Attachment: AMBARI-18532.patch

> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL
> --
>
> Key: AMBARI-18532
> URL: https://issues.apache.org/jira/browse/AMBARI-18532
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-upgrade
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18532.patch
>
>
> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL:
> {code:title=Current Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(100) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> {code:title=Correct Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(255) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> This will cause errors when creating the table while MySQL sets up the 
> foreign key constraint due to the column mismatch.  



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

[jira] [Updated] (AMBARI-18532) blueprint_setting table incorrectly defines blueprint_name column in DDL for MySQL

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-18532:
---
Attachment: (was: AMBARI-18532.patch)

> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL
> --
>
> Key: AMBARI-18532
> URL: https://issues.apache.org/jira/browse/AMBARI-18532
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-upgrade
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.2
>
>
> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL:
> {code:title=Current Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(100) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> {code:title=Correct Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(255) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> This will cause errors when creating the table while MySQL sets up the 
> foreign key constraint due to the column mismatch.  



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

[jira] [Updated] (AMBARI-18532) blueprint_setting table incorrectly defines blueprint_name column in DDL for MySQL

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-18532:
---
Attachment: AMBARI-18532.patch

> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL
> --
>
> Key: AMBARI-18532
> URL: https://issues.apache.org/jira/browse/AMBARI-18532
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-upgrade
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18532.patch
>
>
> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL:
> {code:title=Current Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(100) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> {code:title=Correct Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(255) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> This will cause errors when creating the table while MySQL sets up the 
> foreign key constraint due to the column mismatch.  



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

[jira] [Updated] (AMBARI-18532) blueprint_setting table incorrectly defines blueprint_name column in DDL for MySQL

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-18532:
---
Status: Patch Available  (was: Open)

> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL
> --
>
> Key: AMBARI-18532
> URL: https://issues.apache.org/jira/browse/AMBARI-18532
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-upgrade
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18532.patch
>
>
> blueprint_setting table incorrectly defines blueprint_name column in DDL for 
> MySQL:
> {code:title=Current Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(100) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> {code:title=Correct Definition}
> CREATE TABLE blueprint_setting (
>   id BIGINT NOT NULL,
>   blueprint_name VARCHAR(255) NOT NULL,
>   setting_name VARCHAR(100) NOT NULL,
>   setting_data MEDIUMTEXT NOT NULL,
>   CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
>   CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
>   CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) 
> REFERENCES blueprint(blueprint_name));
> {code}
> This will cause errors when creating the table while MySQL sets up the 
> foreign key constraint due to the column mismatch.  



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

[jira] [Created] (AMBARI-18532) blueprint_setting table incorrectly defines blueprint_name column in DDL for MySQL

[Vitaly Brodetskyi (JIRA)]

Vitaly Brodetskyi created AMBARI-18532:
--

 Summary: blueprint_setting table incorrectly defines 
blueprint_name column in DDL for MySQL
 Key: AMBARI-18532
 URL: https://issues.apache.org/jira/browse/AMBARI-18532
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server, ambari-upgrade
Affects Versions: 2.4.0
Reporter: Vitaly Brodetskyi
Assignee: Vitaly Brodetskyi
Priority: Critical
 Fix For: 2.4.2


blueprint_setting table incorrectly defines blueprint_name column in DDL for 
MySQL:

{code:title=Current Definition}
CREATE TABLE blueprint_setting (
  id BIGINT NOT NULL,
  blueprint_name VARCHAR(100) NOT NULL,
  setting_name VARCHAR(100) NOT NULL,
  setting_data MEDIUMTEXT NOT NULL,
  CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
  CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
  CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) REFERENCES 
blueprint(blueprint_name));
{code}

{code:title=Correct Definition}
CREATE TABLE blueprint_setting (
  id BIGINT NOT NULL,
  blueprint_name VARCHAR(255) NOT NULL,
  setting_name VARCHAR(100) NOT NULL,
  setting_data MEDIUMTEXT NOT NULL,
  CONSTRAINT PK_blueprint_setting PRIMARY KEY (id),
  CONSTRAINT UQ_blueprint_setting_name UNIQUE(blueprint_name,setting_name),
  CONSTRAINT FK_blueprint_setting_name FOREIGN KEY (blueprint_name) REFERENCES 
blueprint(blueprint_name));
{code}

This will cause errors when creating the table while MySQL sets up the foreign 
key constraint due to the column mismatch.  




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

[jira] [Commented] (AMBARI-18520) Ambari usernames should not be converted to lowercase before storing in the DB.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18520:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12831610/rb52500.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/8808//console

This message is automatically generated.

> Ambari usernames should not be converted to lowercase before storing in the 
> DB.
> ---
>
> Key: AMBARI-18520
> URL: https://issues.apache.org/jira/browse/AMBARI-18520
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: rb52500.patch
>
>
> AMBARI-17383 searches the username in a case-insensitive way but introduced a 
> regression by storing the usernames in lowercase in the DB. Usernames should 
> be stored as-is.



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

[jira] [Commented] (AMBARI-18510) Use logsearch truststore to look for credential in case of external authentication

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18510:


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

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

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

This message is automatically generated.

> Use logsearch truststore to look for credential in case of external 
> authentication
> --
>
> Key: AMBARI-18510
> URL: https://issues.apache.org/jira/browse/AMBARI-18510
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 3.0.0
>
> Attachments: AMBARI-18510.patch
>
>
> In case of external authentication if the external server uses SSL Log Search 
> should also look for credentials in it's own trust store. So far it did only 
> in cacerts.



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

[jira] [Updated] (AMBARI-18528) Need a way to escape config values that contain $

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez updated AMBARI-18528:
-
Summary: Need a way to escape config values that contain $  (was: Add 
support for specification of auth_to_local rules)

> Need a way to escape config values that contain $
> -
>
> Key: AMBARI-18528
> URL: https://issues.apache.org/jira/browse/AMBARI-18528
> Project: Ambari
>  Issue Type: Bug
>Reporter: Ted Yu
>
> We tried specifying auth_to_local in zookeeper env input box:
> {code}
> export SERVER_JVMFLAGS="$SERVER_JVMFLAGS 
> -Dzookeeper.security.auth_to_local=RULE:[2:$1@$0](hb...@c.net)s/.*/hbase/  
> -Djava.security.auth.login.config={{zk_server_jaas_file}}"
> {code}
> However, when zookeeper quorum starts, the rule got interrupted with 
> zkServer.sh
> We should add the capability of specifying auth_to_local in Ambari UI



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

[jira] [Commented] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18527:


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

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

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

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

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

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

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

This message is automatically generated.

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18527.patch
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Updated] (AMBARI-18519) Enable Add/Remove JournalNode on NNHA Wizard Step 2

[Richard Zang (JIRA)]

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

Richard Zang updated AMBARI-18519:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed to trunk and 2.5 a442efbde22ac635b60b5650df397fd06c147ae1

> Enable Add/Remove JournalNode on NNHA Wizard Step 2
> ---
>
> Key: AMBARI-18519
> URL: https://issues.apache.org/jira/browse/AMBARI-18519
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.5.0
>Reporter: Richard Zang
>Assignee: Richard Zang
> Fix For: 2.5.0
>
> Attachments: AMBARI-18519.patch
>
>
> Enable Add/Remove JournalNode on NNHA Wizard Step 2



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

[jira] [Updated] (AMBARI-18531) Fix typo in the logsearch input config of Falcon

[Miklos Gergely (JIRA)]

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

Miklos Gergely updated AMBARI-18531:

Status: Patch Available  (was: In Progress)

> Fix typo in the logsearch input config of Falcon
> 
>
> Key: AMBARI-18531
> URL: https://issues.apache.org/jira/browse/AMBARI-18531
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 3.0.0
>
>




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

[jira] [Created] (AMBARI-18531) Fix typo in the logsearch input config of Falcon

[Miklos Gergely (JIRA)]

Miklos Gergely created AMBARI-18531:
---

 Summary: Fix typo in the logsearch input config of Falcon
 Key: AMBARI-18531
 URL: https://issues.apache.org/jira/browse/AMBARI-18531
 Project: Ambari
  Issue Type: Bug
  Components: ambari-logsearch
Affects Versions: 2.4.0
Reporter: Miklos Gergely
Assignee: Miklos Gergely
 Fix For: 3.0.0






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

[jira] [Created] (AMBARI-18530) Fix typo in the logsearch input config of Falcon

[Miklos Gergely (JIRA)]

Miklos Gergely created AMBARI-18530:
---

 Summary: Fix typo in the logsearch input config of Falcon
 Key: AMBARI-18530
 URL: https://issues.apache.org/jira/browse/AMBARI-18530
 Project: Ambari
  Issue Type: Bug
  Components: ambari-logsearch
Affects Versions: 2.4.0
Reporter: Miklos Gergely
Assignee: Miklos Gergely
 Fix For: 3.0.0






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

[jira] [Commented] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18526:


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

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

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

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

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

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

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

This message is automatically generated.

> Ambari breaks sudo and user access if Ambari Agent misconfigured
> 
>
> Key: AMBARI-18526
> URL: https://issues.apache.org/jira/browse/AMBARI-18526
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.5.0
>
> Attachments: AMBARI-18526.patch
>
>
> While working on Ambari installation using Vagrant I found following issues 
> that can be potentially dangerous and destroy sudo and /home permissions
> Steps to reproduce:
> Remove or misconfigure following configs from ambari-agent.ini file:
> {code}
> [agent]
> logdir=/var/log/ambari-agent
> piddir=/var/run/ambari-agent
> {code}
> Start ambari agent.  Note that log, pid, and out want to be written to /.  
> Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
> user will not be able to connect to cluster using private key due to 
> permissions and folder ownership switch to root.
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# ambari-agent start
> chown: changing ownership of `/proc/12937': Operation not permitted
> chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
> chown: changing ownership of `/proc/12938': Operation not permitted
> chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
> chown: changing ownership of `/proc/12941': Operation not permitted
> chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
> directory
> chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file 
> or directory
> chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
> chown: changing ownership of `/proc/12942/fd/4': No such file or directory
> chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
> chown: changing ownership of `/proc/12942': Operation not permitted
> Starting ambari-agent
> Verifying ambari-agent process status...
> Ambari Agent successfully started
> Agent PID at: /ambari-agent.pid
> Agent out at: /ambari-agent.out
> Agent log at: /ambari-agent.log
> {code}
> Sticky bit is removed from sudo as result of it
> {code}
> [root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
> ---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> it should be:
> {code}
> [root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
> ---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> All user folder is messed up as owned by root
> {code}
> [root@ambari-slave1 vagrant]# ls -ld /home/
> drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/
> [root@ambari-slave1 vagrant]# ls -ld /home/vagrant
> drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
> {code}
> sudo is broken:
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# exit
> exit
> [vagrant@ambari-slave1 ~]$ sudo su
> sudo: effective uid is not 0, is sudo installed setuid root?
> {code}
> this is caused due to by function in /usr/sbin/ambari-agent
> {code}
> get_agent_property() {
> property_name="$1"
> value=$(awk -F "=" "/$property_name/ {print \$2}" 
> /etc/ambari-agent/conf/ambari-agent.ini)
> echo $value
> }
> {code}



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

[jira] [Commented] (AMBARI-18521) Stack upgrade fix for Ranger in secure env

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18521:


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

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

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

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

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

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

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

This message is automatically generated.

> Stack upgrade fix for Ranger in secure env
> --
>
> Key: AMBARI-18521
> URL: https://issues.apache.org/jira/browse/AMBARI-18521
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18521.patch
>
>
> Stack changes required while upgrading to 2.5 in secure env
> * Remove adding spnego principal value to 
> ranger-admin-site/ranger.spnego.kerberos.principal
> * Get storm principal bare name and update it accordingly to 
> ranger-admin-site.xml/ranger.plugins.storm.serviceuser



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

[jira] [Created] (AMBARI-18529) Custom logsearch property should override default value

[Miklos Gergely (JIRA)]

Miklos Gergely created AMBARI-18529:
---

 Summary: Custom logsearch property should override default value
 Key: AMBARI-18529
 URL: https://issues.apache.org/jira/browse/AMBARI-18529
 Project: Ambari
  Issue Type: Bug
  Components: ambari-logsearch
Affects Versions: 2.4.0
Reporter: Miklos Gergely
Assignee: Miklos Gergely
 Fix For: 3.0.0






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

[jira] [Updated] (AMBARI-18510) Use logsearch truststore to look for credential in case of external authentication

[Miklos Gergely (JIRA)]

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

Miklos Gergely updated AMBARI-18510:

Attachment: AMBARI-18510.patch

> Use logsearch truststore to look for credential in case of external 
> authentication
> --
>
> Key: AMBARI-18510
> URL: https://issues.apache.org/jira/browse/AMBARI-18510
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 3.0.0
>
> Attachments: AMBARI-18510.patch
>
>
> In case of external authentication if the external server uses SSL Log Search 
> should also look for credentials in it's own trust store. So far it did only 
> in cacerts.



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

[jira] [Updated] (AMBARI-18510) Use logsearch truststore to look for credential in case of external authentication

[Miklos Gergely (JIRA)]

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

Miklos Gergely updated AMBARI-18510:

Status: Patch Available  (was: In Progress)

> Use logsearch truststore to look for credential in case of external 
> authentication
> --
>
> Key: AMBARI-18510
> URL: https://issues.apache.org/jira/browse/AMBARI-18510
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Miklos Gergely
>Assignee: Miklos Gergely
> Fix For: 3.0.0
>
> Attachments: AMBARI-18510.patch
>
>
> In case of external authentication if the external server uses SSL Log Search 
> should also look for credentials in it's own trust store. So far it did only 
> in cacerts.



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

[jira] [Commented] (AMBARI-18517) Changes in upgrade path for Kafka metrics collector hosts config

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18517:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5758 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5758/])
AMBARI-18517 : Changes in upgrade path for Kafka metrics collector hosts 
(avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=06f3b8e9006ef6ad1533f33baa0c9544547bd244])
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog250.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog250Test.java


> Changes in upgrade path for Kafka metrics collector hosts config
> 
>
> Key: AMBARI-18517
> URL: https://issues.apache.org/jira/browse/AMBARI-18517
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 3.0.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
> Fix For: 3.0.0
>
> Attachments: AMBARI-18517.patch, Screen Shot 2016-08-22 at 11.00.37 
> AM.png
>
>
> Config change for Kafka was added through  AMBARI-18170  (Seen in attached 
> screensot). This jira is used to track Upgrade path changes.



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

[jira] [Commented] (AMBARI-18528) Add support for specification of auth_to_local rules

[Ted Yu (JIRA)]

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

Ted Yu commented on AMBARI-18528:
-

By putting a back slash in front of the dollar sign, we were able to get it 
working.

However, Ambari should do this automatically or, warn when the operator saves 
the config if back slash is missing.

> Add support for specification of auth_to_local rules
> 
>
> Key: AMBARI-18528
> URL: https://issues.apache.org/jira/browse/AMBARI-18528
> Project: Ambari
>  Issue Type: Bug
>Reporter: Ted Yu
>
> We tried specifying auth_to_local in zookeeper env input box:
> {code}
> export SERVER_JVMFLAGS="$SERVER_JVMFLAGS 
> -Dzookeeper.security.auth_to_local=RULE:[2:$1@$0](hb...@c.net)s/.*/hbase/  
> -Djava.security.auth.login.config={{zk_server_jaas_file}}"
> {code}
> However, when zookeeper quorum starts, the rule got interrupted with 
> zkServer.sh
> We should add the capability of specifying auth_to_local in Ambari UI



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

[jira] [Commented] (AMBARI-18528) Add support for specification of auth_to_local rules

[Alejandro Fernandez (JIRA)]

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

Alejandro Fernandez commented on AMBARI-18528:
--

Ambari is interpreting this as,
{code}
-Dzookeeper.security.auth_to_local=RULE:2:start@/usr/hdp/current/zookeeper-server/bin/zkServer.sh(hb...@realm.com)s/.*/hbase/
 ​
{code}

> Add support for specification of auth_to_local rules
> 
>
> Key: AMBARI-18528
> URL: https://issues.apache.org/jira/browse/AMBARI-18528
> Project: Ambari
>  Issue Type: Bug
>Reporter: Ted Yu
>
> We tried specifying auth_to_local in zookeeper env input box:
> {code}
> export SERVER_JVMFLAGS="$SERVER_JVMFLAGS 
> -Dzookeeper.security.auth_to_local=RULE:[2:$1@$0](hb...@c.net)s/.*/hbase/  
> -Djava.security.auth.login.config={{zk_server_jaas_file}}"
> {code}
> However, when zookeeper quorum starts, the rule got interrupted with 
> zkServer.sh
> We should add the capability of specifying auth_to_local in Ambari UI



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

[jira] [Commented] (AMBARI-18344) Metrics data is not available - AMS in distributed mode

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18344:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #107 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/107/])
AMBARI-18344 : Metrics data is not available - AMS in distributed mode. 
(avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=f93460c56dfaaa8e5bd104bf50566ecb9f9f2c50])
* (edit) 
ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/PhoenixHBaseAccessor.java
* (edit) 
ambari-metrics/ambari-metrics-timelineservice/src/test/java/org/apache/hadoop/yarn/server/applicationhistoryservice/metrics/timeline/discovery/TestMetadataManager.java


> Metrics data is not available - AMS in distributed mode
> ---
>
> Key: AMBARI-18344
> URL: https://issues.apache.org/jira/browse/AMBARI-18344
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.1
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18344.patch
>
>
> Data is unavailable for service, host and dashboard metrices. 
> Seeing below error in metrics_collector log :
> {code}
> [org.mortbay.jetty.EofException]
>   at 
> com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:159)
>   at 
> com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1437)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
>   at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:895)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:843)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:804)
>   at 
> com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
>   at 
> com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
>   at 
> com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
>   at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.apache.hadoop.security.http.XFrameOptionsFilter.doFilter(XFrameOptionsFilter.java:57)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.apache.hadoop.http.HttpServer2$QuotingInputFilter.doFilter(HttpServer2.java:1294)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>   at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:767)
>   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>   at 

[jira] [Commented] (AMBARI-18518) Sinks should not try to read collector hosts from Zk if AMS is in embedded mode

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18518:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5758 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5758/])
AMBARI-18518 : Sinks should not try to read collector hosts from Zk if 
(avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=98efb571d63a17973bb62a510593c2041c14dcf6])
* (edit) 
ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/availability/MetricCollectorHATest.java
* (edit) 
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/availability/MetricCollectorHAHelper.java


> Sinks should not try to read collector hosts from Zk if AMS is in embedded 
> mode
> ---
>
> Key: AMBARI-18518
> URL: https://issues.apache.org/jira/browse/AMBARI-18518
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 3.0.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-18518.patch
>
>
> Currently, an exception is constantly being thrown in sink logs.
> {code}
> 2016-10-03 21:01:06,537 WARN  availability.MetricCollectorHAHelper 
> (MetricCollectorHAHelper.java:findLiveCollectorHostsFromZNode(91)) - Unable 
> to connect to z
> ookeeper.
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.KeeperException$ConnectionLossException:
>  KeeperErrorCode = ConnectionLoss for /ambari-metrics-cluster
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.KeeperException.create(KeeperException.java:99)
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.KeeperException.create(KeeperException.java:51)
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.ZooKeeper.exists(ZooKeeper.java:1045)
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.ZooKeeper.exists(ZooKeeper.java:1073)
> at 
> org.apache.hadoop.metrics2.sink.timeline.availability.MetricCollectorHAHelper.findLiveCollectorHostsFromZNode(MetricCollectorHAHelper.java:78)
> at 
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.findPreferredCollectHost(AbstractTimelineMetricsSink.java:344)
> at 
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.emitMetrics(AbstractTimelineMetricsSink.java:216)
> at 
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:345)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at 
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> {code}
> After the change
> {code}
> 2016-10-03 21:08:31,494 INFO  availability.MetricCollectorHAHelper 
> (MetricCollectorHAHelper.java:findLiveCollectorHostsFromZNode(80)) - 
> /ambari-metrics-cluster znode does not exist. Skipping requesting live 
> instances from zookeeper
> {code}



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

[jira] [Commented] (AMBARI-18487) Test and refine Collector writes w.r.t sharing and timeouts

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18487:
-

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5758 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5758/])
AMBARI-18487 : Test and refine Collector writes w.r.t sharing and (avijayan: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=c10053b086ae1b4f41c3d4cdba18349144ef7ec4])
* (edit) 
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/blacklisted_set.py
* (edit) 
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/availability/MetricCollectorHAHelper.java
* (edit) 
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/config_reader.py
* (edit) 
ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java
* (edit) 
ambari-metrics/ambari-metrics-host-monitoring/src/main/python/core/emitter.py


> Test and refine Collector writes w.r.t sharing and timeouts
> ---
>
> Key: AMBARI-18487
> URL: https://issues.apache.org/jira/browse/AMBARI-18487
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 3.0.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-18487-trunk.patch
>
>
> Change metric monitor sharding strategy to hostname based.
> Fix issues in AbstractTimelineMetricSink
> Change Sink Zk retry policy to BoundedExponentialBackoffRetry.



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

[jira] [Created] (AMBARI-18528) Add support for specification of auth_to_local rules

[Ted Yu (JIRA)]

Ted Yu created AMBARI-18528:
---

 Summary: Add support for specification of auth_to_local rules
 Key: AMBARI-18528
 URL: https://issues.apache.org/jira/browse/AMBARI-18528
 Project: Ambari
  Issue Type: Bug
Reporter: Ted Yu


We tried specifying auth_to_local in zookeeper env input box:
{code}
export SERVER_JVMFLAGS="$SERVER_JVMFLAGS 
-Dzookeeper.security.auth_to_local=RULE:[2:$1@$0](hb...@c.net)s/.*/hbase/  
-Djava.security.auth.login.config={{zk_server_jaas_file}}"
{code}
However, when zookeeper quorum starts, the rule got interrupted with zkServer.sh

We should add the capability of specifying auth_to_local in Ambari UI



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

[jira] [Updated] (AMBARI-18520) Ambari usernames should not be converted to lowercase before storing in the DB.

[Nahappan Somasundaram (JIRA)]

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

Nahappan Somasundaram updated AMBARI-18520:
---
Status: Patch Available  (was: In Progress)

> Ambari usernames should not be converted to lowercase before storing in the 
> DB.
> ---
>
> Key: AMBARI-18520
> URL: https://issues.apache.org/jira/browse/AMBARI-18520
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: rb52500.patch
>
>
> AMBARI-17383 searches the username in a case-insensitive way but introduced a 
> regression by storing the usernames in lowercase in the DB. Usernames should 
> be stored as-is.



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

[jira] [Updated] (AMBARI-18520) Ambari usernames should not be converted to lowercase before storing in the DB.

[Nahappan Somasundaram (JIRA)]

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

Nahappan Somasundaram updated AMBARI-18520:
---
Attachment: rb52500.patch

> Ambari usernames should not be converted to lowercase before storing in the 
> DB.
> ---
>
> Key: AMBARI-18520
> URL: https://issues.apache.org/jira/browse/AMBARI-18520
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Nahappan Somasundaram
>Assignee: Nahappan Somasundaram
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: rb52500.patch
>
>
> AMBARI-17383 searches the username in a case-insensitive way but introduced a 
> regression by storing the usernames in lowercase in the DB. Usernames should 
> be stored as-is.



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

[jira] [Commented] (AMBARI-18522) Add Service wizard breaks on large clusters when persisting data in localStorage

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18522:


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

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

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

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

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

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

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

This message is automatically generated.

> Add Service wizard breaks on large clusters when persisting data in 
> localStorage
> 
>
> Key: AMBARI-18522
> URL: https://issues.apache.org/jira/browse/AMBARI-18522
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18522.patch
>
>
> Trying to navigate to Assign Masters page or Review page generates JS error 
> with "next" button disabled.



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

[jira] [Updated] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

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

Di Li updated AMBARI-18527:
---
Attachment: AMBARI-18527.patch

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18527.patch
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Updated] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

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

Di Li updated AMBARI-18527:
---
Status: Patch Available  (was: Open)

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18527.patch
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Updated] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

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

Di Li updated AMBARI-18527:
---
Attachment: (was: AMBARI-18527.patch)

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Updated] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

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

Di Li updated AMBARI-18527:
---
Status: Open  (was: Patch Available)

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Commented] (AMBARI-18516) Add ability to have services declare itself as tech-preview or mandatory

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18516:


{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12831521/AMBARI-18516.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 2 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/8802//testReport/
Console output: 
https://builds.apache.org/job/Ambari-trunk-test-patch/8802//console

This message is automatically generated.

> Add ability to have services declare itself as tech-preview or mandatory
> 
>
> Key: AMBARI-18516
> URL: https://issues.apache.org/jira/browse/AMBARI-18516
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
> Attachments: AMBARI-18516.patch
>
>
> When a service is added to a stack, it should be identified as:
> default/regular - service is optional on the cluster, UI usually shows it as
> tech-preview - service may be deployed, UI will not auto-select these 
> services and mark them as TechPreview
> mandatory - service need to be deployed and all deployment should fail is the 
> service is not selected during deployment
> Lets create a proposal of what changes are needed in the services' 
> metainfo.xml? Note that a service can change its attribute between stack 
> versions - e.g. move from "tech-preview" to "mandatory".



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

[jira] [Updated] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

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

Di Li updated AMBARI-18527:
---
Attachment: AMBARI-18527.patch

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18527.patch
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Updated] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

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

Di Li updated AMBARI-18527:
---
Status: Patch Available  (was: Open)

> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files
> 
>
> Key: AMBARI-18527
> URL: https://issues.apache.org/jira/browse/AMBARI-18527
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-agent
>Affects Versions: trunk
>Reporter: Di Li
>Assignee: Di Li
> Fix For: trunk
>
> Attachments: AMBARI-18527.patch
>
>
> HostCleanup.py to be able to resolve wildcards in a dir or file path to a 
> list of dirs and files



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

[jira] [Commented] (AMBARI-18463) Regression: krb5JAASLogin.conf is not updated during secure BP install

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18463:
-

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #106 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/106/])
AMBARI-18463. Regression: krb5JAASLogin.conf is not updated during (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b3410400126fe7a3d32f0fd2597f38eb82b3f67c])
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (add) 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerActionTest.java
* (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6/kerberos.json
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerAction.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/KerberosOperationHandler.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/utils/ShellCommandUtil.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/FinalizeKerberosServerAction.java


> Regression: krb5JAASLogin.conf is not updated during secure BP install
> --
>
> Key: AMBARI-18463
> URL: https://issues.apache.org/jira/browse/AMBARI-18463
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Blocker
>  Labels: blueprints, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-18463_branch-2.5_01.patch, 
> AMBARI-18463_branch-2.5_02.patch, AMBARI-18463_trunk_01.patch, 
> AMBARI-18463_trunk_02.patch
>
>
> When installing a secure cluster using Blueprints, Ambari's 
> {{/etc/ambari-server/conf/krb5JAASLogin.conf}} is not updated to reflect the 
> details of the Ambari Kerberos identity.
> This was introduced by the patch for AMBARI-18406.



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

[jira] [Commented] (AMBARI-18463) Regression: krb5JAASLogin.conf is not updated during secure BP install

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18463:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5757 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5757/])
AMBARI-18463. Regression: krb5JAASLogin.conf is not updated during (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1bf206907ea26eeeada640406ae2c130aa4140c9])
* (edit) ambari-server/src/main/resources/stacks/HDP/2.0.6/kerberos.json
* (add) 
ambari-server/src/test/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerActionTest.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/ConfigureAmbariIdentitiesServerAction.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/utils/ShellCommandUtil.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/FinalizeKerberosServerAction.java
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
* (edit) 
ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/KerberosOperationHandler.java


> Regression: krb5JAASLogin.conf is not updated during secure BP install
> --
>
> Key: AMBARI-18463
> URL: https://issues.apache.org/jira/browse/AMBARI-18463
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Blocker
>  Labels: blueprints, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-18463_branch-2.5_01.patch, 
> AMBARI-18463_branch-2.5_02.patch, AMBARI-18463_trunk_01.patch, 
> AMBARI-18463_trunk_02.patch
>
>
> When installing a secure cluster using Blueprints, Ambari's 
> {{/etc/ambari-server/conf/krb5JAASLogin.conf}} is not updated to reflect the 
> details of the Ambari Kerberos identity.
> This was introduced by the patch for AMBARI-18406.



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

[jira] [Created] (AMBARI-18527) HostCleanup.py to be able to resolve wildcards in a dir or file path to a list of dirs and files

[Di Li (JIRA)]

Di Li created AMBARI-18527:
--

 Summary: HostCleanup.py to be able to resolve wildcards in a dir 
or file path to a list of dirs and files
 Key: AMBARI-18527
 URL: https://issues.apache.org/jira/browse/AMBARI-18527
 Project: Ambari
  Issue Type: Bug
  Components: ambari-agent
Affects Versions: trunk
Reporter: Di Li
Assignee: Di Li
 Fix For: trunk


HostCleanup.py to be able to resolve wildcards in a dir or file path to a list 
of dirs and files



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

[jira] [Updated] (AMBARI-18518) Sinks should not try to read collector hosts from Zk if AMS is in embedded mode

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-18518:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to trunk.

> Sinks should not try to read collector hosts from Zk if AMS is in embedded 
> mode
> ---
>
> Key: AMBARI-18518
> URL: https://issues.apache.org/jira/browse/AMBARI-18518
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 3.0.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-18518.patch
>
>
> Currently, an exception is constantly being thrown in sink logs.
> {code}
> 2016-10-03 21:01:06,537 WARN  availability.MetricCollectorHAHelper 
> (MetricCollectorHAHelper.java:findLiveCollectorHostsFromZNode(91)) - Unable 
> to connect to z
> ookeeper.
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.KeeperException$ConnectionLossException:
>  KeeperErrorCode = ConnectionLoss for /ambari-metrics-cluster
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.KeeperException.create(KeeperException.java:99)
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.KeeperException.create(KeeperException.java:51)
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.ZooKeeper.exists(ZooKeeper.java:1045)
> at 
> org.apache.hadoop.metrics2.sink.relocated.zookeeper.ZooKeeper.exists(ZooKeeper.java:1073)
> at 
> org.apache.hadoop.metrics2.sink.timeline.availability.MetricCollectorHAHelper.findLiveCollectorHostsFromZNode(MetricCollectorHAHelper.java:78)
> at 
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.findPreferredCollectHost(AbstractTimelineMetricsSink.java:344)
> at 
> org.apache.hadoop.metrics2.sink.timeline.AbstractTimelineMetricsSink.emitMetrics(AbstractTimelineMetricsSink.java:216)
> at 
> org.apache.hadoop.metrics2.sink.timeline.HadoopTimelineMetricsSink.putMetrics(HadoopTimelineMetricsSink.java:345)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:186)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.consume(MetricsSinkAdapter.java:43)
> at 
> org.apache.hadoop.metrics2.impl.SinkQueue.consumeAll(SinkQueue.java:87)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter.publishMetricsFromQueue(MetricsSinkAdapter.java:134)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSinkAdapter$1.run(MetricsSinkAdapter.java:88)
> {code}
> After the change
> {code}
> 2016-10-03 21:08:31,494 INFO  availability.MetricCollectorHAHelper 
> (MetricCollectorHAHelper.java:findLiveCollectorHostsFromZNode(80)) - 
> /ambari-metrics-cluster znode does not exist. Skipping requesting live 
> instances from zookeeper
> {code}



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

[jira] [Updated] (AMBARI-18487) Test and refine Collector writes w.r.t sharing and timeouts

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-18487:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to trunk.

> Test and refine Collector writes w.r.t sharing and timeouts
> ---
>
> Key: AMBARI-18487
> URL: https://issues.apache.org/jira/browse/AMBARI-18487
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-metrics
>Affects Versions: 3.0.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-18487-trunk.patch
>
>
> Change metric monitor sharding strategy to hostname based.
> Fix issues in AbstractTimelineMetricSink
> Change Sink Zk retry policy to BoundedExponentialBackoffRetry.



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

[jira] [Updated] (AMBARI-18517) Changes in upgrade path for Kafka metrics collector hosts config

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-18517:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to trunk.

> Changes in upgrade path for Kafka metrics collector hosts config
> 
>
> Key: AMBARI-18517
> URL: https://issues.apache.org/jira/browse/AMBARI-18517
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 3.0.0
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
> Fix For: 3.0.0
>
> Attachments: AMBARI-18517.patch, Screen Shot 2016-08-22 at 11.00.37 
> AM.png
>
>
> Config change for Kafka was added through  AMBARI-18170  (Seen in attached 
> screensot). This jira is used to track Upgrade path changes.



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

[jira] [Commented] (AMBARI-18344) Metrics data is not available - AMS in distributed mode

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan commented on AMBARI-18344:


Pushed to branch-2.4 & branch-2.5 as well.

> Metrics data is not available - AMS in distributed mode
> ---
>
> Key: AMBARI-18344
> URL: https://issues.apache.org/jira/browse/AMBARI-18344
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.1
>Reporter: Aravindan Vijayan
>Assignee: Aravindan Vijayan
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18344.patch
>
>
> Data is unavailable for service, host and dashboard metrices. 
> Seeing below error in metrics_collector log :
> {code}
> [org.mortbay.jetty.EofException]
>   at 
> com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:159)
>   at 
> com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1437)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
>   at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:895)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:843)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:804)
>   at 
> com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
>   at 
> com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
>   at 
> com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
>   at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.apache.hadoop.security.http.XFrameOptionsFilter.doFilter(XFrameOptionsFilter.java:57)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.apache.hadoop.http.HttpServer2$QuotingInputFilter.doFilter(HttpServer2.java:1294)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
>   at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>   at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:767)
>   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>   at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>   at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> Caused by: javax.xml.bind.MarshalException
>  - with linked exception:
> [org.mortbay.jetty.EofException]
>   at 
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:325)
>   at 
> com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:249)
>   at 
> 

[jira] [Commented] (AMBARI-18524) Kafka widget update needs UpgradeCatalog handling.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18524:


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

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

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

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

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

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

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

This message is automatically generated.

> Kafka widget update needs UpgradeCatalog handling.
> --
>
> Key: AMBARI-18524
> URL: https://issues.apache.org/jira/browse/AMBARI-18524
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18524.patch
>
>
> The widgets for "Active Controller Count" and "Replica Manager" on the Kafka 
> service page show incorrect values when more than 1 Kafka Brokers exist. This 
> was fixed via   AMBARI-18485  but it will need UpgradeCatalog handling.



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

[jira] [Commented] (AMBARI-18360) ambari-agent check for unset variables (AMBARI-18317)

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko commented on AMBARI-18360:
-

Cherry-picked commit to branch-2.4

> ambari-agent check for unset variables (AMBARI-18317)
> -
>
> Key: AMBARI-18360
> URL: https://issues.apache.org/jira/browse/AMBARI-18360
> Project: Ambari
>  Issue Type: Bug
>Reporter: Andrew Onischuk
>Assignee: Andrew Onischuk
> Fix For: 2.4.2
>
> Attachments: AMBARI-18360.patch
>
>
> Reported in community:
> 



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

[jira] [Updated] (AMBARI-18463) Regression: krb5JAASLogin.conf is not updated during secure BP install

[Robert Levas (JIRA)]

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

Robert Levas updated AMBARI-18463:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed to trunk
{noformat}
commit 1bf206907ea26eeeada640406ae2c130aa4140c9
Author: Robert Levas 
Date:   Tue Oct 4 13:15:43 2016 -0400
{noformat}

Committed to branch-2.5
{noformat}
commit b3410400126fe7a3d32f0fd2597f38eb82b3f67c
Author: Robert Levas 
Date:   Tue Oct 4 13:18:22 2016 -0400
{noformat}


> Regression: krb5JAASLogin.conf is not updated during secure BP install
> --
>
> Key: AMBARI-18463
> URL: https://issues.apache.org/jira/browse/AMBARI-18463
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Robert Levas
>Assignee: Robert Levas
>Priority: Blocker
>  Labels: blueprints, kerberos
> Fix For: 2.5.0
>
> Attachments: AMBARI-18463_branch-2.5_01.patch, 
> AMBARI-18463_branch-2.5_02.patch, AMBARI-18463_trunk_01.patch, 
> AMBARI-18463_trunk_02.patch
>
>
> When installing a secure cluster using Blueprints, Ambari's 
> {{/etc/ambari-server/conf/krb5JAASLogin.conf}} is not updated to reflect the 
> details of the Ambari Kerberos identity.
> This was introduced by the patch for AMBARI-18406.



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

[jira] [Updated] (AMBARI-17909) AMS Storm Sink: apply change of Storm metrics improvement - worker level aggregation

[Aravindan Vijayan (JIRA)]

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

Aravindan Vijayan updated AMBARI-17909:
---
Fix Version/s: 2.4.0

> AMS Storm Sink: apply change of Storm metrics improvement - worker level 
> aggregation
> 
>
> Key: AMBARI-17909
> URL: https://issues.apache.org/jira/browse/AMBARI-17909
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.4.0
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>Priority: Blocker
> Fix For: 2.4.0
>
> Attachments: AMBARI-17909-v1.patch, AMBARI-17909-v2.patch
>
>
> Abstraction:
> This issue is for following up changes on STORM-2006: Storm metrics feature 
> improvement: support per-worker level metrics aggregation.
> Details:
> With recent patches for AMS and AMS Storm sink, AMS stores task level metrics 
> from Storm, and relevant dashboards can be configured via Grafana.
> But we found that it incurs too many kinds of metrics and also too many data 
> points published to AMS because even a topology can have lots of tasks.
> In order to reduce this, I addressed STORM-2006, but it also needs AMS Storm 
> sink and relevant Storm configurations to be changed.



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

[jira] [Commented] (AMBARI-18506) Ambari should present message if stack upgrade path is not available

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18506:
-

SUCCESS: Integrated in Jenkins build Ambari-branch-2.5 #105 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/105/])
AMBARI-18506 Ambari should present message if stack upgrade path is not 
(atkach: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=1ca575d60f66ed872d78defed5be5532815517fc])
* (edit) ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js
* (add) ambari-web/test/mappers/repository_version_mapper_test.js
* (edit) ambari-web/app/models/stack_version/repository_version.js
* (edit) 
ambari-web/test/controllers/main/admin/stack_and_upgrade_controller_test.js
* (edit) 
ambari-web/app/templates/main/admin/stack_upgrade/upgrade_version_column.hbs
* (edit) 
ambari-web/app/views/main/admin/stack_upgrade/upgrade_version_box_view.js
* (edit) ambari-web/app/assets/test/tests.js
* (edit) 
ambari-web/app/templates/main/admin/stack_upgrade/upgrade_version_box.hbs
* (edit) 
ambari-web/app/views/main/admin/stack_upgrade/upgrade_version_column_view.js
* (edit) ambari-web/app/mappers/repository_version_mapper.js
* (edit) 
ambari-web/test/views/main/admin/stack_upgrade/upgrade_version_box_view_test.js
* (edit) ambari-web/app/utils/ajax/ajax.js
* (edit) ambari-web/app/messages.js


> Ambari should present message if stack upgrade path is not available
> 
>
> Key: AMBARI-18506
> URL: https://issues.apache.org/jira/browse/AMBARI-18506
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 2.5.0
>
> Attachments: AMBARI-18506.patch
>
>
> After adding a new stack version to Ambari and selecting it to be installed 
> on a specific cluster, the UI changes to the cluster versions page. If the 
> upgrade path (aka the upgrade pack) is not available for the transition from 
> the current stack version to the new stack version then the selected version 
> is not seen on that next screen. This transition is silent leaving the user 
> confused as to where the version went.
> For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2.



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

[jira] [Commented] (AMBARI-18506) Ambari should present message if stack upgrade path is not available

[Hudson (JIRA)]

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

Hudson commented on AMBARI-18506:
-

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5756 (See 
[https://builds.apache.org/job/Ambari-trunk-Commit/5756/])
AMBARI-18506 Ambari should present message if stack upgrade path is not 
(atkach: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=269494849cad6d0a56dddaf52316e1d84b08d49f])
* (edit) ambari-web/app/models/stack_version/repository_version.js
* (edit) 
ambari-web/app/templates/main/admin/stack_upgrade/upgrade_version_column.hbs
* (edit) 
ambari-web/app/views/main/admin/stack_upgrade/upgrade_version_column_view.js
* (edit) ambari-web/app/messages.js
* (add) ambari-web/test/mappers/repository_version_mapper_test.js
* (edit) ambari-web/app/assets/test/tests.js
* (edit) ambari-web/app/utils/ajax/ajax.js
* (edit) ambari-web/app/mappers/repository_version_mapper.js
* (edit) ambari-web/app/controllers/main/admin/stack_and_upgrade_controller.js
* (edit) 
ambari-web/test/views/main/admin/stack_upgrade/upgrade_version_box_view_test.js
* (edit) 
ambari-web/test/controllers/main/admin/stack_and_upgrade_controller_test.js
* (edit) 
ambari-web/app/views/main/admin/stack_upgrade/upgrade_version_box_view.js
* (edit) 
ambari-web/app/templates/main/admin/stack_upgrade/upgrade_version_box.hbs


> Ambari should present message if stack upgrade path is not available
> 
>
> Key: AMBARI-18506
> URL: https://issues.apache.org/jira/browse/AMBARI-18506
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 2.5.0
>
> Attachments: AMBARI-18506.patch
>
>
> After adding a new stack version to Ambari and selecting it to be installed 
> on a specific cluster, the UI changes to the cluster versions page. If the 
> upgrade path (aka the upgrade pack) is not available for the transition from 
> the current stack version to the new stack version then the selected version 
> is not seen on that next screen. This transition is silent leaving the user 
> confused as to where the version went.
> For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2.



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

[jira] [Commented] (AMBARI-18524) Kafka widget update needs UpgradeCatalog handling.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on AMBARI-18524:


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

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

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

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

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

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

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

This message is automatically generated.

> Kafka widget update needs UpgradeCatalog handling.
> --
>
> Key: AMBARI-18524
> URL: https://issues.apache.org/jira/browse/AMBARI-18524
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18524.patch
>
>
> The widgets for "Active Controller Count" and "Replica Manager" on the Kafka 
> service page show incorrect values when more than 1 Kafka Brokers exist. This 
> was fixed via   AMBARI-18485  but it will need UpgradeCatalog handling.



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

[jira] [Updated] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-18526:

Affects Version/s: 2.4.0

> Ambari breaks sudo and user access if Ambari Agent misconfigured
> 
>
> Key: AMBARI-18526
> URL: https://issues.apache.org/jira/browse/AMBARI-18526
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.5.0
>
> Attachments: AMBARI-18526.patch
>
>
> While working on Ambari installation using Vagrant I found following issues 
> that can be potentially dangerous and destroy sudo and /home permissions
> Steps to reproduce:
> Remove or misconfigure following configs from ambari-agent.ini file:
> {code}
> [agent]
> logdir=/var/log/ambari-agent
> piddir=/var/run/ambari-agent
> {code}
> Start ambari agent.  Note that log, pid, and out want to be written to /.  
> Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
> user will not be able to connect to cluster using private key due to 
> permissions and folder ownership switch to root.
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# ambari-agent start
> chown: changing ownership of `/proc/12937': Operation not permitted
> chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
> chown: changing ownership of `/proc/12938': Operation not permitted
> chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
> chown: changing ownership of `/proc/12941': Operation not permitted
> chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
> directory
> chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file 
> or directory
> chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
> chown: changing ownership of `/proc/12942/fd/4': No such file or directory
> chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
> chown: changing ownership of `/proc/12942': Operation not permitted
> Starting ambari-agent
> Verifying ambari-agent process status...
> Ambari Agent successfully started
> Agent PID at: /ambari-agent.pid
> Agent out at: /ambari-agent.out
> Agent log at: /ambari-agent.log
> {code}
> Sticky bit is removed from sudo as result of it
> {code}
> [root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
> ---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> it should be:
> {code}
> [root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
> ---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> All user folder is messed up as owned by root
> {code}
> [root@ambari-slave1 vagrant]# ls -ld /home/
> drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/
> [root@ambari-slave1 vagrant]# ls -ld /home/vagrant
> drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
> {code}
> sudo is broken:
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# exit
> exit
> [vagrant@ambari-slave1 ~]$ sudo su
> sudo: effective uid is not 0, is sudo installed setuid root?
> {code}
> this is caused due to by function in /usr/sbin/ambari-agent
> {code}
> get_agent_property() {
> property_name="$1"
> value=$(awk -F "=" "/$property_name/ {print \$2}" 
> /etc/ambari-agent/conf/ambari-agent.ini)
> echo $value
> }
> {code}



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

[jira] [Updated] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-18526:

Fix Version/s: 2.5.0

> Ambari breaks sudo and user access if Ambari Agent misconfigured
> 
>
> Key: AMBARI-18526
> URL: https://issues.apache.org/jira/browse/AMBARI-18526
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Fix For: 2.5.0
>
> Attachments: AMBARI-18526.patch
>
>
> While working on Ambari installation using Vagrant I found following issues 
> that can be potentially dangerous and destroy sudo and /home permissions
> Steps to reproduce:
> Remove or misconfigure following configs from ambari-agent.ini file:
> {code}
> [agent]
> logdir=/var/log/ambari-agent
> piddir=/var/run/ambari-agent
> {code}
> Start ambari agent.  Note that log, pid, and out want to be written to /.  
> Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
> user will not be able to connect to cluster using private key due to 
> permissions and folder ownership switch to root.
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# ambari-agent start
> chown: changing ownership of `/proc/12937': Operation not permitted
> chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
> chown: changing ownership of `/proc/12938': Operation not permitted
> chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
> chown: changing ownership of `/proc/12941': Operation not permitted
> chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
> directory
> chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file 
> or directory
> chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
> chown: changing ownership of `/proc/12942/fd/4': No such file or directory
> chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
> chown: changing ownership of `/proc/12942': Operation not permitted
> Starting ambari-agent
> Verifying ambari-agent process status...
> Ambari Agent successfully started
> Agent PID at: /ambari-agent.pid
> Agent out at: /ambari-agent.out
> Agent log at: /ambari-agent.log
> {code}
> Sticky bit is removed from sudo as result of it
> {code}
> [root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
> ---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> it should be:
> {code}
> [root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
> ---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> All user folder is messed up as owned by root
> {code}
> [root@ambari-slave1 vagrant]# ls -ld /home/
> drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/
> [root@ambari-slave1 vagrant]# ls -ld /home/vagrant
> drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
> {code}
> sudo is broken:
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# exit
> exit
> [vagrant@ambari-slave1 ~]$ sudo su
> sudo: effective uid is not 0, is sudo installed setuid root?
> {code}
> this is caused due to by function in /usr/sbin/ambari-agent
> {code}
> get_agent_property() {
> property_name="$1"
> value=$(awk -F "=" "/$property_name/ {print \$2}" 
> /etc/ambari-agent/conf/ambari-agent.ini)
> echo $value
> }
> {code}



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

[jira] [Updated] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-18526:

Attachment: AMBARI-18526.patch

> Ambari breaks sudo and user access if Ambari Agent misconfigured
> 
>
> Key: AMBARI-18526
> URL: https://issues.apache.org/jira/browse/AMBARI-18526
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-18526.patch
>
>
> While working on Ambari installation using Vagrant I found following issues 
> that can be potentially dangerous and destroy sudo and /home permissions
> Steps to reproduce:
> Remove or misconfigure following configs from ambari-agent.ini file:
> {code}
> [agent]
> logdir=/var/log/ambari-agent
> piddir=/var/run/ambari-agent
> {code}
> Start ambari agent.  Note that log, pid, and out want to be written to /.  
> Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
> user will not be able to connect to cluster using private key due to 
> permissions and folder ownership switch to root.
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# ambari-agent start
> chown: changing ownership of `/proc/12937': Operation not permitted
> chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
> chown: changing ownership of `/proc/12938': Operation not permitted
> chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
> chown: changing ownership of `/proc/12941': Operation not permitted
> chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
> directory
> chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file 
> or directory
> chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
> chown: changing ownership of `/proc/12942/fd/4': No such file or directory
> chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
> chown: changing ownership of `/proc/12942': Operation not permitted
> Starting ambari-agent
> Verifying ambari-agent process status...
> Ambari Agent successfully started
> Agent PID at: /ambari-agent.pid
> Agent out at: /ambari-agent.out
> Agent log at: /ambari-agent.log
> {code}
> Sticky bit is removed from sudo as result of it
> {code}
> [root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
> ---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> it should be:
> {code}
> [root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
> ---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> All user folder is messed up as owned by root
> {code}
> [root@ambari-slave1 vagrant]# ls -ld /home/
> drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/
> [root@ambari-slave1 vagrant]# ls -ld /home/vagrant
> drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
> {code}
> sudo is broken:
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# exit
> exit
> [vagrant@ambari-slave1 ~]$ sudo su
> sudo: effective uid is not 0, is sudo installed setuid root?
> {code}
> this is caused due to by function in /usr/sbin/ambari-agent
> {code}
> get_agent_property() {
> property_name="$1"
> value=$(awk -F "=" "/$property_name/ {print \$2}" 
> /etc/ambari-agent/conf/ambari-agent.ini)
> echo $value
> }
> {code}



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

[jira] [Updated] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-18526:

Component/s: ambari-server

> Ambari breaks sudo and user access if Ambari Agent misconfigured
> 
>
> Key: AMBARI-18526
> URL: https://issues.apache.org/jira/browse/AMBARI-18526
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-18526.patch
>
>
> While working on Ambari installation using Vagrant I found following issues 
> that can be potentially dangerous and destroy sudo and /home permissions
> Steps to reproduce:
> Remove or misconfigure following configs from ambari-agent.ini file:
> {code}
> [agent]
> logdir=/var/log/ambari-agent
> piddir=/var/run/ambari-agent
> {code}
> Start ambari agent.  Note that log, pid, and out want to be written to /.  
> Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
> user will not be able to connect to cluster using private key due to 
> permissions and folder ownership switch to root.
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# ambari-agent start
> chown: changing ownership of `/proc/12937': Operation not permitted
> chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
> chown: changing ownership of `/proc/12938': Operation not permitted
> chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
> chown: changing ownership of `/proc/12941': Operation not permitted
> chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
> directory
> chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file 
> or directory
> chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
> chown: changing ownership of `/proc/12942/fd/4': No such file or directory
> chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
> chown: changing ownership of `/proc/12942': Operation not permitted
> Starting ambari-agent
> Verifying ambari-agent process status...
> Ambari Agent successfully started
> Agent PID at: /ambari-agent.pid
> Agent out at: /ambari-agent.out
> Agent log at: /ambari-agent.log
> {code}
> Sticky bit is removed from sudo as result of it
> {code}
> [root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
> ---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> it should be:
> {code}
> [root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
> ---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> All user folder is messed up as owned by root
> {code}
> [root@ambari-slave1 vagrant]# ls -ld /home/
> drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/
> [root@ambari-slave1 vagrant]# ls -ld /home/vagrant
> drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
> {code}
> sudo is broken:
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# exit
> exit
> [vagrant@ambari-slave1 ~]$ sudo su
> sudo: effective uid is not 0, is sudo installed setuid root?
> {code}
> this is caused due to by function in /usr/sbin/ambari-agent
> {code}
> get_agent_property() {
> property_name="$1"
> value=$(awk -F "=" "/$property_name/ {print \$2}" 
> /etc/ambari-agent/conf/ambari-agent.ini)
> echo $value
> }
> {code}



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

[jira] [Created] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

Dmitry Lysnichenko created AMBARI-18526:
---

 Summary: Ambari breaks sudo and user access if Ambari Agent 
misconfigured
 Key: AMBARI-18526
 URL: https://issues.apache.org/jira/browse/AMBARI-18526
 Project: Ambari
  Issue Type: Bug
Reporter: Dmitry Lysnichenko
Assignee: Dmitry Lysnichenko
 Attachments: AMBARI-18526.patch


While working on Ambari installation using Vagrant I found following issues 
that can be potentially dangerous and destroy sudo and /home permissions

Steps to reproduce:

Remove or misconfigure following configs from ambari-agent.ini file:
{code}
[agent]
logdir=/var/log/ambari-agent
piddir=/var/run/ambari-agent
{code}

Start ambari agent.  Note that log, pid, and out want to be written to /.  
Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
user will not be able to connect to cluster using private key due to 
permissions and folder ownership switch to root.

{code}
[root@ambari-slave1 vagrant]# id
uid=0(root) gid=0(root) groups=0(root)

[root@ambari-slave1 vagrant]# ambari-agent start

chown: changing ownership of `/proc/12937': Operation not permitted
chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
chown: changing ownership of `/proc/12938': Operation not permitted
chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
chown: changing ownership of `/proc/12941': Operation not permitted
chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
directory
chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file or 
directory
chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
chown: changing ownership of `/proc/12942/fd/4': No such file or directory
chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
chown: changing ownership of `/proc/12942': Operation not permitted
Starting ambari-agent
Verifying ambari-agent process status...
Ambari Agent successfully started
Agent PID at: /ambari-agent.pid
Agent out at: /ambari-agent.out
Agent log at: /ambari-agent.log
{code}

Sticky bit is removed from sudo as result of it

{code}
[root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
{code}

it should be:

{code}
[root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
{code}

All user folder is messed up as owned by root

{code}
[root@ambari-slave1 vagrant]# ls -ld /home/
drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/

[root@ambari-slave1 vagrant]# ls -ld /home/vagrant
drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
{code}

sudo is broken:

{code}
[root@ambari-slave1 vagrant]# id
uid=0(root) gid=0(root) groups=0(root)
[root@ambari-slave1 vagrant]# exit
exit
[vagrant@ambari-slave1 ~]$ sudo su
sudo: effective uid is not 0, is sudo installed setuid root?
{code}

this is caused due to by function in /usr/sbin/ambari-agent

{code}
get_agent_property() {
property_name="$1"
value=$(awk -F "=" "/$property_name/ {print \$2}" 
/etc/ambari-agent/conf/ambari-agent.ini)
echo $value
}
{code}




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

[jira] [Updated] (AMBARI-18526) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

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

Dmitry Lysnichenko updated AMBARI-18526:

Status: Patch Available  (was: Open)

> Ambari breaks sudo and user access if Ambari Agent misconfigured
> 
>
> Key: AMBARI-18526
> URL: https://issues.apache.org/jira/browse/AMBARI-18526
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Dmitry Lysnichenko
>Assignee: Dmitry Lysnichenko
> Attachments: AMBARI-18526.patch
>
>
> While working on Ambari installation using Vagrant I found following issues 
> that can be potentially dangerous and destroy sudo and /home permissions
> Steps to reproduce:
> Remove or misconfigure following configs from ambari-agent.ini file:
> {code}
> [agent]
> logdir=/var/log/ambari-agent
> piddir=/var/run/ambari-agent
> {code}
> Start ambari agent.  Note that log, pid, and out want to be written to /.  
> Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
> user will not be able to connect to cluster using private key due to 
> permissions and folder ownership switch to root.
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# ambari-agent start
> chown: changing ownership of `/proc/12937': Operation not permitted
> chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
> chown: changing ownership of `/proc/12938': Operation not permitted
> chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
> chown: changing ownership of `/proc/12941': Operation not permitted
> chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
> directory
> chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file 
> or directory
> chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
> chown: changing ownership of `/proc/12942/fd/4': No such file or directory
> chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
> chown: changing ownership of `/proc/12942': Operation not permitted
> Starting ambari-agent
> Verifying ambari-agent process status...
> Ambari Agent successfully started
> Agent PID at: /ambari-agent.pid
> Agent out at: /ambari-agent.out
> Agent log at: /ambari-agent.log
> {code}
> Sticky bit is removed from sudo as result of it
> {code}
> [root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
> ---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> it should be:
> {code}
> [root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
> ---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
> {code}
> All user folder is messed up as owned by root
> {code}
> [root@ambari-slave1 vagrant]# ls -ld /home/
> drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/
> [root@ambari-slave1 vagrant]# ls -ld /home/vagrant
> drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
> {code}
> sudo is broken:
> {code}
> [root@ambari-slave1 vagrant]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@ambari-slave1 vagrant]# exit
> exit
> [vagrant@ambari-slave1 ~]$ sudo su
> sudo: effective uid is not 0, is sudo installed setuid root?
> {code}
> this is caused due to by function in /usr/sbin/ambari-agent
> {code}
> get_agent_property() {
> property_name="$1"
> value=$(awk -F "=" "/$property_name/ {print \$2}" 
> /etc/ambari-agent/conf/ambari-agent.ini)
> echo $value
> }
> {code}



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

[jira] [Created] (AMBARI-18525) Ambari breaks sudo and user access if Ambari Agent misconfigured

[Dmitry Lysnichenko (JIRA)]

Dmitry Lysnichenko created AMBARI-18525:
---

 Summary: Ambari breaks sudo and user access if Ambari Agent 
misconfigured
 Key: AMBARI-18525
 URL: https://issues.apache.org/jira/browse/AMBARI-18525
 Project: Ambari
  Issue Type: Bug
Reporter: Dmitry Lysnichenko
Assignee: Dmitry Lysnichenko



While working on Ambari installation using Vagrant I found following issues 
that can be potentially dangerous and destroy sudo and /home permissions

Steps to reproduce:

Remove or misconfigure following configs from ambari-agent.ini file:
{code}
[agent]
logdir=/var/log/ambari-agent
piddir=/var/run/ambari-agent
{code}

Start ambari agent.  Note that log, pid, and out want to be written to /.  
Everything fails and sudo is destroyed as well as /home for all users.  Sudo 
user will not be able to connect to cluster using private key due to 
permissions and folder ownership switch to root.

{code}
[root@ambari-slave1 vagrant]# id
uid=0(root) gid=0(root) groups=0(root)

[root@ambari-slave1 vagrant]# ambari-agent start

chown: changing ownership of `/proc/12937': Operation not permitted
chown: changing ownership of `/proc/12938/task/12938': Operation not permitted
chown: changing ownership of `/proc/12938': Operation not permitted
chown: changing ownership of `/proc/12941/task/12941': Operation not permitted
chown: changing ownership of `/proc/12941': Operation not permitted
chown: changing ownership of `/proc/12942/task/12942/fd/4': No such file or 
directory
chown: changing ownership of `/proc/12942/task/12942/fdinfo/4': No such file or 
directory
chown: changing ownership of `/proc/12942/task/12942': Operation not permitted
chown: changing ownership of `/proc/12942/fd/4': No such file or directory
chown: changing ownership of `/proc/12942/fdinfo/4': No such file or directory
chown: changing ownership of `/proc/12942': Operation not permitted
Starting ambari-agent
Verifying ambari-agent process status...
Ambari Agent successfully started
Agent PID at: /ambari-agent.pid
Agent out at: /ambari-agent.out
Agent log at: /ambari-agent.log
{code}

Sticky bit is removed from sudo as result of it

{code}
[root@ambari-slave1 vagrant]# ls -l /usr/bin/sudo
---x--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
{code}

it should be:

{code}
[root@ambari-slave2 vagrant]# ls -l /usr/bin/sudo
---s--x--x. 1 root root 123832 Oct 15  2014 /usr/bin/sudo
{code}

All user folder is messed up as owned by root

{code}
[root@ambari-slave1 vagrant]# ls -ld /home/
drwxr-xr-x. 3 root root 4096 Mar  9  2016 /home/

[root@ambari-slave1 vagrant]# ls -ld /home/vagrant
drwx-- 3 root root 4096 Sep 27 22:16 /home/vagrant
{code}

sudo is broken:

{code}
[root@ambari-slave1 vagrant]# id
uid=0(root) gid=0(root) groups=0(root)
[root@ambari-slave1 vagrant]# exit
exit
[vagrant@ambari-slave1 ~]$ sudo su
sudo: effective uid is not 0, is sudo installed setuid root?
{code}

this is caused due to by function in /usr/sbin/ambari-agent

{code}
get_agent_property() {
property_name="$1"
value=$(awk -F "=" "/$property_name/ {print \$2}" 
/etc/ambari-agent/conf/ambari-agent.ini)
echo $value
}
{code}




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

[jira] [Updated] (AMBARI-18506) Ambari should present message if stack upgrade path is not available

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-18506:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Ambari should present message if stack upgrade path is not available
> 
>
> Key: AMBARI-18506
> URL: https://issues.apache.org/jira/browse/AMBARI-18506
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 2.5.0
>
> Attachments: AMBARI-18506.patch
>
>
> After adding a new stack version to Ambari and selecting it to be installed 
> on a specific cluster, the UI changes to the cluster versions page. If the 
> upgrade path (aka the upgrade pack) is not available for the transition from 
> the current stack version to the new stack version then the selected version 
> is not seen on that next screen. This transition is silent leaving the user 
> confused as to where the version went.
> For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2.



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

[jira] [Commented] (AMBARI-18506) Ambari should present message if stack upgrade path is not available

[Andrii Tkach (JIRA)]

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

Andrii Tkach commented on AMBARI-18506:
---

committed to trunk and branch-2.5

> Ambari should present message if stack upgrade path is not available
> 
>
> Key: AMBARI-18506
> URL: https://issues.apache.org/jira/browse/AMBARI-18506
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 2.5.0
>
> Attachments: AMBARI-18506.patch
>
>
> After adding a new stack version to Ambari and selecting it to be installed 
> on a specific cluster, the UI changes to the cluster versions page. If the 
> upgrade path (aka the upgrade pack) is not available for the transition from 
> the current stack version to the new stack version then the selected version 
> is not seen on that next screen. This transition is silent leaving the user 
> confused as to where the version went.
> For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2.



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

[jira] [Updated] (AMBARI-18506) Ambari should present message if stack upgrade path is not available

[Andrii Tkach (JIRA)]

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

Andrii Tkach updated AMBARI-18506:
--
Fix Version/s: (was: 2.4.2)
   2.5.0

> Ambari should present message if stack upgrade path is not available
> 
>
> Key: AMBARI-18506
> URL: https://issues.apache.org/jira/browse/AMBARI-18506
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.4.0
>Reporter: Andrii Tkach
>Assignee: Andrii Tkach
> Fix For: 2.5.0
>
> Attachments: AMBARI-18506.patch
>
>
> After adding a new stack version to Ambari and selecting it to be installed 
> on a specific cluster, the UI changes to the cluster versions page. If the 
> upgrade path (aka the upgrade pack) is not available for the transition from 
> the current stack version to the new stack version then the selected version 
> is not seen on that next screen. This transition is silent leaving the user 
> confused as to where the version went.
> For example: Adding HDP 2.5 to a cluster where the current stack is HDP 2.2.



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

[jira] [Updated] (AMBARI-18524) Kafka widget update needs UpgradeCatalog handling.

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-18524:

Attachment: AMBARI-18524.patch

> Kafka widget update needs UpgradeCatalog handling.
> --
>
> Key: AMBARI-18524
> URL: https://issues.apache.org/jira/browse/AMBARI-18524
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18524.patch
>
>
> The widgets for "Active Controller Count" and "Replica Manager" on the Kafka 
> service page show incorrect values when more than 1 Kafka Brokers exist. This 
> was fixed via   AMBARI-18485  but it will need UpgradeCatalog handling.



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

[jira] [Updated] (AMBARI-18524) Kafka widget update needs UpgradeCatalog handling.

[Dmytro Sen (JIRA)]

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

Dmytro Sen updated AMBARI-18524:

Status: Patch Available  (was: Open)

> Kafka widget update needs UpgradeCatalog handling.
> --
>
> Key: AMBARI-18524
> URL: https://issues.apache.org/jira/browse/AMBARI-18524
> Project: Ambari
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Dmytro Sen
>Assignee: Dmytro Sen
>Priority: Critical
> Fix For: 2.4.2
>
> Attachments: AMBARI-18524.patch
>
>
> The widgets for "Active Controller Count" and "Replica Manager" on the Kafka 
> service page show incorrect values when more than 1 Kafka Brokers exist. This 
> was fixed via   AMBARI-18485  but it will need UpgradeCatalog handling.



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

[jira] [Created] (AMBARI-18524) Kafka widget update needs UpgradeCatalog handling.

[Dmytro Sen (JIRA)]

Dmytro Sen created AMBARI-18524:
---

 Summary: Kafka widget update needs UpgradeCatalog handling.
 Key: AMBARI-18524
 URL: https://issues.apache.org/jira/browse/AMBARI-18524
 Project: Ambari
  Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Dmytro Sen
Assignee: Dmytro Sen
Priority: Critical
 Fix For: 2.4.2


The widgets for "Active Controller Count" and "Replica Manager" on the Kafka 
service page show incorrect values when more than 1 Kafka Brokers exist. This 
was fixed via   AMBARI-18485  but it will need UpgradeCatalog handling.



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

[jira] [Updated] (AMBARI-18516) Add ability to have services declare itself as tech-preview or mandatory

[Vitaly Brodetskyi (JIRA)]

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

Vitaly Brodetskyi updated AMBARI-18516:
---
Attachment: (was: AMBARI-18516.patch)

> Add ability to have services declare itself as tech-preview or mandatory
> 
>
> Key: AMBARI-18516
> URL: https://issues.apache.org/jira/browse/AMBARI-18516
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Vitaly Brodetskyi
>Assignee: Vitaly Brodetskyi
>Priority: Critical
> Fix For: 2.5.0
>
>
> When a service is added to a stack, it should be identified as:
> default/regular - service is optional on the cluster, UI usually shows it as
> tech-preview - service may be deployed, UI will not auto-select these 
> services and mark them as TechPreview
> mandatory - service need to be deployed and all deployment should fail is the 
> service is not selected during deployment
> Lets create a proposal of what changes are needed in the services' 
> metainfo.xml? Note that a service can change its attribute between stack 
> versions - e.g. move from "tech-preview" to "mandatory".



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

[jira] [Updated] (AMBARI-18522) Add Service wizard breaks on large clusters when persisting data in localStorage

[Andrii Babiichuk (JIRA)]

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

Andrii Babiichuk updated AMBARI-18522:
--
Status: Patch Available  (was: Open)

  29527 tests complete (25 seconds)
  154 tests pending


> Add Service wizard breaks on large clusters when persisting data in 
> localStorage
> 
>
> Key: AMBARI-18522
> URL: https://issues.apache.org/jira/browse/AMBARI-18522
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18522.patch
>
>
> Trying to navigate to Assign Masters page or Review page generates JS error 
> with "next" button disabled.



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

[jira] [Updated] (AMBARI-18522) Add Service wizard breaks on large clusters when persisting data in localStorage

[Andrii Babiichuk (JIRA)]

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

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

> Add Service wizard breaks on large clusters when persisting data in 
> localStorage
> 
>
> Key: AMBARI-18522
> URL: https://issues.apache.org/jira/browse/AMBARI-18522
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.2.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18522.patch
>
>
> Trying to navigate to Assign Masters page or Review page generates JS error 
> with "next" button disabled.



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

[jira] [Updated] (AMBARI-18523) LogSearch Portal: Use "enabled" suffix instead of "enable" for auth properties

[JIRA]

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

Olivér Szabó updated AMBARI-18523:
--
Attachment: AMBARI-18523.patch

> LogSearch Portal: Use "enabled" suffix instead of "enable" for auth properties
> --
>
> Key: AMBARI-18523
> URL: https://issues.apache.org/jira/browse/AMBARI-18523
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-logsearch
>Affects Versions: 2.4.0
>Reporter: Olivér Szabó
>Assignee: Olivér Szabó
> Fix For: 2.5.0
>
> Attachments: AMBARI-18523.patch
>
>




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

[jira] [Created] (AMBARI-18523) LogSearch Portal: Use "enabled" suffix instead of "enable" for auth properties

[JIRA]

Olivér Szabó created AMBARI-18523:
-

 Summary: LogSearch Portal: Use "enabled" suffix instead of 
"enable" for auth properties
 Key: AMBARI-18523
 URL: https://issues.apache.org/jira/browse/AMBARI-18523
 Project: Ambari
  Issue Type: Bug
  Components: ambari-logsearch
Affects Versions: 2.4.0
Reporter: Olivér Szabó
Assignee: Olivér Szabó
 Fix For: 2.5.0






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

[jira] [Created] (AMBARI-18522) Add Service wizard breaks on large clusters when persisting data in localStorage

[Andrii Babiichuk (JIRA)]

Andrii Babiichuk created AMBARI-18522:
-

 Summary: Add Service wizard breaks on large clusters when 
persisting data in localStorage
 Key: AMBARI-18522
 URL: https://issues.apache.org/jira/browse/AMBARI-18522
 Project: Ambari
  Issue Type: Bug
  Components: ambari-web
Affects Versions: 2.2.2
Reporter: Andrii Babiichuk
Assignee: Andrii Babiichuk
Priority: Blocker
 Fix For: 2.4.2


Trying to navigate to Assign Masters page or Review page generates JS error 
with "next" button disabled.



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

[jira] [Updated] (AMBARI-18521) Stack upgrade fix for Ranger in secure env

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-18521:
-
Description: 
Stack changes required while upgrading to 2.5 in secure env
* Remove adding spnego principal value to 
ranger-admin-site/ranger.spnego.kerberos.principal
* Get storm principal bare name and update it accordingly to 
ranger-admin-site.xml/ranger.plugins.storm.serviceuser

  was:
Stack changes required while upgrading to 2.4 in secure env
* Remove adding spnego principal value to 
ranger-admin-site/ranger.spnego.kerberos.principal
* Get storm principal bare name and update it accordingly to 
ranger-admin-site.xml/ranger.plugins.storm.serviceuser


> Stack upgrade fix for Ranger in secure env
> --
>
> Key: AMBARI-18521
> URL: https://issues.apache.org/jira/browse/AMBARI-18521
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18521.patch
>
>
> Stack changes required while upgrading to 2.5 in secure env
> * Remove adding spnego principal value to 
> ranger-admin-site/ranger.spnego.kerberos.principal
> * Get storm principal bare name and update it accordingly to 
> ranger-admin-site.xml/ranger.plugins.storm.serviceuser



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

[jira] [Updated] (AMBARI-18521) Stack upgrade fix for Ranger in secure env

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-18521:
-
Description: 
Stack changes required while upgrading to 2.4 in secure env
* Remove adding spnego principal value to 
ranger-admin-site/ranger.spnego.kerberos.principal
* Get storm principal bare name and update it accordingly to 
ranger-admin-site.xml/ranger.plugins.storm.serviceuser

  was:
Stack changes required while upgrading to 2.4 in secure env
* Remove adding spnego principal value to 
ranger-admin-site/ranger.spnego.kerberos.principal
* Calculate storm principal and update it accordingly


> Stack upgrade fix for Ranger in secure env
> --
>
> Key: AMBARI-18521
> URL: https://issues.apache.org/jira/browse/AMBARI-18521
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18521.patch
>
>
> Stack changes required while upgrading to 2.4 in secure env
> * Remove adding spnego principal value to 
> ranger-admin-site/ranger.spnego.kerberos.principal
> * Get storm principal bare name and update it accordingly to 
> ranger-admin-site.xml/ranger.plugins.storm.serviceuser



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

[jira] [Updated] (AMBARI-18521) Stack upgrade fix for Ranger in secure env

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-18521:
-
Attachment: AMBARI-18521.patch

> Stack upgrade fix for Ranger in secure env
> --
>
> Key: AMBARI-18521
> URL: https://issues.apache.org/jira/browse/AMBARI-18521
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18521.patch
>
>
> Stack changes required while upgrading to 2.4 in secure env
> * Remove adding spnego principal value to 
> ranger-admin-site/ranger.spnego.kerberos.principal
> * Calculate storm principal and update it accordingly



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

[jira] [Updated] (AMBARI-18521) Stack upgrade fix for Ranger in secure env

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-18521:
-
Status: Patch Available  (was: In Progress)

> Stack upgrade fix for Ranger in secure env
> --
>
> Key: AMBARI-18521
> URL: https://issues.apache.org/jira/browse/AMBARI-18521
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
> Attachments: AMBARI-18521.patch
>
>
> Stack changes required while upgrading to 2.4 in secure env
> * Remove adding spnego principal value to 
> ranger-admin-site/ranger.spnego.kerberos.principal
> * Calculate storm principal and update it accordingly



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

[jira] [Updated] (AMBARI-18521) Stack upgrade fix for Ranger in secure env

[Mugdha Varadkar (JIRA)]

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

Mugdha Varadkar updated AMBARI-18521:
-
Summary: Stack upgrade fix for Ranger in secure env  (was: Ranger upgrade 
fix from stack 2.4 to 2.5 in secure env)

> Stack upgrade fix for Ranger in secure env
> --
>
> Key: AMBARI-18521
> URL: https://issues.apache.org/jira/browse/AMBARI-18521
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Critical
> Fix For: 2.5.0, 2.4.2
>
>
> Stack changes required while upgrading to 2.4 in secure env
> * Remove adding spnego principal value to 
> ranger-admin-site/ranger.spnego.kerberos.principal
> * Calculate storm principal and update it accordingly



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

[jira] [Created] (AMBARI-18521) Ranger upgrade fix from stack 2.4 to 2.5 in secure env

[Mugdha Varadkar (JIRA)]

Mugdha Varadkar created AMBARI-18521:


 Summary: Ranger upgrade fix from stack 2.4 to 2.5 in secure env
 Key: AMBARI-18521
 URL: https://issues.apache.org/jira/browse/AMBARI-18521
 Project: Ambari
  Issue Type: Bug
  Components: ambari-server
Affects Versions: 2.4.0, 2.4.1
Reporter: Mugdha Varadkar
Assignee: Mugdha Varadkar
Priority: Critical
 Fix For: 2.5.0, 2.4.2


Stack changes required while upgrading to 2.4 in secure env
* Remove adding spnego principal value to 
ranger-admin-site/ranger.spnego.kerberos.principal
* Calculate storm principal and update it accordingly



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