Skip to content


Subversion checkout URL

You can clone with
Download ZIP


read config file for graphite URL #15

wants to merge 1 commit into from

4 participants


I wanted to use apache + passenger to serve up Tasseo and I needed another way to pass the graphite URL. I realized that a config file might be needed at some point so I added this for my own benefit. Include it if you like it. I also have a sample apache vhost config in another commit on my fork.


Why can't you use ENV?


Using config files for configuration values is imho an antipattern (see Going to pass on this, thanks though.

@obfuscurity obfuscurity closed this

Ok. Thanks for the reading material.


I was just reading the README for tasseo and came across this quote: "Here's an example configuration that you could put in e.g. dashboards/example.js". Is it suggesting that we store configuration options in a file?


@wfaulk Application configuration options are not stored in files. Dashboard definitions are stored in js files.


How does one provide configuration options to the application? Do you have to toggle them into the registers by hand? Only ever start the application at an interactive command line?


There is only one mandatory configuration option (GRAPHITE_URL) and a handful of optional settings (GRAPHITE_AUTH and OAuth-specific ones). They are passed into the application as environment variables ("config vars").


Where are the values for the environment variables stored before the application is started?

b commented

In the environment, hence the name. See the documentation link Jason provided above.


Yes, I understand the concept of environment variables. What I don't understand is where their values come from if they're not in a file. It's not like they spring fully instantiated from the forehead of Zeus.


@wfaulk You can certainly store environment variables in a file if you choose to. It's done with shell scripts and other applications all the time.


So, to be clear, you're okay with other people storing configuration information in files as long as it's not you. So you want people to come up with their own ad-hoc methods of storing configuration for your application? And you think that makes more sense than having a well-defined place and method?

From your referenced whitepaper:

there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place

It seems like you're doing far more to enforce this diaspora of config files across a system than you're doing to help it. Ultimately, an admin who's familiar with configuring your application in one environment, when he moves to a different environment, will be forced to perform a lot of research to find where the person who initially installed tasseo decided to store that config info. It's a lot easier to look at the args list of a running application for a config file location or examine the program for a default config file location (or even assume it's probably in /etc) than trace back through the calling stack to find where some random file was loaded to populate the environment variables. Yeah, hopefully it's documented somewhere, but then you've just added another layer of documentation dispersal.

For someone who's writing software aimed at sysadmins, you sure fail to understand what makes an application easy to administer.

You can obviously write your program however you want. And I can choose a different application. Which I have done. Thanks for your time.


@wfaulk I appreciate your insightful feedback but I remain unconvinced that using environment variables for runtime configuration values is an impedance to proper system or application administration. I've been a Systems Administrator for the better part of 15 years, so I like to think I've seen a wide variety of deployment strategies. I can tell you where I think you should put your vars, but someone else would argue against that. All I can do is tell you where the baseline should be; it's up to you to implement the specifics within your own boundaries and limitations.

I'm glad that you've found a solution that meets your needs. Thanks again for your feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 9, 2012
  1. @bwhaley
This page is out of date. Refresh to see the latest.
1  config/.gitignore
@@ -0,0 +1 @@
1  config/tasseo.yaml-sample
@@ -0,0 +1 @@
+:graphite: http://graphite-server
8 public/d/.gitignore
@@ -1,7 +1 @@
-var metrics =
- {
- "alias": "test metric",
- "target": ""
- }
2  views/index.haml
@@ -37,7 +37,7 @@
- if dashboard
- var url = "#{ENV['GRAPHITE_URL']}";
+ var url = "#{url}";
%script{ :type => "text/javascript", :src => "/d/#{dashboard}.js" }
%script{ :type => "text/javascript", :src => "/j/tasseo.js" }
- else
8 web.rb
@@ -1,6 +1,7 @@
require 'sinatra'
require 'rack-ssl-enforcer'
require 'haml'
+require 'yaml'
module Tasseo
class Application < Sinatra::Base
@@ -12,6 +13,7 @@ class Application < Sinatra::Base
before do
+ @config = YAML.load_file(File.expand_path("../config/tasseo.yaml", __FILE__))
@@ -29,6 +31,7 @@ def find_dashboards
haml :index, :locals => {
:dashboard => nil,
:list => @dashboards,
+ :url => @config[:graphite],
:error => nil
@@ -43,7 +46,10 @@ def find_dashboards
get %r{/([\S]+)} do
path = params[:captures].first
if @dashboards.include?(path)
- haml :index, :locals => { :dashboard => path }
+ haml :index, :locals => {
+ :dashboard => path,
+ :url => @config[:graphite]
+ }
haml :index, :locals => {
:dashboard => nil,
Something went wrong with that request. Please try again.