brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Corbett (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-385) Synchronous start of group members
Date Mon, 14 Nov 2016 11:10:58 GMT


Sam Corbett commented on BROOKLYN-385:

Two suggestions from [~alex.heneveld]:

{{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.)

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

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

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)

> Synchronous start of group members
> ----------------------------------
>                 Key: BROOKLYN-385
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message