brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yavor Yanchev <>
Subject Re: Parameterize the start effector
Date Tue, 05 Jan 2016 15:45:28 GMT

As far as I can see, implementing a non-destructive customize is a very 
good idea, but it can be software specific. In our particular case a 
customer wants to stop and then start a database software process while 
preserving the stopped installation (including VM, data, etc).

More precisely, PostgreSQL has a database initialization step which is 
part of the customize phase of the current implementation [1] and [2]. 
If PostgreSQL process is stopped and then started the database 
initialization should be skipped so the data is preserved. It might be 
the case for other database blueprints too, e.g. MySQL [3]



On 01/05/2016 04:39 PM, Alex Heneveld wrote:
> yavor-
> i like the direction this is going.  thinking aloud however would it 
> be better to recommend that install and customize are non-destructive 
> by default, with an option for destruction?  that way it does the 
> right thing on first launch, and on relaunch, with a way to force it 
> to clear.  (for install this is already the case by default; for 
> customize it is not but we could advise that best practice is for it 
> to be so.)
> and then on start we'd add optional parameters "install.forceClean" 
> and "customize.forceClean" which would delete INSTALL_DIR and RUN_DIR .
> does that stack up?
> --a
> On 05/01/2016 14:13, Yavor Yanchev wrote:
>> Hi,
>> I just want to follow up on the previous mail with some more 
>> information.
>> In Brooklyn, most of the entities expose start, stop and restart 
>> effectors. Brooklyn docs have a detailed explanation of the current 
>> start/stop/restart effectors behavior [1].
>> Many users want to start a process/service that has been stopped by 
>> them using the stop() effector. Naturally, they are trying to use the 
>> start() effector to launch the process, but not the restart() 
>> effector as it is outlined in the documentation [1]. Having start() 
>> effector executed it goes through the install+customize+launch phases 
>> which can be confusing for some of the users. Most of them will 
>> expect just the launch phase to be execute without install+customize. 
>> It can be rather problematic for some entities such as databases [1].
>> It will be very helpful to provide our users with a way so they can 
>> skip install and customize phases and just launch stopped process via 
>> the start() effector.
>> My intention is to extend the SoftwareProcess' start() effector with 
>> a new boolean parameter "skipInstallation" with "false" as its 
>> default value.
>> It can be created as a static class (StartSoftwareParameters) in the 
>> SoftwareProcess interface. Such parameter class is currently missing 
>> and start parameters are defined via the Startable interface as part 
>> of the start effector's body.
>> The proposed addition of the new parameter will require a change in 
>> the AbstractSoftwareProcessDriver as well. 
>> AbstractSoftwareProcessDriver's start() already uses a config with a 
>> similar name and meaning (install.skip).
>> *install.skip* can omit the install phase, but not the customize. We 
>> can slightly change its behavior to skip the customize phase and/or 
>> introduce an additional config which controls omitting of the 
>> customize phase.
>> WDYT?
>> Regards,
>> Yavor
>> [1] 
>> On 01/04/2016 01:11 PM, Yavor Yanchev wrote:
>>> Hi All,
>>> Happy New Year!
>>> Brooklyn uses want to be able to parameterize the start effector so 
>>> it behaves like the restart effector when a special parameter is set.
>>> What do you think about introducing a new boolean parameter called 
>>> "skipInstallation" so the start effector can skip the install and 
>>> customize steps and just launch the process?
>>> Some time ago, Aled provided a good explanation why we might need 
>>> such functionally in a comment regarding PR #792 [1].
>>> Regards,
>>> Yavor
>>> [1] 


View raw message