You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Alasdair Hodge <al...@cloudsoftcorp.com> on 2014/09/13 23:39:16 UTC
Scriptable entity lifecycle hooks
Brooklyn-ers,
I've encountered a few situations on customer projects where I want to
compose a simple blueprint from generic Brooklyn entities, but also need
to perform app-specific actions on the remote machines at specific
stages of the entity lifecycle. For example, I want a MySQL node, but
bootstrapping the schemas requires downloading and unpacking a ZIP file
and running multiple DDL and SQL scripts.
VanillaSoftwareProcess is undeniably cool: YAML-configurable bash
commands for install, customize, launch and post-launch actions are
immensely useful! If those same hooks were provided by the parent
SoftwareProcess class, they could be used to extend the functionality of
any concrete entity *without the need to create custom subclasses*.
Food for thought.
A.
--
Alasdair Hodge
Principal Engineer,
Cloudsoft Corporation
Re: Scriptable entity lifecycle hooks
Posted by Aled Sage <al...@gmail.com>.
Hi all,
An additional use-case from a customer recently was...
During install, the machine may need to be rebooted (perhaps even
several times). How does one split up the install commands, to
interleave them with the reboots?
---
A concrete example is the docker host setup - on some Linux
distros/versions it involves upgrading the kernel and rebooting, before
finally installing the docker packages.
---
This is possible in Java - e.g. add a sequence of tasks to call a
script, call reboot, wait for reboot complete, call next task, etc.
It is not currently possible in a "pure bash" entity (i.e. when using
VanillaSoftwareProcess with yaml).
I expect this isn't a common use-case on Linux; we need to ensure the
common-case doesn't get (much) more complicated if we add this support.
Aled
On 16/09/2014 16:28, Andrew Kennedy wrote:
> "Added install resources configuration as complement to runtime resources"
>
> - https://github.com/apache/incubator-brooklyn/pull/165
>
> I'll add some integration tests for this as well, but can someone take a
> quick look and verify this is a reasonable interim step forward?
>
> Thanks,
> Andrew.
>
Re: Scriptable entity lifecycle hooks
Posted by Andrew Kennedy <an...@cloudsoftcorp.com>.
"Added install resources configuration as complement to runtime resources"
- https://github.com/apache/incubator-brooklyn/pull/165
I'll add some integration tests for this as well, but can someone take a
quick look and verify this is a reasonable interim step forward?
Thanks,
Andrew.
--
-- andrew kennedy ? cloud engineer :
http://blog.abstractvisitorpattern.co.uk/ ;
On 16 September 2014 11:52, Andrew Kennedy <andrew.kennedy@cloudsoftcorp.com
> wrote:
> +1 to INSTALL_FILES and INSTALL_TEMPLATES as an interim measure. In fact I
> think I'll make a PR for that, as it's a simple addition. I'm currently
> writing up some notes on entity configuration and startup that documents
> these settings, will post the link when I'm done.
>
> Andrew.
> --
> -- andrew kennedy ? cloudsoft & software engineer : @grkvlt ;
> On 15 Sep 2014 19:04, "Aled Sage" <al...@gmail.com> wrote:
>
>> Hi all,
>>
>> Completely agree. The hooks we have for bash commands / scripts in
>> VanillaSoftwareProcess should be added to all "SoftwareProcess" entity
>> types (and should be extended for your additional use-cases).
>>
>> Which hooks should be exposed? Taking the MySQL example, the existing
>> lifecycle is:
>>
>> install->customize->launch->checkRunning->connectSensors->
>> waitForServiceUp->stop/kill
>>
>> Do we add pre/post for each of those? Or is that over-kill?
>>
>> ---
>> As per Martin's previous e-mail thread, we already have
>> SoftwareProcess.PRE_INSTALL_COMMAND, POST_INSTALL_COMMAND,
>> PRE_LAUNCH_COMMAND, POST_LAUNCH_COMMAND.
>>
>> We also have:
>> RUNTIME_FILES: Map of files to be copied, keyed by destination name
>> relative to runDir
>> RUNTIME_TEMPLATES: Map of templates to be filled in and copied, keyed
>> by destination name relative to runDir
>>
>> (these don't help with uploading a file to be used in pre/post
>> install, because these are applied after customize.)
>>
>> We could add INSTALL_FILES and INSTALL_TEMPLATES.
>>
>> We could also upload the RUNTIME_FILES + RUNTIME_TEMPLATES before
>> customize, rather than after (the customize step often does stuff in the
>> "runDir", such as customizing the configuration files for the ports to use
>> etc).
>>
>> ---
>> Longer term, we could support customizing the sequence of lifecycle
>> steps. e.g. it could configuration for the set of named steps, with a
>> naming convention for the hook to call during each step.
>>
>> However, that would need more thought and a lot more discussion; I'd be
>> happy to defer that for now.
>>
>> Aled
>>
>>
>> On 15/09/2014 12:46, Martin Harris wrote:
>>
>>> Hi Alasdair,
>>>
>>> This sounds similar to something I raised in an email titled "Customizing
>>> an entity in YAML" back in June. I'll forward that to the group again, as
>>> Aled and Alex had some comments on the suggestion
>>>
>>> Cheers
>>>
>>> M
>>>
>>>
>>>
>>> On 13 September 2014 22:39, Alasdair Hodge <
>>> alasdair.hodge@cloudsoftcorp.com
>>>
>>>> wrote:
>>>> Brooklyn-ers,
>>>>
>>>> I've encountered a few situations on customer projects where I want to
>>>> compose a simple blueprint from generic Brooklyn entities, but also
>>>> need to
>>>> perform app-specific actions on the remote machines at specific stages
>>>> of
>>>> the entity lifecycle. For example, I want a MySQL node, but
>>>> bootstrapping
>>>> the schemas requires downloading and unpacking a ZIP file and running
>>>> multiple DDL and SQL scripts.
>>>>
>>>> VanillaSoftwareProcess is undeniably cool: YAML-configurable bash
>>>> commands
>>>> for install, customize, launch and post-launch actions are immensely
>>>> useful! If those same hooks were provided by the parent SoftwareProcess
>>>> class, they could be used to extend the functionality of any concrete
>>>> entity *without the need to create custom subclasses*.
>>>>
>>>> Food for thought.
>>>>
>>>> A.
>>>> --
>>>> Alasdair Hodge
>>>> Principal Engineer,
>>>> Cloudsoft Corporation
>>>>
>>>>
>>>
>>>
>>
Re: Scriptable entity lifecycle hooks
Posted by Andrew Kennedy <an...@cloudsoftcorp.com>.
+1 to INSTALL_FILES and INSTALL_TEMPLATES as an interim measure. In fact I
think I'll make a PR for that, as it's a simple addition. I'm currently
writing up some notes on entity configuration and startup that documents
these settings, will post the link when I'm done.
Andrew.
--
-- andrew kennedy ? cloudsoft & software engineer : @grkvlt ;
On 15 Sep 2014 19:04, "Aled Sage" <al...@gmail.com> wrote:
> Hi all,
>
> Completely agree. The hooks we have for bash commands / scripts in
> VanillaSoftwareProcess should be added to all "SoftwareProcess" entity
> types (and should be extended for your additional use-cases).
>
> Which hooks should be exposed? Taking the MySQL example, the existing
> lifecycle is:
>
> install->customize->launch->checkRunning->connectSensors->
> waitForServiceUp->stop/kill
>
> Do we add pre/post for each of those? Or is that over-kill?
>
> ---
> As per Martin's previous e-mail thread, we already have
> SoftwareProcess.PRE_INSTALL_COMMAND, POST_INSTALL_COMMAND,
> PRE_LAUNCH_COMMAND, POST_LAUNCH_COMMAND.
>
> We also have:
> RUNTIME_FILES: Map of files to be copied, keyed by destination name
> relative to runDir
> RUNTIME_TEMPLATES: Map of templates to be filled in and copied, keyed
> by destination name relative to runDir
>
> (these don't help with uploading a file to be used in pre/post
> install, because these are applied after customize.)
>
> We could add INSTALL_FILES and INSTALL_TEMPLATES.
>
> We could also upload the RUNTIME_FILES + RUNTIME_TEMPLATES before
> customize, rather than after (the customize step often does stuff in the
> "runDir", such as customizing the configuration files for the ports to use
> etc).
>
> ---
> Longer term, we could support customizing the sequence of lifecycle steps.
> e.g. it could configuration for the set of named steps, with a naming
> convention for the hook to call during each step.
>
> However, that would need more thought and a lot more discussion; I'd be
> happy to defer that for now.
>
> Aled
>
>
> On 15/09/2014 12:46, Martin Harris wrote:
>
>> Hi Alasdair,
>>
>> This sounds similar to something I raised in an email titled "Customizing
>> an entity in YAML" back in June. I'll forward that to the group again, as
>> Aled and Alex had some comments on the suggestion
>>
>> Cheers
>>
>> M
>>
>>
>>
>> On 13 September 2014 22:39, Alasdair Hodge <alasdair.hodge@cloudsoftcorp.
>> com
>>
>>> wrote:
>>> Brooklyn-ers,
>>>
>>> I've encountered a few situations on customer projects where I want to
>>> compose a simple blueprint from generic Brooklyn entities, but also need
>>> to
>>> perform app-specific actions on the remote machines at specific stages of
>>> the entity lifecycle. For example, I want a MySQL node, but bootstrapping
>>> the schemas requires downloading and unpacking a ZIP file and running
>>> multiple DDL and SQL scripts.
>>>
>>> VanillaSoftwareProcess is undeniably cool: YAML-configurable bash
>>> commands
>>> for install, customize, launch and post-launch actions are immensely
>>> useful! If those same hooks were provided by the parent SoftwareProcess
>>> class, they could be used to extend the functionality of any concrete
>>> entity *without the need to create custom subclasses*.
>>>
>>> Food for thought.
>>>
>>> A.
>>> --
>>> Alasdair Hodge
>>> Principal Engineer,
>>> Cloudsoft Corporation
>>>
>>>
>>
>>
>
Re: Scriptable entity lifecycle hooks
Posted by Aled Sage <al...@gmail.com>.
Hi all,
Completely agree. The hooks we have for bash commands / scripts in
VanillaSoftwareProcess should be added to all "SoftwareProcess" entity
types (and should be extended for your additional use-cases).
Which hooks should be exposed? Taking the MySQL example, the existing
lifecycle is:
install->customize->launch->checkRunning->connectSensors->waitForServiceUp->stop/kill
Do we add pre/post for each of those? Or is that over-kill?
---
As per Martin's previous e-mail thread, we already have
SoftwareProcess.PRE_INSTALL_COMMAND, POST_INSTALL_COMMAND,
PRE_LAUNCH_COMMAND, POST_LAUNCH_COMMAND.
We also have:
RUNTIME_FILES: Map of files to be copied, keyed by destination name
relative to runDir
RUNTIME_TEMPLATES: Map of templates to be filled in and copied,
keyed by destination name relative to runDir
(these don't help with uploading a file to be used in pre/post
install, because these are applied after customize.)
We could add INSTALL_FILES and INSTALL_TEMPLATES.
We could also upload the RUNTIME_FILES + RUNTIME_TEMPLATES before
customize, rather than after (the customize step often does stuff in the
"runDir", such as customizing the configuration files for the ports to
use etc).
---
Longer term, we could support customizing the sequence of lifecycle
steps. e.g. it could configuration for the set of named steps, with a
naming convention for the hook to call during each step.
However, that would need more thought and a lot more discussion; I'd be
happy to defer that for now.
Aled
On 15/09/2014 12:46, Martin Harris wrote:
> Hi Alasdair,
>
> This sounds similar to something I raised in an email titled "Customizing
> an entity in YAML" back in June. I'll forward that to the group again, as
> Aled and Alex had some comments on the suggestion
>
> Cheers
>
> M
>
>
>
> On 13 September 2014 22:39, Alasdair Hodge <alasdair.hodge@cloudsoftcorp.com
>> wrote:
>> Brooklyn-ers,
>>
>> I've encountered a few situations on customer projects where I want to
>> compose a simple blueprint from generic Brooklyn entities, but also need to
>> perform app-specific actions on the remote machines at specific stages of
>> the entity lifecycle. For example, I want a MySQL node, but bootstrapping
>> the schemas requires downloading and unpacking a ZIP file and running
>> multiple DDL and SQL scripts.
>>
>> VanillaSoftwareProcess is undeniably cool: YAML-configurable bash commands
>> for install, customize, launch and post-launch actions are immensely
>> useful! If those same hooks were provided by the parent SoftwareProcess
>> class, they could be used to extend the functionality of any concrete
>> entity *without the need to create custom subclasses*.
>>
>> Food for thought.
>>
>> A.
>> --
>> Alasdair Hodge
>> Principal Engineer,
>> Cloudsoft Corporation
>>
>
>
Re: Scriptable entity lifecycle hooks
Posted by Martin Harris <ma...@cloudsoftcorp.com>.
Hi Alasdair,
This sounds similar to something I raised in an email titled "Customizing
an entity in YAML" back in June. I'll forward that to the group again, as
Aled and Alex had some comments on the suggestion
Cheers
M
On 13 September 2014 22:39, Alasdair Hodge <alasdair.hodge@cloudsoftcorp.com
> wrote:
> Brooklyn-ers,
>
> I've encountered a few situations on customer projects where I want to
> compose a simple blueprint from generic Brooklyn entities, but also need to
> perform app-specific actions on the remote machines at specific stages of
> the entity lifecycle. For example, I want a MySQL node, but bootstrapping
> the schemas requires downloading and unpacking a ZIP file and running
> multiple DDL and SQL scripts.
>
> VanillaSoftwareProcess is undeniably cool: YAML-configurable bash commands
> for install, customize, launch and post-launch actions are immensely
> useful! If those same hooks were provided by the parent SoftwareProcess
> class, they could be used to extend the functionality of any concrete
> entity *without the need to create custom subclasses*.
>
> Food for thought.
>
> A.
> --
> Alasdair Hodge
> Principal Engineer,
> Cloudsoft Corporation
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855