[Glass] Is anyone using upstart to launch stones via tODE?

[Dale Henrichs via Glass]

On 11/24/2015 02:21 PM, Jupiter Jones wrote:
> Hi Dale,
>
>> Sorry I can't help with upstart, but if you are interested in sharing your work, I will create a GsDevKit/GsDevKit_upstart project where the scripts/templates can be shared …
> Thanks Dale. Mariano is going to share his sysV and monit scripts as well, so it would be good to setup repos for these as well.
3 new projects created[1][2][3]. Only added a README at this point ... 
I'll add MIT license file and then we'll see how they pan out .... My 
thoughts are that projects like these will be cloned into the 
GsDevKit_home/etc directory ....

Let me know if/when we need additional GsDevKit modules.

[1] https://github.com/GsDevKit/GsDevKit_upstart
[2] https://github.com/GsDevKit/GsDevKit_monit
[3] https://github.com/GsDevKit/GsDevKit_sysV
>
>> I'm interested in isolating the scripts/templates for upstart/monit/daemontools/nginx/etc. because my sense is that there is utility to being able to manage the production scripts under git and the model would be that the master branch would have the standard scripts and templates and then for production a branch would be used to manage the production changes …
> Absolutely! It’s the last piece of the puzzle moving from dev to production. Additionally supporting gsApplicationTools / ServiceVM / Seaside / whatever would need to be included so that not only GemStone is covered, but templates for apps using those known entry points..
I did create a GsDevKit_seaside31[4] module  ... includes bash scripts, 
tode scripts, docs and tests ... I'm almost tempted to move the scripts 
and docs into the standard Seaside31 repo, but if we were to add 
monit/upstart/sysV/nginx/lighttpd/apache module support to 
GsDevKit_seaside31, itself,then perhaps a GsDevKit_seaside31/etc would 
be a better target for the clones...

I think this is an area for experimentation and exploration and we can 
use the GsDevKit_seaside31 project as a platform for this 
experimentation ...

I think it would be really good to have a turnkey Seaside module and 
this project[4] is as good a place as any to start building it ...

[4] https://github.com/GsDevKit/GsDevKit_seaside31
>
>> By having separate git repositories for each of the subsystems, then a developer can mix and match the subsystems being used and (perhaps more importantly) to be able pick and choose which subsystems get updated and which ones to leave as is ….
> Exactly :)
>
>> For ss3, I make changes to the "template" files in-place in a git repository and then use symbolic links to hook up the "templates" with the actual system locations for lighttpd, monit and daemonetools .... I don't know if this practice (symbolic liinks) makes sense for other systems like upstart, but it is comforting to know that if I mess up some script edits, I can restore the scripts to their previous state with a simple `git checkout` ...
> I do the same thing with dns and nginx, and based on my reading of upstart, it should work the same way too.
Good ...
>
> This is part of what I was hoping to achieve with the gsDeploymentTools project, however, the amazing devOps guy that was going to contribute to the bare-metal and AWS images took a month off to travel before starting and found himself a very lucrative position in Dubai and never returned :)
oops ... bad luck...
>
> Regardless, I’m keen to get this part done and dusted.
I'm in the process of integrating feedback about GsDevKit_home from the 
Smalltalks conference ... but this is pretty much just the tweaking of 
scripts ... no major structural changes ... yet:)

It will be interesting to see how things flow here ... part of the 
underlying technology is to use Pharo for the more complicated scripting 
tasks combined with the liberal use of .ston files (like the 
sessionDescriptions and info.ston files in the stone directories) can 
replace xml files for configuration purposes ...

a seaside_deployment.ston file that listed out the various GsDevKit_ 
modules needed for deploying a production Seaside instance would then 
drive the install/maintenance process ... custom seaside_deployment.ston 
files can be created for managing things not quite covered by the 
standard GsDevKit_ modules ...

I like the idea of being able toshare standard seaside_deployment 
modules like I'm sharing the project entries[5]...

Anyway ... food for thought...

Dale

[5] http://gsdevkit.github.io/GsDevKit_home/