[jira] [Updated] (AMBARI-16214) Ensure Blueprint deployment can start immediately - after Server start
[ https://issues.apache.org/jira/browse/AMBARI-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-16214: -- Description: * Blueprint may be provided during cluster start up (no need for a REST API call). (was: * Blueprint deployment should only wait for headnodes/zknodes * Blueprint may be provided during cluster start up (no need for a REST API call).) > Ensure Blueprint deployment can start immediately - after Server start > -- > > Key: AMBARI-16214 > URL: https://issues.apache.org/jira/browse/AMBARI-16214 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Sandor Magyari > Fix For: 2.4.1 > > > * Blueprint may be provided during cluster start up (no need for a REST API > call). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16214) Ensure Blueprint deployment can start immediately - after Server start
[ https://issues.apache.org/jira/browse/AMBARI-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-16214: -- Assignee: Sandor Magyari > Ensure Blueprint deployment can start immediately - after Server start > -- > > Key: AMBARI-16214 > URL: https://issues.apache.org/jira/browse/AMBARI-16214 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Sandor Magyari > Fix For: 2.4.1 > > > * Blueprint deployment should only wait for headnodes/zknodes > * Blueprint may be provided during cluster start up (no need for a REST API > call). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16220) No INSTALL commands
[ https://issues.apache.org/jira/browse/AMBARI-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-16220: -- Assignee: Sandor Magyari > No INSTALL commands > --- > > Key: AMBARI-16220 > URL: https://issues.apache.org/jira/browse/AMBARI-16220 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Sandor Magyari > Fix For: 2.4.1 > > > Get rid of install commands. Currently, install commands are needed for two > purposes: > * Satisfy the state transition requirements > * Install clients (HDFS_CLIENT, HIVE_CLIENT, etc) > The first one is a simpler where the server can help auto transition to > INSTALLED and then issue START. The second one will require either issue > INSTALL command only for Client components or create a CONFIGURE command that > does the same for the Client components that can precede the Start commands. > It can go in as a stage in for the START tasks themselves. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16220) No INSTALL commands
[ https://issues.apache.org/jira/browse/AMBARI-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-16220: -- Fix Version/s: (was: 2.4.1) 2.5.0 > No INSTALL commands > --- > > Key: AMBARI-16220 > URL: https://issues.apache.org/jira/browse/AMBARI-16220 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Sandor Magyari > Fix For: 2.5.0 > > > In case packages.pre.installed=true is set in ambari.properties, Blueprint > based deployments will not create INSTALL commands for service components. > Normally START command should call configure, but we must ensure this is true > for all used components. For client components INSTALL will be still > generated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-17219) Removing and re-adding hosts makes database inconsitent
[ https://issues.apache.org/jira/browse/AMBARI-17219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader resolved AMBARI-17219. --- Resolution: Fixed Fix Version/s: (was: 2.5.0) (was: 2.2-next) > Removing and re-adding hosts makes database inconsitent > --- > > Key: AMBARI-17219 > URL: https://issues.apache.org/jira/browse/AMBARI-17219 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-17219_2.2-next.patch, > AMBARI-17219_trunk_branch-2.4.patch > > > When a host is removed, it is necessary to have all the components stopped > and removed, before the host itself can be deleted. > If a host component is not stopped, it is not allowed to be removed, so the > host itself cannot be removed. However if re-adding the host is tried, even > if it is still in the cluster, a row is inserted to topology_host_info table. > Multiple lines of the same host in that table is incorrect, so topology > validation fails. > Expected behaviour: if host is still in the cluster, a duplicate should not > be able to be persisted in any of the related tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.2-next, 2.5.0 > > Attachments: AMBARI-17248.trunk.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Status: Patch Available (was: In Progress) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.2-next, 2.5.0 > > Attachments: AMBARI-17248.trunk.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
Sebastian Toader created AMBARI-17248: - Summary: Reduce the idle time before first command from next stage is executed on a host Key: AMBARI-17248 URL: https://issues.apache.org/jira/browse/AMBARI-17248 Project: Ambari Issue Type: Improvement Components: ambari-agent, ambari-server Reporter: Sebastian Toader Assignee: Sebastian Toader Fix For: 2.2-next, 2.5.0 Commands to be executed by ambari-agents are being sent down by the server in the response message to agent heartbeat messages. The server processes the received heartbeat, it checks if there are next commands scheduled to be executed by ambari-agent and adds those to the heartbeat response for the ambari-agent. The server organises the commands that can be executed in parallel into stages. Ambari server ensures that only the commands of a single stage is scheduled to be executed by the agent and starts scheduling the commands of the next stage only after all commands of current stage has finished successfully. The processing of command status received with the heartbeat message happens asynchronously to heartbeat response in HeartBeatProcessor and ActionScheduler creation thus when the heartbeat response is created the commands for the next stage are not scheduled yet. This means that the next commands will be sent to agent only with the next heartbeat. Agents currently sends a heartbeat to the server on command a completion or at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 seconds if there are no commands to be executed. This means that when the server receives a heartbeat triggered by the completion of the last command from the current stage the server will send the commands for the next stage only 10 seconds later when the next heartbeat is received. This leads to agents spending considerable amount of time idle when there are multiple stages to be executed. Agents should heartbeat at a higher rate while there are still pending stages to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Fix Version/s: (was: 2.5.0) (was: 2.2-next) 2.4.0 > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.v2.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v2.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: (was: AMBARI-17248.trunk.patch) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v2.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-16216) Agent to respond immediately after command execution
[ https://issues.apache.org/jira/browse/AMBARI-16216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader resolved AMBARI-16216. --- Resolution: Not A Problem > Agent to respond immediately after command execution > > > Key: AMBARI-16216 > URL: https://issues.apache.org/jira/browse/AMBARI-16216 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Sebastian Toader > Fix For: 2.4.1 > > > Agent to respond immediately after command execution -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.v7.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v6.patch, AMBARI-17248.trunk.v7.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.v6.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v6.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: (was: AMBARI-17248.trunk.v5.patch) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v6.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: (was: AMBARI-17248.trunk.v6.patch) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v7.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17053) Add explicit ambari-server log line indicating cluster creation complete
[
https://issues.apache.org/jira/browse/AMBARI-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335546#comment-15335546
]
Sebastian Toader commented on AMBARI-17053:
---
Committed to trunk:
{code}
commit 438a3cec25798a4e0565fe7914a440c306362ec6
Author: Daniel Gergely
Date: Fri Jun 17 06:58:33 2016 +0200
AMBARI-17053. Add explicit ambari-server log line indicating cluster
creation complete. (Daniel Gergely via stoader)
{code}
Committed to branch-2.4:
{code}
commit 2f6d7fbc9637e9714ed30ae63be3f0e5b92583b7
Author: Daniel Gergely
Date: Fri Jun 17 06:58:33 2016 +0200
AMBARI-17053. Add explicit ambari-server log line indicating cluster
creation complete. (Daniel Gergely via stoader)
{code}
> Add explicit ambari-server log line indicating cluster creation complete
>
>
> Key: AMBARI-17053
> URL: https://issues.apache.org/jira/browse/AMBARI-17053
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0, 2.2-next
>
> Attachments: AMBARI-17053_2.2-next.patch,
> AMBARI-17053_branch-2.4_and_trunk.patch
>
>
> Add a log message to see when the cluster is ready to use (cluster creation
> finishes)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17053) Add explicit ambari-server log line indicating cluster creation complete
[ https://issues.apache.org/jira/browse/AMBARI-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17053: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Add explicit ambari-server log line indicating cluster creation complete > > > Key: AMBARI-17053 > URL: https://issues.apache.org/jira/browse/AMBARI-17053 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.4.0, 2.2-next > > Attachments: AMBARI-17053_2.2-next.patch, > AMBARI-17053_branch-2.4_and_trunk.patch > > > Add a log message to see when the cluster is ready to use (cluster creation > finishes) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.v5.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v5.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: (was: AMBARI-17248.trunk.v4.patch) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v5.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v7.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: (was: AMBARI-17248.trunk.v3.patch) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v4.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.v4.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v4.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: (was: AMBARI-17248.trunk.v2.patch) > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v3.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17248) Reduce the idle time before first command from next stage is executed on a host
[ https://issues.apache.org/jira/browse/AMBARI-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-17248: -- Attachment: AMBARI-17248.trunk.v3.patch > Reduce the idle time before first command from next stage is executed on a > host > --- > > Key: AMBARI-17248 > URL: https://issues.apache.org/jira/browse/AMBARI-17248 > Project: Ambari > Issue Type: Improvement > Components: ambari-agent, ambari-server >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-17248.trunk.v3.patch > > > Commands to be executed by ambari-agents are being sent down by the server in > the response message to agent heartbeat messages. > The server processes the received heartbeat, it checks if there are next > commands scheduled to be executed by ambari-agent and adds those to the > heartbeat response for the ambari-agent. > The server organises the commands that can be executed in parallel into > stages. Ambari server ensures that only the commands of a single stage is > scheduled to be executed by the agent and starts scheduling the commands of > the next stage only after all commands of current stage has finished > successfully. > The processing of command status received with the heartbeat message happens > asynchronously to heartbeat response in HeartBeatProcessor and > ActionScheduler creation thus when the heartbeat response is created the > commands for the next stage are not scheduled yet. This means that the next > commands will be sent to agent only with the next heartbeat. > Agents currently sends a heartbeat to the server on command a completion or > at a timeout = self.netutil.HEARTBEAT_IDDLE_INTERVAL_SEC – > self.netutil.MINIMUM_INTERVAL_BETWEEN_HEARTBEATS interval which is ~10 > seconds if there are no commands to be executed. > This means that when the server receives a heartbeat triggered by the > completion of the last command from the current stage the server will send > the commands for the next stage only 10 seconds later when the next heartbeat > is received. This leads to agents spending considerable amount of time idle > when there are multiple stages to be executed. > Agents should heartbeat at a higher rate while there are still pending stages > to be executed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17419) Disabling the auto-start for ambari-server and ambari-agent doesn't work on systemd
[
https://issues.apache.org/jira/browse/AMBARI-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-17419:
--
Attachment: AMBARI-17419.trunk.v1.patch
> Disabling the auto-start for ambari-server and ambari-agent doesn't work on
> systemd
> ---
>
> Key: AMBARI-17419
> URL: https://issues.apache.org/jira/browse/AMBARI-17419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent, ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-17419.trunk.v1.patch, AMBARI-17419.v1.patch
>
>
> Trying do disable auto-start for ambari-server by executing {{update-rc.d
> ambari-server disable}} is failing with {{update-rc.d: error: ambari-server
> Default-Start contains no runlevels, aborting.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17419) Disabling the auto-start for ambari-server and ambari-agent doesn't work on systemd
[
https://issues.apache.org/jira/browse/AMBARI-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-17419:
--
Attachment: (was: AMBARI-17419.v1.patch)
> Disabling the auto-start for ambari-server and ambari-agent doesn't work on
> systemd
> ---
>
> Key: AMBARI-17419
> URL: https://issues.apache.org/jira/browse/AMBARI-17419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent, ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-17419.trunk.v1.patch
>
>
> Trying do disable auto-start for ambari-server by executing {{update-rc.d
> ambari-server disable}} is failing with {{update-rc.d: error: ambari-server
> Default-Start contains no runlevels, aborting.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-17419) Disabling the auto-start for ambari-server and ambari-agent doesn't work on systemd
Sebastian Toader created AMBARI-17419:
-
Summary: Disabling the auto-start for ambari-server and
ambari-agent doesn't work on systemd
Key: AMBARI-17419
URL: https://issues.apache.org/jira/browse/AMBARI-17419
Project: Ambari
Issue Type: Bug
Components: ambari-agent, ambari-server
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Fix For: 2.4.0
Trying do disable auto-start for ambari-server by executing {{update-rc.d
ambari-server disable}} is failing with {{update-rc.d: error: ambari-server
Default-Start contains no runlevels, aborting.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17419) Disabling the auto-start for ambari-server and ambari-agent doesn't work on systemd
[
https://issues.apache.org/jira/browse/AMBARI-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-17419:
--
Attachment: AMBARI-17419.v1.patch
> Disabling the auto-start for ambari-server and ambari-agent doesn't work on
> systemd
> ---
>
> Key: AMBARI-17419
> URL: https://issues.apache.org/jira/browse/AMBARI-17419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent, ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-17419.v1.patch
>
>
> Trying do disable auto-start for ambari-server by executing {{update-rc.d
> ambari-server disable}} is failing with {{update-rc.d: error: ambari-server
> Default-Start contains no runlevels, aborting.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17419) Disabling the auto-start for ambari-server and ambari-agent doesn't work on systemd
[
https://issues.apache.org/jira/browse/AMBARI-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-17419:
--
Status: Patch Available (was: In Progress)
> Disabling the auto-start for ambari-server and ambari-agent doesn't work on
> systemd
> ---
>
> Key: AMBARI-17419
> URL: https://issues.apache.org/jira/browse/AMBARI-17419
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent, ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-17419.v1.patch
>
>
> Trying do disable auto-start for ambari-server by executing {{update-rc.d
> ambari-server disable}} is failing with {{update-rc.d: error: ambari-server
> Default-Start contains no runlevels, aborting.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15296) Missing property: hive.server2.authentication.kerberos.keytab
[
https://issues.apache.org/jira/browse/AMBARI-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188906#comment-15188906
]
Sebastian Toader commented on AMBARI-15296:
---
Committed to branch-2.2:
{code}
commit ea069b334ae0b163c0670145c02f10e92d64d101
Author: Toader, Sebastian
Date: Wed Mar 9 20:41:07 2016 +0100
AMBARI-15296. Missing property:
hive.server2.authentication.kerberos.keytab. (Laszlo Puskas via stoader)
{code}
> Missing property: hive.server2.authentication.kerberos.keytab
> -
>
> Key: AMBARI-15296
> URL: https://issues.apache.org/jira/browse/AMBARI-15296
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Mahadev konar
>Assignee: Laszlo Puskas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15296.v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
[ https://issues.apache.org/jira/browse/AMBARI-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15336: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Blueprints: NullPointerException when unncessary config types found with > %HOSTGROUP% tags > - > > Key: AMBARI-15336 > URL: https://issues.apache.org/jira/browse/AMBARI-15336 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-15336.v2.patch > > > NPE is thrown during cluster provisioning when the Blueprint contains > configurations that are not used by any of the services that are listed in > the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15457) Topology host info is not cleared when a host is removed
[
https://issues.apache.org/jira/browse/AMBARI-15457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15202639#comment-15202639
]
Sebastian Toader commented on AMBARI-15457:
---
Committed to branch-2.2
{noformat}
commit 4ae09499732c9d997edbb215837713619dc4e639
Author: Toader, Sebastian
Date: Sat Mar 19 07:19:43 2016 +0100
AMBARI-15457. Topology host info is not cleared when a host is removed.
(Daniel Gergely via stoader)
{noformat}
> Topology host info is not cleared when a host is removed
>
>
> Key: AMBARI-15457
> URL: https://issues.apache.org/jira/browse/AMBARI-15457
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15457.patch, AMBARI-15457_branch-2.2.patch
>
>
> When a host is removed, a record is left in the topology_host_info table. As
> a result re-adding the same host is not possible, due to invalid topology.
> Host removal should remove the corresponding record from topology_host_info
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15241) Basic Operational Audit Logging
[
https://issues.apache.org/jira/browse/AMBARI-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15218707#comment-15218707
]
Sebastian Toader commented on AMBARI-15241:
---
Committed to trunk:
{code}
commit 46a34ccdabe0ad4172e94a63c9b077e17861
Author: Toader, Sebastian
Date: Wed Mar 30 20:02:27 2016 +0200
AMBARI-15241. Basic Operational Audit Logging. (Daniel Gergely via stoader)
{code}
> Basic Operational Audit Logging
> ---
>
> Key: AMBARI-15241
> URL: https://issues.apache.org/jira/browse/AMBARI-15241
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Reporter: Sebastian Toader
>Assignee: Daniel Gergely
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15241.v2.patch
>
>
> Ambari should audit operational events (including user, timestamp, etc) such
> as: start, stop, restart, move, add/delete service, add/delete component,
> enable/disable kerberos, enter/leave maintenance mode,
> create/edit/enable/disable alerts. This should also include user/group role
> changes (including Ambari Admin flag).
> This information should be available in an operational log.
> When an operation is executed in Ambari, append an entry to a history log
> showing:
> The timestamp is when the operation is started
> The user is the logged in user
> The operation is what is currently displayed in the operations UI
> The success/fail is what is displayed in the UI when the operation is
> completed
> Comment is an optional field the user can supply
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15241) Basic Operational Audit Logging
[ https://issues.apache.org/jira/browse/AMBARI-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15241: -- Attachment: AMBARI-15241.v2.patch > Basic Operational Audit Logging > --- > > Key: AMBARI-15241 > URL: https://issues.apache.org/jira/browse/AMBARI-15241 > Project: Ambari > Issue Type: New Feature > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Daniel Gergely >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15241.patch, AMBARI-15241.v2.patch > > > Ambari should audit operational events (including user, timestamp, etc) such > as: start, stop, restart, move, add/delete service, add/delete component, > enable/disable kerberos, enter/leave maintenance mode, > create/edit/enable/disable alerts. This should also include user/group role > changes (including Ambari Admin flag). > This information should be available in an operational log. > When an operation is executed in Ambari, append an entry to a history log > showing: > The timestamp is when the operation is started > The user is the logged in user > The operation is what is currently displayed in the operations UI > The success/fail is what is displayed in the UI when the operation is > completed > Comment is an optional field the user can supply -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
Sebastian Toader created AMBARI-15643: - Summary: During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING. Key: AMBARI-15643 URL: https://issues.apache.org/jira/browse/AMBARI-15643 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.1 Reporter: Sebastian Toader Assignee: Sebastian Toader Priority: Critical Fix For: 2.2.2 After the cluster creation template posted to Ambari (via the REST Api) to provision a cluster using Blueprints is accepted for processing Ambari returns in the response the url of the request through which the status/progress of the cluster creation can be tracked. When querying the status of the request it erroneously returns "COMPLETED" instead of returning "PENDING" until the first task of the cluster creation is scheduled to be executed on one of the cluster nodes. Once at least one task is scheduled to be executed the status of the request should change to "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
Sebastian Toader created AMBARI-15744:
-
Summary: Webhcat Server failed to stop while stopping all the
services
Key: AMBARI-15744
URL: https://issues.apache.org/jira/browse/AMBARI-15744
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.2.2
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Fix For: 2.2.2
Stop all the services using Stop All on dashboard. Webhcat server fails to stop
with the below error. This looks like an intermittent issue.
{code}
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
line 155, in \nWebHCatServer().execute()\n File
\"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
line 219, in execute\nmethod(env)\n File
\"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
line 47, in stop\nwebhcat_service(action='stop')\n File
\"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
line 89, in thunk\nreturn fn(*args, **kwargs)\n File
\"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
line 57, in webhcat_service\nenvironment = environ)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
line 154, in __init__\nself.env.run()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 158, in run\nself.run_action(resource, action)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 121, in run_action\nprovider_action()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
line 238, in action_run\ntries=self.resource.tries,
try_sleep=self.resource.try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 70, in inner\nresult = function(command, **kwargs)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 140, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n
File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 291, in _call\nraise
Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
'/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
webhcat: stopping
...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Attachment: AMBARI-15744.trunk.v2.patch
AMBARI-15744.branch-2.2.v2.patch
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230212#comment-15230212
]
Sebastian Toader commented on AMBARI-15744:
---
Part2 committed to trunk:
{code}
commit 0e87151795a9bf97f8b7ef8033204b03f08ab91b
Author: Toader, Sebastian
Date: Thu Apr 7 15:08:37 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (part2) (stoader)
{code}
Part2 committed to branch-2.2:
{code}
commit 86a2305c0a8456dfdbe5e80f3cedd1630cad51b1
Author: Toader, Sebastian
Date: Thu Apr 7 15:13:45 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (part2) (stoader)
{code}
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230846#comment-15230846
]
Sebastian Toader commented on AMBARI-15646:
---
Committed to trunk:
{code}
commit 6320d589f942b41cdab34c1de241423ccb5b4752
Author: Daniel Gergely
Date: Thu Apr 7 18:48:43 2016 +0200
AMBARI-15646. Audit Log Code Cleanup & Safety. (Daniel Gergely via stoader)
{code}
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Attachment: AMBARI-15744.trunk.v1.patch
AMBARI-15744.branch-2.2.v1.patch
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Status: Patch Available (was: In Progress)
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
Sebastian Toader created AMBARI-15803: - Summary: Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive Key: AMBARI-15803 URL: https://issues.apache.org/jira/browse/AMBARI-15803 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.2 Reporter: Sebastian Toader Assignee: Sebastian Toader Priority: Blocker Fix For: 2.2.2 If a cluster is being provisioned using Blueprint then Ambari server restarted prior all hosts specified in the cluster creation template was assigned to the cluster, than the server becomes unresponsive unable to load the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: AMBARI-15803.trunk.v1.patch AMBARI-15803.branch-2.2.v1.patch > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v1.patch, > AMBARI-15803.trunk.v1.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.branch-2.2.v1.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.trunk.v2.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: AMBARI-15803.trunk.v2.patch AMBARI-15803.branch-2.2.v2.patch > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.trunk.v2.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.trunk.v1.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.trunk.v2.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15804) Audit logging cleanup and tests
[
https://issues.apache.org/jira/browse/AMBARI-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238695#comment-15238695
]
Sebastian Toader commented on AMBARI-15804:
---
Committed to trunk:
{code}
commit e0bc22e18b85e16800225076a60606f4e8f13e87
Author: Toader, Sebastian
Date: Tue Apr 12 16:26:59 2016 +0200
AMBARI-15804. Audit logging cleanup and tests (part2). (Daniel Gergely via
stoader)
commit af13ef73931bf672536199b944d4c3e26ad24ac4
Author: Daniel Gergely
Date: Tue Apr 12 14:59:45 2016 +0200
AMBARI-15804. Audit logging cleanup and tests. (Daniel Gergely via stoader)
{code}
> Audit logging cleanup and tests
> ---
>
> Key: AMBARI-15804
> URL: https://issues.apache.org/jira/browse/AMBARI-15804
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-15804.patch
>
>
> Add unit tests for events and event creators, correct auditlog messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15804) Audit logging cleanup and tests
[ https://issues.apache.org/jira/browse/AMBARI-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15804: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Audit logging cleanup and tests > --- > > Key: AMBARI-15804 > URL: https://issues.apache.org/jira/browse/AMBARI-15804 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-15804.patch > > > Add unit tests for events and event creators, correct auditlog messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15646:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
>
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Status: Patch Available (was: In Progress) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v1.patch, > AMBARI-15803.trunk.v1.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15786) Add some logs to help co-related task ids from server and agent
[ https://issues.apache.org/jira/browse/AMBARI-15786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234953#comment-15234953 ] Sebastian Toader commented on AMBARI-15786: --- +1 > Add some logs to help co-related task ids from server and agent > --- > > Key: AMBARI-15786 > URL: https://issues.apache.org/jira/browse/AMBARI-15786 > Project: Ambari > Issue Type: Bug > Components: ambari-agent, ambari-server >Affects Versions: 2.2.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty > Fix For: 2.2.2 > > Attachments: AMBARI-15786.patch > > > Recently, I was debugging some cluster and it was very difficult to co-relate > commands that failed with the scheduling of commands from the server. There > are several key log statements that are missing task IDs that can be used to > co-relate the logs. > The changes are modifying only the logs and I have tested that the logs are > being emitted properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: AMBARI-15803.trunk.v3.patch AMBARI-15803.branch-2.2.v3.patch > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.branch-2.2.v3.patch, AMBARI-15803.trunk.v2.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.branch-2.2.v2.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v3.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[
https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237039#comment-15237039
]
Sebastian Toader commented on AMBARI-15803:
---
Committed to trunk:
{code}
commit 2d25706dfb62fb557b6186d0a8c0f512724f39ea
Author: Toader, Sebastian
Date: Tue Apr 12 09:27:22 2016 +0200
AMBARI-15803. Restarting ambari-server after successful blueprint deploy of
large cluster makes it unresponsive. (stoader)
{code}
Committed to branch-2.2:
{code}
commit 7e6877a1589be25499d0a833d3099e612d9b420d
Author: Toader, Sebastian
Date: Tue Apr 12 09:22:06 2016 +0200
AMBARI-15803. Restarting ambari-server after successful blueprint deploy of
large cluster makes it unresponsive. (stoader)
{code}
> Restarting ambari-server after successful blueprint deploy of large cluster
> makes it unresponsive
> -
>
> Key: AMBARI-15803
> URL: https://issues.apache.org/jira/browse/AMBARI-15803
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-15803.branch-2.2.v3.patch,
> AMBARI-15803.trunk.v3.patch
>
>
> If a cluster is being provisioned using Blueprint then Ambari server
> restarted prior all hosts specified in the cluster creation template was
> assigned to the cluster, than the server becomes unresponsive unable to load
> the cluster from database and continue the cluster creation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v3.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230023#comment-15230023
]
Sebastian Toader commented on AMBARI-15744:
---
Committed to trunk:
{code}
commit 1cc4a20b33157de8c547929321567911a13d8942
Author: Toader, Sebastian
Date: Thu Apr 7 11:32:42 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (stoader)
{code}
Committed to branch-2.2:
{code}
commit 5edcf8a275a7ec6f80a6d4456942103e3c8c006c
Author: Toader, Sebastian
Date: Thu Apr 7 11:56:52 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (stoader)
{code}
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15205284#comment-15205284
]
Sebastian Toader commented on AMBARI-15489:
---
Committed to trunk:
{code}
commit d2ccdcaa4435c15c6559c405383c12aac5ae
Author: Toader, Sebastian
Date: Mon Mar 21 19:23:53 2016 +0100
AMBARI-15489. Configuration with tag 'TOPOLOGY_RESOLVED' exists for
'cluster-env' error when creating Kerberized cluster with Blueprints. (stoader)
{code}
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
>
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Attachment: AMBARI-15554.v1.patch
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v1.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> at
>
[jira] [Updated] (AMBARI-15531) Hiveserver2 goes down on HA cluster deployed via blueprint
[
https://issues.apache.org/jira/browse/AMBARI-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15531:
--
Fix Version/s: 2.4.0
> Hiveserver2 goes down on HA cluster deployed via blueprint
> --
>
> Key: AMBARI-15531
> URL: https://issues.apache.org/jira/browse/AMBARI-15531
> Project: Ambari
> Issue Type: Bug
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15531.b22.v1.patch, AMBARI-15531.b22.v2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> On an HA cluster deployed via bluerint, HiveServer2 is down and we see below
> in hiveserver2 logs
> {code}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=hive, access=WRITE,
> inode="/tmp/hive":hdfs:hdfs:drwxr-xr-x
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1780)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1764)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1747)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3930)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1068)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:622)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2206)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2202)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2200)
> at org.apache.hadoop.ipc.Client.call(Client.java:1427)
> at org.apache.hadoop.ipc.Client.call(Client.java:1358)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
> at com.sun.proxy.$Proxy15.mkdirs(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.mkdirs(ClientNamenodeProtocolTranslatorPB.java:558)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:252)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
> at com.sun.proxy.$Proxy16.mkdirs(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3018)
> ... 24 more
> 2016-03-21 20:06:00,216 INFO [Thread-4]: server.HiveServer2
> (HiveStringUtils.java:run(709)) - SHUTDOWN_MSG:
> /
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: (was: 2.4.0)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: (was: 2.4.0)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: AMBARI-15489.v1.patch
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: 2.2.2
2.4.0
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
>
[jira] [Created] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
Sebastian Toader created AMBARI-15489:
-
Summary: Configuration with tag 'TOPOLOGY_RESOLVED' exists for
'cluster-env' error when creating Kerberized cluster with Blueprints
Key: AMBARI-15489
URL: https://issues.apache.org/jira/browse/AMBARI-15489
Project: Ambari
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when
creating Kerberized cluster with Blueprints.
{noformat}
17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
AmbariManagementControllerImpl:1471 - Applying configuration with tag
'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
TopologyManager.ConfigureClusterTask: An exception occurred while attempting to
process cluster configs and set on cluster:
java.lang.RuntimeException: Failed to set configurations on cluster:
org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
at
org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
at
org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
at
org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
at
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
at
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
at
org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
... 11 more
Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
at
org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
at
org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
... 12 more
17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
Exception during task execution:
java.util.concurrent.ExecutionException: java.lang.Exception:
java.lang.RuntimeException: Failed to set configurations on cluster:
org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluste
r-env'
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:206)
at
org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
at
org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
at
org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.Exception: java.lang.RuntimeException: Failed to set
configurations on cluster: org.apache.ambari.server.AmbariException:
Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Status: Patch Available (was: In Progress)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: AMBARI-15489.v2.patch
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: (was: AMBARI-15489.v1.patch)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: AMBARI-15489-trunk.v2.patch
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Attachment: AMBARI-15554.v2.patch
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> at
>
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Attachment: (was: AMBARI-15554.v1.patch)
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
>
[jira] [Commented] (AMBARI-15665) Unable to Create Cluster Fails Due To Audit Logger
[
https://issues.apache.org/jira/browse/AMBARI-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223162#comment-15223162
]
Sebastian Toader commented on AMBARI-15665:
---
Committed to trunk:
{code}
commit 836647a36966b1b534e1419b30d4b31858773478
Author: Daniel Gergely
Date: Sat Apr 2 11:29:37 2016 +0200
AMBARI-15665. Unable to Create Cluster Fails Due To Audit Logger. (Daniel
Gergley via stoader)
{code}
> Unable to Create Cluster Fails Due To Audit Logger
> --
>
> Key: AMBARI-15665
> URL: https://issues.apache.org/jira/browse/AMBARI-15665
> Project: Ambari
> Issue Type: Bug
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
>Priority: Blocker
> Attachments: AMBARI-15665.patch
>
>
> Attempt to update repository information in preparation for a new cluster
> creation:
> {code}
> PUT
> api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> {
> "Repositories": {
> "base_url": "http://repo.ambari.apache.org/hdp/centos6/HDP-2.3.6.0-3566/;,
> "verify_base_url": true
> }
> }
> {code}
> {code}
> 2016-03-31 15:47:17,822 WARN [qtp-ambari-client-35]
> (ServletHandler.java:628) doHandle() -
> /api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> java.lang.ClassCastException:
> org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter$1
> cannot be cast to org.springframework.security.core.userdetails.User
> at
> org.apache.ambari.server.audit.request.eventcreator.RepositoryEventCreator.createAuditEvent(RepositoryEventCreator.java:83)
> at
> org.apache.ambari.server.audit.request.RequestAuditLoggerImpl.log(RequestAuditLoggerImpl.java:85)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:130)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:83)
> at
> org.apache.ambari.server.api.services.RepositoryService.updateRepository(RepositoryService.java:145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15665) Unable to Create Cluster Fails Due To Audit Logger
[
https://issues.apache.org/jira/browse/AMBARI-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15665:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Unable to Create Cluster Fails Due To Audit Logger
> --
>
> Key: AMBARI-15665
> URL: https://issues.apache.org/jira/browse/AMBARI-15665
> Project: Ambari
> Issue Type: Bug
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
>Priority: Blocker
> Attachments: AMBARI-15665.patch
>
>
> Attempt to update repository information in preparation for a new cluster
> creation:
> {code}
> PUT
> api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> {
> "Repositories": {
> "base_url": "http://repo.ambari.apache.org/hdp/centos6/HDP-2.3.6.0-3566/;,
> "verify_base_url": true
> }
> }
> {code}
> {code}
> 2016-03-31 15:47:17,822 WARN [qtp-ambari-client-35]
> (ServletHandler.java:628) doHandle() -
> /api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> java.lang.ClassCastException:
> org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter$1
> cannot be cast to org.springframework.security.core.userdetails.User
> at
> org.apache.ambari.server.audit.request.eventcreator.RepositoryEventCreator.createAuditEvent(RepositoryEventCreator.java:83)
> at
> org.apache.ambari.server.audit.request.RequestAuditLoggerImpl.log(RequestAuditLoggerImpl.java:85)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:130)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:83)
> at
> org.apache.ambari.server.api.services.RepositoryService.updateRepository(RepositoryService.java:145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[ https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15643: -- Attachment: AMBARI-15643.v1.patch > During cluster creation using Blueprints the cluster creation request has > incorrect COMPLETED state instead of PENDING. > --- > > Key: AMBARI-15643 > URL: https://issues.apache.org/jira/browse/AMBARI-15643 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-15643.v1.patch > > > After the cluster creation template posted to Ambari (via the REST Api) to > provision a cluster using Blueprints is accepted for processing Ambari > returns in the response the url of the request through which the > status/progress of the cluster creation can be tracked. > When querying the status of the request it erroneously returns "COMPLETED" > instead of returning "PENDING" until the first task of the cluster creation > is scheduled to be executed on one of the cluster nodes. Once at least one > task is scheduled to be executed the status of the request should change to > "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks > completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[
https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220167#comment-15220167
]
Sebastian Toader commented on AMBARI-15643:
---
Committed to trunk:
{code}
commit 6f61de093943a75868925cb7f76cbceea6215ae9
Author: Toader, Sebastian
Date: Thu Mar 31 16:39:29 2016 +0200
AMBARI-15643. During cluster creation using Blueprints the cluster creation
request has incorrect COMPLETED state instead of PENDING. (stoader)
{code}
> During cluster creation using Blueprints the cluster creation request has
> incorrect COMPLETED state instead of PENDING.
> ---
>
> Key: AMBARI-15643
> URL: https://issues.apache.org/jira/browse/AMBARI-15643
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15643.v1.patch
>
>
> After the cluster creation template posted to Ambari (via the REST Api) to
> provision a cluster using Blueprints is accepted for processing Ambari
> returns in the response the url of the request through which the
> status/progress of the cluster creation can be tracked.
> When querying the status of the request it erroneously returns "COMPLETED"
> instead of returning "PENDING" until the first task of the cluster creation
> is scheduled to be executed on one of the cluster nodes. Once at least one
> task is scheduled to be executed the status of the request should change to
> "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks
> completed succesfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[ https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15643: -- Status: Patch Available (was: In Progress) > During cluster creation using Blueprints the cluster creation request has > incorrect COMPLETED state instead of PENDING. > --- > > Key: AMBARI-15643 > URL: https://issues.apache.org/jira/browse/AMBARI-15643 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-15643.v1.patch > > > After the cluster creation template posted to Ambari (via the REST Api) to > provision a cluster using Blueprints is accepted for processing Ambari > returns in the response the url of the request through which the > status/progress of the cluster creation can be tracked. > When querying the status of the request it erroneously returns "COMPLETED" > instead of returning "PENDING" until the first task of the cluster creation > is scheduled to be executed on one of the cluster nodes. Once at least one > task is scheduled to be executed the status of the request should change to > "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks > completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task
[
https://issues.apache.org/jira/browse/AMBARI-15645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15645:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_branch-2.2_01.patch,
> AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos
> identity is established before making this call when really the HDFS identity
> should be established - since this is an administrative HDFS call that
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
> if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
> time.sleep(5)
> hdfs_roll_edits()
> time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
> if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
> time.sleep(5)
> hdfs_roll_edits()
> time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in
> https://issues.apache.org/jira/browse/AMBARI-10519.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214632#comment-15214632
]
Sebastian Toader commented on AMBARI-15554:
---
Committed to trunk:
{code}
commit 71b4c624fb219bb1626c238322bda6c2e5589f72
Author: Toader, Sebastian
Date: Mon Mar 28 13:04:17 2016 +0200
AMBARI-15554. Ambari LDAP integration cannot handle LDAP directories with
multiple entries for the same user. (stoader)
{code}
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
>
[jira] [Commented] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15205073#comment-15205073
]
Sebastian Toader commented on AMBARI-15489:
---
Committed to branch-2.2:
{code}
commit 4dfcaf8864b211fd8cbf1fc522f2b8fe0e8a3782
Author: Toader, Sebastian
Date: Mon Mar 21 19:23:53 2016 +0100
AMBARI-15489. Configuration with tag 'TOPOLOGY_RESOLVED' exists for
'cluster-env' error when creating Kerberized cluster with Blueprints. (stoader)
{code}
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
>
[jira] [Commented] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252589#comment-15252589
]
Sebastian Toader commented on AMBARI-16013:
---
{code:title=branch-2.2.2}
commit 95bc6b6056f7c87890cb2b1473b2fc72e6be89c4
Author: Toader, Sebastian
Date: Thu Apr 21 19:07:36 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
{code:title=branch-2.2}
commit ff25b1d7f3142d18114b351180c1fff85caa8799
Author: Toader, Sebastian
Date: Thu Apr 21 19:07:36 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
{code:title=trunk}
commit 5b5bf1a34b1b060202421fcdb91a73f47376c273
Author: Toader, Sebastian
Date: Thu Apr 21 19:09:56 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-16180) Backport AMBARI-15457 to 2.2-next
[ https://issues.apache.org/jira/browse/AMBARI-16180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263860#comment-15263860 ] Sebastian Toader commented on AMBARI-16180: --- +1 > Backport AMBARI-15457 to 2.2-next > - > > Key: AMBARI-16180 > URL: https://issues.apache.org/jira/browse/AMBARI-16180 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1.1 >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.2-next > > Attachments: AMBARI-16180.patch > > > Backport AMBARI-15457 to 2.2-next > The issue was about invalid topology if a host is removed and then re-added > to the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Commented] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15259626#comment-15259626
]
Sebastian Toader commented on AMBARI-16119:
---
Committed to trunk:
{code}
commit fee485798ea0f271f51a41d6e05386ed28b9b755
Author: Toader, Sebastian
Date: Tue Apr 26 21:15:54 2016 +0200
AMBARI-16119. User imported from AD is unable to login to Ambari. (stoader)
{code}
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
>
[jira] [Created] (AMBARI-16119) User imported from AD is unable to login to Ambari.
Sebastian Toader created AMBARI-16119:
-
Summary: User imported from AD is unable to login to Ambari.
Key: AMBARI-16119
URL: https://issues.apache.org/jira/browse/AMBARI-16119
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Fix For: 2.4.0
Steps to reproduce:
#Install ambari 2.4.0
#Setup ambari with AD server
#Perform "ambari-server sync-ldap --all"
#Try to login to Ambari as one of the users imported AD
The login fails with the following exception in the log:
{code}
20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
/api/v1/users/ambari-d
java.lang.IllegalArgumentException: Cannot pass null or empty values to
constructor
at
org.springframework.security.core.userdetails.User.(User.java:99)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
at
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
at
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
at
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
at
org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:216)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:205)
at
org.apache.ambari.server.controller.AmbariHandlerList.handle(AmbariHandlerList.java:139)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Description:
Steps to reproduce:
# Install ambari 2.4.0
# Setup ambari with AD server
# Perform "ambari-server sync-ldap --all"
# Try to login to Ambari as one of the users imported AD
The login fails with the following exception in the log:
{code}
20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
/api/v1/users/ambari-d
java.lang.IllegalArgumentException: Cannot pass null or empty values to
constructor
at
org.springframework.security.core.userdetails.User.(User.java:99)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
at
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
at
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
at
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
at
org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:216)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:205)
at
org.apache.ambari.server.controller.AmbariHandlerList.handle(AmbariHandlerList.java:139)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: AMBARI-16119.trunk.v1.patch
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v1.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Status: Patch Available (was: Open)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v1.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: (was: AMBARI-16119.trunk.v2.patch)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: AMBARI-16119.trunk.v3.patch
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: (was: AMBARI-16119.trunk.v1.patch)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v2.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: AMBARI-16119.trunk.v2.patch
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v2.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Commented] (AMBARI-16820) Blueprint Export does not replace hive.llap.zk.sm.connectionString
[
https://issues.apache.org/jira/browse/AMBARI-16820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298087#comment-15298087
]
Sebastian Toader commented on AMBARI-16820:
---
Committed to trunk:
{code}
commit 0965ddec865740b2ab8165981dbdc363e45177c3
Author: Daniel Gergely
Date: Tue May 24 14:17:47 2016 +0200
AMBARI-16820. Blueprint Export does not replace
hive.llap.zk.sm.connectionString. (Daniel Gergely via stoader)
{code}
Committed to branch-2.4:
{code}
Author: Daniel Gergely
Date: Tue May 24 14:17:47 2016 +0200
AMBARI-16820. Blueprint Export does not replace
hive.llap.zk.sm.connectionString. (Daniel Gergely via stoader)
{code}
> Blueprint Export does not replace hive.llap.zk.sm.connectionString
> --
>
> Key: AMBARI-16820
> URL: https://issues.apache.org/jira/browse/AMBARI-16820
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-16820.patch
>
>
> When exporting blueprint, the value of property
> hive.llap.zk.sm.connectionString is not replaced with placeholders.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-16820) Blueprint Export does not replace hive.llap.zk.sm.connectionString
[
https://issues.apache.org/jira/browse/AMBARI-16820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298087#comment-15298087
]
Sebastian Toader edited comment on AMBARI-16820 at 5/24/16 12:24 PM:
-
Committed to trunk:
{code}
commit 0965ddec865740b2ab8165981dbdc363e45177c3
Author: Daniel Gergely
Date: Tue May 24 14:17:47 2016 +0200
AMBARI-16820. Blueprint Export does not replace
hive.llap.zk.sm.connectionString. (Daniel Gergely via stoader)
{code}
Committed to branch-2.4:
{code}
commit 9633574dac50b58ada66c3b081dd366a64accbbd
Author: Daniel Gergely
Date: Tue May 24 14:17:47 2016 +0200
AMBARI-16820. Blueprint Export does not replace
hive.llap.zk.sm.connectionString. (Daniel Gergely via stoader)
{code}
was (Author: stoader):
Committed to trunk:
{code}
commit 0965ddec865740b2ab8165981dbdc363e45177c3
Author: Daniel Gergely
Date: Tue May 24 14:17:47 2016 +0200
AMBARI-16820. Blueprint Export does not replace
hive.llap.zk.sm.connectionString. (Daniel Gergely via stoader)
{code}
Committed to branch-2.4:
{code}
Author: Daniel Gergely
Date: Tue May 24 14:17:47 2016 +0200
AMBARI-16820. Blueprint Export does not replace
hive.llap.zk.sm.connectionString. (Daniel Gergely via stoader)
{code}
> Blueprint Export does not replace hive.llap.zk.sm.connectionString
> --
>
> Key: AMBARI-16820
> URL: https://issues.apache.org/jira/browse/AMBARI-16820
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-16820.patch
>
>
> When exporting blueprint, the value of property
> hive.llap.zk.sm.connectionString is not replaced with placeholders.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16820) Blueprint Export does not replace hive.llap.zk.sm.connectionString
[ https://issues.apache.org/jira/browse/AMBARI-16820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-16820: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Blueprint Export does not replace hive.llap.zk.sm.connectionString > -- > > Key: AMBARI-16820 > URL: https://issues.apache.org/jira/browse/AMBARI-16820 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-16820.patch > > > When exporting blueprint, the value of property > hive.llap.zk.sm.connectionString is not replaced with placeholders. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16630) Extend logging for ActionQueue's retry logic
[
https://issues.apache.org/jira/browse/AMBARI-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16630:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to branch-2.4:
{code}
commit 34f5cbb2d5335d24bdcb6285793783f71a7b3489
Author: Daniel Gergely
Date: Tue May 17 22:32:46 2016 +0200
AMBARI-16630. Extend logging for ActionQueue's retry logic. (Daniel Gergely
via stoader)
commit 9201b6498b55c9e4d9d2e92fea38ddaad42e6832
Author: Daniel Gergely
Date: Wed May 18 09:19:55 2016 +0200
AMBARI-16630. Extend logging for ActionQueue's retry logic (part2). (Daniel
Gergely via stoader)
{code}
Committed to trunk:
{code}
commit 40fe30bfe7d58ce56e128d8c09be6cb947eff92f
Author: Daniel Gergely
Date: Tue May 17 22:32:46 2016 +0200
AMBARI-16630. Extend logging for ActionQueue's retry logic. (Daniel Gergely
via stoader)
commit 7d516272c6a035e0bd970cb592061ea08a40a942
Author: Daniel Gergely
Date: Wed May 18 09:19:55 2016 +0200
AMBARI-16630. Extend logging for ActionQueue's retry logic (part2). (Daniel
Gergely via stoader)
{code}
> Extend logging for ActionQueue's retry logic
>
>
> Key: AMBARI-16630
> URL: https://issues.apache.org/jira/browse/AMBARI-16630
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-agent
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0, 2.2-next
>
> Attachments: AMBARI-16630.patch, AMBARI-16630_2.2-next.patch,
> AMBARI-16630_addendum.patch
>
>
> At info level, commands should be tracked if they are retried on failure or
> not, and if not, what is the reason for that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16214) Ensure Blueprint deployment can start immediately - after Server start
Sebastian Toader created AMBARI-16214: - Summary: Ensure Blueprint deployment can start immediately - after Server start Key: AMBARI-16214 URL: https://issues.apache.org/jira/browse/AMBARI-16214 Project: Ambari Issue Type: Task Components: ambari-server Reporter: Sebastian Toader Fix For: 2.4.1 * Blueprint deployment should only wait for headnodes/zknodes * Blueprint may be provided during cluster start up (no need for a REST API call). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-16221) AMS/LogSearch service should be outside the cluster and shared across clusters
Sebastian Toader created AMBARI-16221: - Summary: AMS/LogSearch service should be outside the cluster and shared across clusters Key: AMBARI-16221 URL: https://issues.apache.org/jira/browse/AMBARI-16221 Project: Ambari Issue Type: Task Components: ambari-server Reporter: Sebastian Toader Fix For: 2.4.1 AMS and LogSearch can be shared services that is shared across clusters. Cluster deployments can simply deploy the agents (AMS Monitor, Sinks, and Log Feeders) that can communicate with shared services. In some ways, logs are already being collected by log4j sinks and syslog handlers. Metrics should also be collected in the same way by a shared service and made accessible to the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
