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
