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
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
