"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 <[email protected] > 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" <[email protected]> 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 < >>> [email protected] >>> >>>> 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 >>>> >>>> >>> >>> >>
