Is anyone using upstart to launch stones via tODE?
Locked
Is anyone using upstart to launch stones via tODE?
 
|
Hi All,
I’ve been asked to setup an AWS image with GemStone and Seaside and I’m planning on using tODE. Everything is setup, however, I’m wondering if anyone has gone through the process of configuring upstart to start and stone stones? I’m thinking something like: initictl start gemstone STONE=myStoneName …to run the script: /opt/git/GsDevKit_home/startServer -b $STONE If anyone has had a go at this, I’d appreciate any advice, help, scripts, whatever. Perhaps an addition to GsDevKit_home for those working with upstart would be the place to keep these. I’ll set one up if no one has done this already. Thanks in advance. Cheers, Jupiter _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Is anyone using upstart to launch stones via tODE?
|
|
Hi Jupiter, I have init System V (not upstart) and monit scripts. If you think this can help you let me know and I share them with you. Best, On Tue, Nov 24, 2015 at 2:18 AM, Jupiter Jones via Glass <[hidden email]> wrote: Hi All, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Is anyone using upstart to launch stones via tODE?
|
|
In reply to this post by GLASS mailing list
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 ... 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 ... 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 .... 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` ... Dale On 11/23/2015 09:18 PM, Jupiter Jones via Glass wrote: > Hi All, > > I’ve been asked to setup an AWS image with GemStone and Seaside and I’m planning on using tODE. > > Everything is setup, however, I’m wondering if anyone has gone through the process of configuring upstart to start and stone stones? > > I’m thinking something like: > > initictl start gemstone STONE=myStoneName > > …to run the script: > > /opt/git/GsDevKit_home/startServer -b $STONE > > If anyone has had a go at this, I’d appreciate any advice, help, scripts, whatever. Perhaps an addition to GsDevKit_home for those working with upstart would be the place to keep these. I’ll set one up if no one has done this already. > > Thanks in advance. > > Cheers, > > Jupiter > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Is anyone using upstart to launch stones via tODE?
|
|
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. > 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.. > 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. 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 :) Regardless, I’m keen to get this part done and dusted. Cheers, Jupiter _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Is anyone using upstart to launch stones via tODE?
|
|
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/ _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |