[
https://issues.apache.org/jira/browse/AMBARI-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185737#comment-14185737
]
Robert Levas commented on AMBARI-7985:
--------------------------------------
[~swagle]
I agree that we should use most of the existing architecture. I was going to
investigate using the ServerActionManager or something like it - it appears
that the existing ServiceActionManager isn't really doing anything and may even
be obsolete. So from within the ActionScheduler, there is a switch that
attempts to handle server-side tasks:
{code}
for (ExecutionCommand cmd : commandsToSchedule) {
if (Role.valueOf(cmd.getRole()).equals(Role.AMBARI_SERVER_ACTION)) {
/**
* We don't forbid executing any stages in parallel with
* AMBARI_SERVER_ACTION. That should be OK as AMBARI_SERVER_ACTION
* is not used as of now. The general motivation has been to update
* Request status when last task associated with the
* Request is finished.
*/
executeServerAction(s, cmd);
} else {
processHostRole(s, cmd, commandsToStart, commandsToUpdate);
}
}
{code}
I plan to reuse this, but make the {{executeServerAction}} method do something
useful - maybe even rename it to be sort of symmetrical, {{processServerRole}}.
Anticipating that an Ambari Agent may not be running on the Ambari Server is
one of the reasons I am going with this route, since it may be the case that I
need to know beforehand the IP of the server to get to external resources and
etc...
To be clear on how I see this working, the HRC will essentially state
{{server}}, {{AMBARI_SERVER_ACTION}}, {{CUSTOM_COMMAND}}. The details of the
command will be embedded in the command payload... something like:
{code:javascript}
{
"implementation" : "<some classpath, extends ServerAction>",
"data" : {
<command data>
}
}
{code}
> Allow for server-side commands
> ------------------------------
>
> Key: AMBARI-7985
> URL: https://issues.apache.org/jira/browse/AMBARI-7985
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
> Affects Versions: 2.0.0
> Reporter: Robert Levas
> Assignee: Robert Levas
> Labels: ambari-server, commands, server, server-side, tasks
> Fix For: 2.0.0
>
>
> Ambari currently handles _client-/agent-side_ commands; however there is no
> ability to handle _server-side_ commands. Server-side commands should be
> specified as a task in a stage and managed along with the stage.
> *Use Case:* Generate principals and keytabs on the Ambari server before
> sending the keytabs to their relevant hosts.
> *Implementation:* To add the concept of a server-side task:
> * update {{org.apache.ambari.server.serveraction.ServerAction}} to be an
> _abstract class_
> ** _server-side_ tasks must implement this class
> * reuse existing _host_role_command_ and _execution_command_ data
> ** _server-side_ tasks are to have a role of {{AMBARI_SERVER_ACTION}}
> ** _server-side_ execution command data should be encapsulated as JSON and
> specify the ServerAction implementation class and any needed payload data
> * {{org.apache.ambari.server.actionmanager.ActionScheduler}} and
> {{org.apache.ambari.server.serveraction.ServerActionManagerImpl}} need to be
> updated to handle the execution of server-side tasks
> ** each _server-side_ task should be executed in its own thread.
> *** _server_side_ tasks should be executed in (staged) order, serially - not
> in parallel
> *** _server_side_ tasks should ensure not to mess up _stage_ ordering
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
