You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@cloudsoftcorp.com> on 2014/07/01 13:06:40 UTC
Re: Customizing an entity in YAML
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?
>
Fwd: Customizing an entity in YAML
Posted by 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
Re: Customizing an entity in YAML
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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?
>>>>
>>>>
>
Re: Customizing an entity in YAML
Posted by Aled Sage <al...@gmail.com>.
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?
>>>
>>>
Re: Customizing an entity in YAML
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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?
>>
>>
>