Example Use Cases

Example Use Cases

Just a small brain dump of how one might use Noah

Application Bootstrapping

While you could have your application lookup a specific configuration in Noah, you could have it actually bootstrap by looking up a list of parameters

Create an application bootstrap configuration entry

boostrap_json = <<EOJ
{
  "configurations":["db", "queue"]
}
EOJ

a1 = Application.create(:name => 'myapp')
if a1.save
  a1.configurations << Configuration.create(:name => 'bootstrap', :format => 'json', :body => bootstrap_json, :application => a1)
end

Create specific configuration entries

a1.configurations << Configuration.create(:name => 'db', :format => 'string', :body => 'redis://127.0.0.1:6379/0', :application => a1)
mq_json = << EOQ
{
  "server":"localhost",
  "port":"5673",
  "vhost":"myapp",
  "exchange":"myexchange"
}
EOQ
a1.configurations << Configuration.create(:name => 'queue', :format => 'json', :body => mq_json, :application => a1)

In your app initialization

• GET /c/myapp/bootstrap
• Iterate over each bootstrap value, GET /c/myapp/<value>, configure given component (connect to given db, bind queue to given exchange)
• Continue application startup and notify Noah, you're online (NYI): PUT /h/myhostname/myapp/active or similar

Not only did you get your configuration from Noah but you've now registered YOURSELF as a service in Noah.

Monitoring

For example, using Nagios event handlers or even a custom notification method

• Nagios polls your service (say a RabbitMQ server) and notices it's offline.
• Nagios after given retry intervals, sends a 'notification' to Noah that a given service is offline. PUT /h/myrabbitmqserver/rabbitmq/inactive

Now your application will be aware that RabbitMQ is offline on that server and will instead buffer message locally. Your app can intermittently poll Noah for the status on a degrading interval or....

Monitoring plus Callbacks

Your app registers a Watcher for /h/myrabbitmqserver/rabbitmq with a Webhook callback. When Nagios notices that RabbitMQ is offline, it does the above steps. However since your application has registered a Webhook endpoint for status changes to that path, it now get's notified immediately.

When the server comes back online, Nagios sends an active notification to Noah which in turn triggers a callback for your application. It stops buffering messages locally and send them to the RabbitMQ server again.

Monitoring + Passive Checks

In your application code, you update Noah with your status on startup and shutdown (active/inactive) Nagios itself is a Watcher on state change via a passive service check. When Noah marks the host/service as inactive, it notifies Nagios which then triggers an alert. The process that actually registers as the Watcher and submits passive results to Nagios would be up to you to write

Usage with Chef or Puppet

Chef and puppet are AWESOME tools. I love them both. However having to update application properties via a client run and service restart is a bit ugly. Your application has to restart to pick up the new changes. Instead you could do this...

• We bring up a new Voldemort server via our CM tool.
• As part of the server bootstrapping and client run process, we register a new Host (active) and Service (inactive).
• Voldemort rebalancing process begins. At the end it notifies Noah that that /h/myserver/voldemort is active and updates the Configuration object for your application with the additional server.
• Your application (again registered as a Watcher) gets a callback that there's a new Voldemort server it can talk to and reconfigures itself

You would still configure the bootstrap urls for your application via your CM tool.