brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] Controlling effectors concurrency
Date Wed, 11 Jan 2017 14:25:53 GMT

svet, all,

lots of good points.

the idea of "lifecycle phases" in our software process entities has 
grown to be something of a monster, in my opinion.  they started as a 
small set of conventions but they've grown to the point where it's the 
primary hook for yaml and people are wanting "pre.pre.install".

it's (a) misguided since for any value of N, N phases is too few and (b) 
opaque coming from a java superclass.

a lot of things rely on the current SoftwareProcess so not saying we 
kill it, but for the community it would be much healthier (in terms of 
consumers) to allow multiple strategies and especially focus on *the 
reusability of tasks in YAML* -- eg "provision" or "install template 
files" or "create run dir" -- so people can write rich blueprints that 
don't require magic lifecycle phases from superclasses.

the "init.d" numbered approach svet cites is one way these are wired 
together, with extensions (child types) able to insert new numbered 
steps or override with the number and label.  but that would be one 
strategy, there might be simpler ones that are just a list, or other 
sequencing strategies like precondition/action/postcondition or 
runs-before/runs-after (where to extend something, you can say 
`my-pre-customize: { do: something, run-before: launch, run-after: 
customize }`).

we're not sure exactly how that would look but wrt mutex logic the idea 
that adjuncts plug into the entity lifecycles feels wrong, like it's 
pushing for more standardisation in lifecycle phases where things can 
plug in.   whereas with a task approach we can have effector definitions 
being explicit about synchronization, which i think is better.  and if 
they want to make that configurable/pluggable they can do this and be 
explicit about how that is done (for instance it might take a config 
param, even a config param (or child or relation) which is an entity and 
call an effector on that if set).

concretely in the examples i'm saying instead of ENRICHER APPROACH

         memberSpec:
           $brooklyn:entitySpec:
             type: cluster-member
             brooklyn.enrichers:
             - type: org.apache.brooklyn.enricher.stock.AquirePermissionToProceed
               brooklyn.config:
                 stage: post.provisioning
                 # lifecycle stage "post.provisioning" is part of cluster-member and
                 # the enricher above understands those stages

we concentrate on a way to define tasks and extend them, so that we 
could instead have a TASK APPROACH:

         memberSpec:
           $brooklyn:entitySpec:
             type: cluster-member
             effectors:
               start:
                 035-pre-launch-get-semaphore: { acquire-semaphore: ... }
                 # assume 040-launch is defined in the parent "start" yaml defn
                 # using a new hypothetical "initd" yaml-friendly task factory,
                 # acquire-semaphore is a straightforward task;
                 # scope can come from parent/ancestor task,
                 # also wanted to ensure mutex is not kept on errors

or

         memberSpec:
           $brooklyn:entitySpec:
             type: cluster-member
             effectors:
               start:
                 my-pre-launch:
                   task:  { acquire-semaphore: ... }
                   run-before: launch
                   run-after: customize
                   # launch and customize defined in the parent "start" yaml defn,
                   # using a new hypothetical "ordered-labels" yaml-friendly task factory;
                   # acquire-semaphore and scope are as in the "initd" example


both approaches need a little bit of time to get your head around the 
new concepts but the latter approach is much more powerful and general.  
there's a lot TBD but the point i'm making is that *if we make tasks 
easier to work with in yaml, it becomes more natural to express 
concurrency control as tasks*.


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

best
alex


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