brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: [PROPOSAL] Controlling effectors concurrency
Date Wed, 11 Jan 2017 16:50:08 GMT


On 11/01/2017 15:55, Svetoslav Neykov wrote:
>> PS - as a near-term option if needed we could extend SoftwareProcess LATCH to do
something special if the config/sensor it is given is a "Semaphore" type
> What do you think the behaviour should be here - releasing the semaphore after the corresponding
step completes or at the end of the wrapping effector? I think this is defined by the blueprint
authors. And making this configurable adds even more complexity. Instead could invest in developing
the above functionality.

I'd probably release the latch sempahore right after the phase but I 
agree it's arbitrary and don't like that.  Only suggested it if we need 
something very quick as it's isolated and probably fairly easy in the code.

Note code exists and is run implicitly I think during the Install step 
(otherwise things like yum complain), along with I think the class is 
called SemaphoreWithOwner.

I'd LOVE to invest in the task-based functionality.  Code-wise it's not 
that far away with the type registry and YOML, but it needs a couple 
more people to become familiar with it!

Lastly I meant to say -- someone mentioned flock but the bash *sem* 
command (aka parallel) is awesome though not as well known as it should 
be.  This is an example used in zookeeper:

sudo yum install parallel

REMOVE_OLD_CMD="sed -i /server.*=/d zoo.cfg"
ADD_NEW_CMD="cat >> zoo.cfg << EOF

sem --id brooklyn --fg "$REMOVE_OLD_CMD ; $ADD_NEW_CMD"

It runs the commands in the quotes on the last line while acquiring the 
semaphore with the given name "brooklyn" on the machine.  You can 
configure semaphore counts and timeouts too.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message