brooklyn-dev mailing list archives

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

    [ 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)

Mime
View raw message