Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
Subject: Re: [PROPOSAL] softwareProcess.start to have runFromPhase option
To: dev@brooklyn.incubator.apache.org
References: <55F9253F.80106@gmail.com> <55F9307D.7080401@CloudsoftCorp.com>
From: Aled Sage <aled.sage@gmail.com>
Message-ID: <55F942ED.3060606@gmail.com>
Date: Wed, 16 Sep 2015 11:22:37 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55F9307D.7080401@CloudsoftCorp.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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
>>
>>
>
>