[
https://issues.apache.org/jira/browse/WHIRR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989576#comment-12989576
]
Tibor Kiss edited comment on WHIRR-221 at 2/2/11 9:55 AM:
----------------------------------------------------------
What exactly means that? We have a BootstrapClusterAction and a
ConfigureClusterAction. It is enough to serialize according the the specified
order only inside BootstrapClusterAction or BootstrapClusterAction and
ConfigureClusterAction has to be serialized in one, role by role?
There are two places where the change has to take place. The
BootstrapCluterAction#doAction and eventually the parent
ScriptBasedClusterAction#execute. The latter one raises a new question. It is
important to serialize in the same way (ordered) the handler.beforeAction and
handler.afterAction event handlers? The latter question is harder to answer, at
least for me and now.
If it is enough to serialize according to order only at the level of
BootstrapClusterAction#doAction, then I would say that when I was fixing
WHIRR-167 I was taking in consideration such a change and I tried to reduce the
complexity of BootstrapClusterAction#doAction. The WHIRR-167 is near to be
commited in trunk (read the latest comments there), this change is much easier
to schedule after WHIRR-167 has been merged into trunk.
Anyway, lets answer the questions raised by the desired feature.
was (Author: tibor.kiss):
What exactly means that? We have a BootstrapClusterAction and a
ConfigureClusterAction. It is enough to serialize according the the specified
order only inside BootstrapCluterAction or BootstrapCluterAction and
ConfigureClusterAction has to be serialized in one, role by role?
There are two places where the change has to take place. The
BootstrapCluterAction#doAction and eventually the parent
ScriptBasedClusterAction#execute. The latter one raises a new question. It is
important to serialize in the same way (ordered) the handler.beforeAction and
handler.afterAction event handlers? The latter question is harder to answer, at
least for me and now.
If it is enough to serialize according to order only at the level of
BootstrapCluterAction#doAction, then I would say that when I was fixing
WHIRR-167 I was taking in consideration such a change and I tried to reduce the
complexity of BootstrapCluterAction#doAction. The WHIRR-167 is near to be
commited in trunk (read the latest comments there), this change is much easier
to schedule after WHIRR-167 has been merged into trunk.
Anyway, lets answer the questions raised by the desired feature.
> Optionally control the order of starting services
> -------------------------------------------------
>
> Key: WHIRR-221
> URL: https://issues.apache.org/jira/browse/WHIRR-221
> Project: Whirr
> Issue Type: New Feature
> Components: core, documentation
> Reporter: Andrei Savu
> Priority: Critical
> Fix For: 0.4.0
>
>
> As Lars sugested in WHIRR-170:
> The user should "be able to optionally control the order (services start).
> This could be role based and specified like so
> {code}
> whirr.role-order=zk,nn+jt,dn+tt,hbase-master,hbase-regionserver
> {code}
> If not specified the system should make any effort to start the services as
> quickly as possible, for example in multiple threads. In other words, when
> the role-order is not given no guarantee about order can be given."
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
