[
https://issues.apache.org/jira/browse/AMBARI-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185602#comment-14185602
]
Robert Levas commented on AMBARI-7985:
--------------------------------------
[~swagle],
{{quote}}
Server-side commands should be specified as a task in a stage
Does this mean a server action is a part of Role Command order, and if it is,
since all server actions have the same role AMBARI_SERVER_ACTION, how can it be
specified in the ordering
{{quote}
I guess this does mean that a server action is part of a Role Command order and
thus will have the role {{AMBARI_SERVER_ACTION}}. Thinking about this more, I
believe that a role can be specified only once within a stage, so multiple
stages will need to be created to handle multiple server-side actions. With
this, aren't stages ordered and guaranteed not to start unless the previous
stage completes successfully?
{{quote}}
{{quote}}
each server-side task should be executed in its own thread
A stage in Ambari is a way of grouping tasks that can be executed in parallel
(one command per host), if server action follows max one action per stage, it
would be executed serially by the Action Scheduler.
I am not sure I understand, why the need for separate thread to execute server
actions, could you explain the need for this ?
{{quote}}
It appeared to me that the Action Scheduler pulled tasks from the queue and
processed them by simply updating their states so that another process could
come by and pick them up - somewhere in the Heartbeat monitor code. This is a
quick task and could be done inline without causing a perceivable delay.
However if we allow the server-side task to be handled in this thread, it could
take some time and delay the queue processing.
It may be that case that this is ok, especially since each server-side task may
be handled in its own stage. However, are stages created by different request
ordered? If not, then we may not want to hold the Action Scheduler hostage
while we process our server-side task.
> 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)
