Writing software is 10% inspiration, 90% grepping through source from github trying to find how the broken internals of a third party dependency work.
- me
It seems like a joke, like something that just couldn’t possibly be true. But in today’s world of increasingly componentized software units, we find ourselves spending a disproportionate amount of time figuring out how and why some 3rd party library works, or doesn’t work.
*shudder*
Thank goodness for OSS.
Today’s “OSS cave” was foreman. Foreman is great, but we are using it to export upstart configuration files and the config files it created result in orphaned processes after a new deploy.
As it turns out this is a long-standing known issue: #97. In the issue, jarthod has a resolution which involves using a customized template to generate a working upstart configuration file. What’s non-obvious is how to incorporate this custom template.
The foreman upstart
exporter
uses three templates: upstart/master.conf.erb,
upstart/process_master.conf.erb, and upstart/process.conf.erb.
jarthod offered a replacement for process.conf.erb.
After looking through the command line options and the source for the upstart exporter, the answer was fairly easy.
process.conf.erb in any folder you like-t option to specify a custom template
directory: foreman export upstart /etc/init -t path/to/templates/The documentation
says that the foreman exporter base
class
uses the method export_template which looks for templates in 3
locations: the -t command-line provided option,
~/.foreman/templates, and finally the templates shipped with the gem
itself.
The trick is that if you look at the source for the default upstart
exporter, you might be tempted to put the templates in an upstart/
subdirectory, but templates from the -t command-line option are looked
for just in the root of that directory.
After writing all that down, it seems STUPIDLY SIMPLE. Because it is. But yet it took longer than I wish to find and/or figure all that out. Ugh.