Fwd: Customizing an entity in YAML

[Martin Harris <ma...@cloudsoftcorp.com>]

Forwarded, as promised, wrt Alasdair's "Scriptable entity lifecycle hooks"
email

Cheers

M

---------- Forwarded message ----------
From: Alex Heneveld <al...@cloudsoftcorp.com>
Date: 1 July 2014 16:36
Subject: Re: Customizing an entity in YAML
To: dev@brooklyn.incubator.apache.org



You're right, probably more complex than needed for now.

The "clutter" I meant is just in the SoftwareProcess code.  But
{pre,post}_launch is probably worth it.

Agree with you about leaving it as a string for now.

--A



On 01/07/2014 16:20, Aled Sage wrote:

> Hi Alex,
>
> Are you thinking of using an entity initializer that (when executed on
> entity.init) does some very fancy stuff to intercept the tasks that will
> later be executed - in particular intercepting the launch task which is a
> sub-task of start? If so, that sounds powerful but complicated.
>
> What do you mean by "always cluttering it"? With Martin's scheme, we'd
> only include the config in yaml when we needed it to execute extra commands.
>
> I wondered about the config being a list as well - I backed off that
> because ListConfigKey is deprecated (because our use of the datagrid for
> storing config values is backed by a set, and is not preserving order).
> We could declare it as ConfigKey<List<String>> though.
>
> Aled
>
>
> On 01/07/2014 15:56, Alex Heneveld wrote:
>
>> We could define this as an entity initializer which wraps the
>> SoftwareProcess tasks, that way it is optionally available in yaml without
>> always cluttering it. Or okay to add always.
>>
>> It could take a list that way it could be extended multiple times.
>>
>> Best
>> Alex
>> On 1 Jul 2014 12:07, "Aled Sage" <al...@cloudsoftcorp.com> wrote:
>>
>>  Hi Martin,
>>>
>>> That makes sense. I'm slightly hesitant for us to have so many config
>>> options.
>>>
>>> For now, should we just add PRE_LAUNCH_COMMAND and POST_LAUNCH_COMMAND as
>>> I believe that meets your UserGrid use-case (to update a config file
>>> being
>>> installed into a Tomcat server, without having to write Java code that
>>> sub-classes the Tomcat7SshDriver).
>>>
>>> ---
>>> Another useful thing (based on separate chat on another UserGrid
>>> requirement) is to specify files to be uploaded. In
>>> `brooklyn.entity.messaging.qpid.QpidBroker`, there are config keys for
>>> RUNTIME_FILES and RUNTIME_TEMPLATES that are uploaded in
>>> `QpidSshDriver.customize`. It would be good to generalise these in
>>> SoftwareProcess.
>>>
>>> (MongoDBClient.JS_SCRIPTS is similar, but the MongoDBClientSshDriver.
>>> customize
>>> chooses the destination dir rather than it being part of the config
>>> values).
>>>
>>> Aled
>>>
>>> p.s. the interface is SoftwareProcess rather than
>>> AbstractSoftwareProcess.
>>>
>>>
>>> On 19/06/2014 16:19, Martin Harris wrote:
>>>
>>>  Hi Folks,
>>>>
>>>> I have a use-case where I want to deploy a Tomcat server, and once it's
>>>> launched I want to modify one of the files (inject the URL of another
>>>> node
>>>> into a config file)
>>>>
>>>> If I were doing it in Java, I'd create a custom SSH driver and override
>>>> launch, but I want to do it in YAML
>>>>
>>>> In a similar pattern to the VanillaSoftwareProcess, I'm thinking about
>>>> adding some ConfigKey<String> keys to AbstractSoftwareProcess as
>>>> follows:
>>>>
>>>> ConfigKey<String> PRE_INSTALL_COMMAND
>>>> ConfigKey<String> POST_INSTALL_COMMAND
>>>> ConfigKey<String> PRE_CUSTOMIZE_COMMAND
>>>> ConfigKey<String> POST_CUSTOMIZE_COMMAND
>>>> ConfigKey<String> PRE_LAUNCH_COMMAND
>>>> ConfigKey<String> POST_LAUNCH_COMMAND
>>>>
>>>> These would then be executed in AbstractSoftwareProcess.start()
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>>
>



-- 
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855