brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <svetoslav.ney...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] Controlling effectors concurrency
Date Wed, 11 Jan 2017 17:45:13 GMT
Sam I think that's a great approach to composing tasks and mixing them with semaphores.

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

Alex, I like that, gives you much cleaner semantics than flock.

> effectors:
>   start:
>      my-pre-launch:
>        task:  { acquire-semaphore: ... }
>        run-before: launch


Geoff, I have some reservations re init.d style naming as well. Mostly due to being too fragile
when having multiple layers of blueprints. I'm going to suggest one more alternative, somehow
similar to before/after. Instead of declaring when to run a task (before/after another task),
just override the parent task, do the work you need to and reference the parent task explicitly.

effectors:
  start:
     launch: [my-custom-launch, $super.launch]
     my-custom-launch:
     - ssh: ....

Anyway this is getting sidetracked. I agree that the task based approach is a nice place to
be longer term. Might go with extending the latches shorter term - need to think some more
about it.

What do people think about introducing the callback behaviour for effectors though? I see
it as an orthogonal concept to what's possible with composing tasks. It's a middle ground
for implementing the semaphores where the latches are too limited and "semaphores as tasks"
are still not here. Will make life easier for some more complex scenarios where one needs
to sync with/influence other entities (examples in previous emails).

Svet.



> On 11.01.2017 г., at 18:50, Alex Heneveld <alex.heneveld@cloudsoftcorp.com> wrote:
> 
> 
> Svet-
> 
> 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
> server.0=NEW
> server.1=NEW
> 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.
> 
> Best
> Alex
> 


Mime
View raw message