This cookbook has been tested on the following platforms (for installing the server)
- Natty 32-bit Rubygems install
- Natty 64-bit Rubygems install
- Lucid 32-bit Vagrant
- Lucid 64-bit Vagrant
Right now, only the ubuntu-related stuff is really stubbed out. Init script templates for redhat and non-upstart debian need to be written.
The init scripts should be resilient enough to get populated with the proper path to the noah binscript. It uses
Gem.bin_path to get it.
The main reason for this is working around system rubies that do stupid crap like dump binaries in
/var/lib/gems/bin or something.
If you want to test it, the recipe you want is
This will install Noah from rubygems, compile redis from source into a self-contained directory and then create two startup scripts - noah-redis and noah.
noah::default: provides the Noah LWRP
noah::server: Installs a Noah server
noah::client: For use with Chef Server. Searches for local Noah server and sets default attributes for clients.
noah::register: Registers the current node in Noah both as a
Hostprimitive and an
If you are running with a Chef server, the best option is to use
noah::client as the first recipe in your role/run_list and
noah::register as the last recipe in your role/run_list
A single attribute is exposed for use in search. By assigning a node with this role, clients can find the local Noah server.
You can see the exposed attributes but the key server ones are:
If you're okay with it, the default install dir for everything is /var/lib/noah.
Client attributes are a bit different in how they operate based on the resource you're using
You can read more about what happens with each specific resource below.
Just the LWRP
If you just want to use the LWRP, all you need to do is add
noah::default as a dependency to your cookbook and include the recipe. This also provides additional methods in your cookbook:
The following resources are exposed by the LWRP:
noah_application- no custom parameters
Each of these resource take a common set of parameters in the DSL:
These are pulled from node attributes unless otherwise specified. With the exception of
retry_interval only take effect when the Noah server is unreachable. Errors are thrown if the connection to the Noah server times out or Noah returns anything other than a
200 response. Each resource also has a specific set of parameters related to that resource which match up with the Noah attributes
Additionally, two new methods are available that you can call to lookup information:
noah_get takes a full URL to a Noah resource and converts the JSON result to a ruby hash. The response is unaltered beyond that. If the response cannot be converted, it assumed to be an ephemeral and served "raw".
noah_search takes a Noah object type and an string. This is not a "real" search. It simply grabs all objects of the given type and looks for keys that contain the provided string. It is not a replacement for Chef's built in search.
noah_block is a special resource best used for coordinating interaction between client bootstraps. Imaging a use case where a load balancer needs to know all of the application servers. Until those application servers have bootstrapped fully, they will not be available as search results. Using Ephemerals (for now),
noah_block allows you to "block" a portion of a chef-client run until some data is available in Noah. Using the
on_failure attribute, you can either
:fail based on the results of Noah query.
Take the following example:
noah_block "wait for dbmaster" do path "http://localhost:5678/ephemerals/foo" timeout 600 data "someval1" retry_interval 5 on_failure :pass end
In this case, the client run will poll every 5 seconds for 600 seconds until it gets "someval" as a response from "http://localhost:5678/ephemerals/foo". If Noah is unreachable or it does not get the response it expects, it will simply continue with the rest of the recipe. An
on_failure value of
:fail will error out immediately. An
on_failure value of
:retry will continue retrying even if Noah is unreachable until the timeout value.
The exception to a
:pass is when the data doesn't match. It makes no sense to allow you to continue if there is data there but is not correct. Imagine the scenario where you need the value of the path to be "go" but it's "stop". If we were to pass from there, we might perform something that should not performed.
noah_block resource will retry, the
on_failure guard is to determine how to respond to an error
There's a small "test suite" of recipes included. If you include
noah::test in your run_list, it will perform a series of tests that ensure some basic functionality. The last test to run is for
noah_block and it's designed to test proper failure. This test suite will fail intentionally at the end if everything is working properly.
- DRY the code out.