Hi Alex,
Good points.
---
I don't think entity config (or a global flag) meets the requirement.
The use-case is that Brooklyn was used to start the entity initially
(including install), and now they want to call an effector to ensure it
is (still) launched.
That implies either separate effectors (e.g. "restart" the second time),
or parameterising "start".
---
A parameter on restart might well make sense. However, it's not just
stopProcessMode=never. They want to safely call it even if the process
is running, so allowing it to be guarded with a driver.isRunning check
would make sense.
---
For idempotent steps, agreed that's the aim but it would be very strict
to have it as a requirement. There are no doubt entities out there that
fail to meet this requirement (including customers' private entities).
For example, bin/start.sh script for some entities would often fail with
a non-zero exit code if the port is not available because an instance is
already running.
Some start.sh scripts might even launch a second process!
If implemented with `sudo service <name> start` then it will hopefully
cope a lot better with already running (i.e. returning exit code 0).
---
For some entities, the customise phase is not idempotent.
For example, the Postgres entity would run the database creation step
again, which could be very bad if a user wrote that sql to first drop
pre-existing tables!
Improving these entities would certainly be a good thing.
---
> feels like it's a global flag never to run install, not a per-call
option -- which in any
> case would be meaningless if you didn't also change the initial start!
Not sure I follow. Once the entity has been started (and thus
installed), it's valid to call the "launch" phase by itself (which is
what "restart" relies on). We also want to be able to call it without
first worrying if it is already running.
Aled
On 16/09/2015 10:03, Alex Heneveld wrote:
Aled-
Should this be config on the entity rather than a param on the start
effector ?
And or should it maybe be a parameter on *restart* cf stop's
STOP_PROCESS_MODE NEVER ?
It weakly feels wrong to put this on "start" because normally it would
have no effect after the first invocation. In general things should
be written so that all steps are idempotent; the default install is
no-op if Brooklyn has already run the install, and most entities will
further simply check whether the required processes are installed and
do nothing if it is (either explicitly or relying on apt-get / yum's
behaviour for the same). So new entities could be written such that
installation is no-op if launch is already possible; for existing
entities where install might change the launch ideally they'd change
the entity but if that's not possible then it feels like it's a global
flag never to run install, not a per-call option -- which in any case
would be meaningless if you didn't also change the initial start!
Best
Alex
On 16/09/2015 09:15, Aled Sage wrote:
Hi all,
A customer has asked that we add more configuration options to the
softwareProcess.start() effector. They want to just launch the
process, skipping previous phases like install/customize.
They are looking for more symmetry with stop, where there are options
for `stopProcessMode` and `stopMachineMode` that can be set to
ALWAYS, IF_NOT_STOPPED or NEVER.
The use-case is that their own customers can stop a process (e.g. for
maintenance). They want a safe way to ensure the process is running.
To do this, they currently call restart - this will first stop the
process (if it is not already running) and then launch the process
without going through install/customize. However, they want a way
that does not first stop the process, and does not require them to
first inspect the sensor to see if it is running.
This implies that if the process is already running, then it should
be a no-op.
_*Proposal for SoftwareProcess.start*_
I propose that we add an optional parameter `String runFromPhase` for
the start effector. This would have valid values of "install",
"customize" and "launch" (though other entities could be written that
understood other phases). If blank, then all phases would be run.
If "launch" were specified, then the pre-launch and post-launch would
still be run. Same for install/customize.
We would also change the call to launch, to only call driver.launch
if driver.isRunning is false.
For entities written in pure YAML, the same thing applies: commands
are supplied for isRunning, launch, etc.
Entity authors would be encouraged to:
* Always implement isRunning (and not just return "true", as I've seen
some people do!)
* Make launch idempotent, where possible.
_*Alternative for SoftwareProcess.start (not to be done)*_
The customer proposed a `skipInstallation` boolean parameter.
However, that does not convey whether "customize" would be skipped. I
also have a personal preference for parameter names to be positively
named, rather than negatively named (e.g. runInstallation defaulting
to true, rather than skipInstallation defaulting to false).
_*Consistency with SoftwareProcess.restart*_
I'd also like to make the configuration options more consistent
between SoftwareProcess.stop() and restart().
The restart effector has restartMachine, with options "true", "false"
and "auto" (versus ALWAYS, IF_NOT_STOPPED, and NEVER for stop).
_*Other info*_
There are semi-related configuration options of
SKIP_ENTITY_START_IF_RUNNING and SKIP_ENTITY_START. However, these
are configured on the entity (or location), rather than as parameters
passed to the start method.
If start's runFromPhase was blank, then these parameters would be used.
If start's runFromPhase was supplied, then that would override the
entity's configuration.
Aled
