[
https://issues.apache.org/jira/browse/WHIRR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201779#comment-13201779
]
David Alves edited comment on WHIRR-221 at 2/6/12 11:47 PM:
------------------------------------------------------------
Dependencies are specified as follows:
public class HBaseMasterClusterActionHandler {
...
public void getRequiredRoles() {
return ImmutableSet.of("zookeeper");
}
...
}
Dependencies are overriden in configuration as follows:
whirr.role-dependency.hbase-master=
(to set the dependency to none)
There is a main system to run ClusterActionEvents. Before all stages are
executed ClusterActionEvents are built, separated into stages that can be
executed in parallel, and a Callable is attached to each one. After all
beforeAction() method have been called the stages are submitted and each
callable is executed according to the stage.
Even though the next stage won't begin before all the scripts of the current
stage complete, for the cases where a startup script returns before the service
is actually active, handlers can override and return a positive value in
getOnlineDelayMillis(). In this case after each stage whirr will wait for the
biggest of the delays before executing next stage's scripts.
Maven build passes. Dependency analyzer is unit tested.
Do you think we need more unit tests or can we proceed to itests?
There are some corner cases that are still not implemented, namely cyclic
dependencies, and multiple paths a<-b,a<-c,b<-c, but I can't think of a case
where they are required and as such decided leave them for later.
Please review/comment/test/suggest more tests.
was (Author: dr-alves):
Dependencies are specified as follows:
public class HBaseMasterClusterActionHandler {
...
public void getRequiredRoles() {
return ImmutableSet.of("zookeeper");
}
...
}
Dependencies are overriden in configuration as follows:
whirr.role-dependency.hbase-master=
(to set the dependency to none)
There is a main system to run ClusterActionEvents. Before all stages are
executed ClusterActionEvents are built, separated into stages that can be
executed in parallel, and a Callable is attached to each one. After all
beforeAction() method have been called the stages are submitted and each
callable is executed according to the stage.
Even though the next stage won't begin before all the scripts of the current
stage complete, for the cases where a startup script returns before the service
is actually active handler get return a positive value to
getOnlineDelayMillis(). In this case after each stage whirr will wait for the
biggest of the delays before executing next stages scripts.
Maven build passes. Dependency analyzer is unit tested.
Do you think we need more unit tests or can we proceed to itests?
There are some corner cases that are still not implemented, namely cyclic
dependencies, and multiple paths a<-b,a<-c,b<-c, but I can't think of a case
where they are required and as such can leave them for later.
Please review/comment/test/suggest more tests.
> 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
> Affects Versions: 0.8.0
> Reporter: Andrei Savu
> Assignee: David Alves
> Priority: Critical
> Fix For: 0.8.0
>
> Attachments: WHIRR-221-v1.patch, WHIRR-221-v3.patch, WHIRR-221.patch,
> WHIRR-221.patch, WHIRR-221.patch, WHIRR-221.patch
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
