[
https://issues.apache.org/jira/browse/BROOKLYN-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15663491#comment-15663491
]
Sam Corbett commented on BROOKLYN-385:
--------------------------------------
Two suggestions from [~alex.heneveld]:
{quote}
{{maxConcurrentChildCommand}} — per command _instance_ . so if {{=2}} then
{{cluster.start()}} would run {{child1.start()}} and {{child2.start()}} but not
{{child3.start()}} until one of those two completes. it would not go
deeper/finer eg not phases way to allow 3 to {{provision}} while 1 is
{{launch}} — that would be quite hard, and i’m not sure it’s needed (it would
speed things up but maybe there are better ways to allow that.)
{quote}
And:
{quote}
have a semaphore on normal nodes cluster and for the {{launch}} step each node
acquires that semaphore, releasing when confirmed joined. i could see a task
you set in yaml eg if using the initdish idea
{code}
035-pre-launch-get-semaphore: { acquire-semaphore: { scope: $brooklyn:parent(),
name: "node-launch" } }
040-launch: { ssh: "service cassandra start" }
045-confirm-service-up: { wait: { sensor: service.inCluster, timeout: 20m } }
050-finish-release-semaphore: semaphore-release
{code}
tasks of type {{acquire-semaphore}} would use (create if needed) a named
semaphore against the given entity … but somehow we need to say when it should
automatically be released (eg on failure) in addition to explicit release (the
{{050}} which assumes some scope, not sure how/if to implement that)
{quote}
> Synchronous start of group members
> ----------------------------------
>
> Key: BROOKLYN-385
> URL: https://issues.apache.org/jira/browse/BROOKLYN-385
> Project: Brooklyn
> Issue Type: Improvement
> Reporter: Sam Corbett
>
> In some cases it would be useful to enforce a limit on the number of members
> of a cluster that may {{start}} at once. For example, it is preferable to add
> nodes to Cassandra clusters one-at-a-time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
