ironfan 5.0.11 → 6.0.0

data/notes/design_notes-cookbook_event_ordering.md

@@ -1,249 +0,0 @@
-# Cookbook event ordering
-
-
-Most cookbooks have some set of the following
-
-* base configuration
-* announce component
-  - before discovery so it can be found
-  - currently done in converge stage -- some aspects might be incompletely defined?
-
-* register apt repository if any
-* create daemon user
-  - before directories so we can set permissions
-  - before package install so uid is stable
-* install, as package, git deploy or install from release
-  - often have to halt legacy services -- config files don't exist
-* create any remaining directories 
-  - after package install so it has final say
-* install plugins
-  - after directories, before config files
-* define service
-  - before config file creation so we can notify
-  - can't start it yet because no config files
-* discover component (own or other, same or other machines)
-* write config files (notify service of changes)
-  - must follow everything so info is current
-* register a minidash dashboard
-* trigger start (or restart) of service
-
-## Proposal:
-
-kill `role`s, in favor of `stack`s.
-
-A runlist is assembled in the following phases:
-
-* `initial` configuration
-* `before_install`
-  - `account`
-* `install`
-  - `plugin` install
-  - `directories`
-* `announcement`
-  - `service` definition
-- `discovery`
-* `commit`
-  - `config_files`: write config files to disk
-* `finalize`
-* `launch`
-
-As you can see, most layers have semantic names (`plugin`, `user`, etc); if you name your recipe correctly, they will be assigned to the correct phase. Otherwise, you can attach them explicitly to a semantic or non-semantic phase.
-
-    elasticsearch_datanode component:
-    
-    elasticsearch::default              # initial
-    elasticsearch::install_from_release #install phase
-    elasticsearch::plugins              # plugin phase
-
-    elasticsearch::server               # service definition; includes announcement
-    elasticsearch::config_files         # config_files; includes discovery
-
-I'm not clear on how much the phases should be strictly broken out into one-recipe-per-phase.
-
-It's also possible to instead define a chef resource that let you defer a block to a given phase from within a callback. It would be similar to a ruby block, but have more explicit timing. This may involve jacking around inside Chef, something we've avoided to now.
-
-__________________________________________________________________________
-
-Run List is 
-
-    [role[systemwide], role[chef_client], role[ssh], role[nfs_client],
-    role[volumes], role[package_set], role[org_base], role[org_users], 
-    
-    role[hadoop],
-    role[hadoop_s3_keys], 
-    role[cassandra_server], role[zookeeper_server],
-    role[flume_master], role[flume_agent], 
-    role[ganglia_master],
-    role[ganglia_agent], role[hadoop_namenode], role[hadoop_datanode],
-    role[hadoop_jobtracker], role[hadoop_secondarynn], role[hadoop_tasktracker],
-    role[hbase_master], role[hbase_regionserver], role[hbase_stargate],
-    role[redis_server], role[mysql_client], role[redis_client],
-    role[cassandra_client], role[elasticsearch_client], role[jruby], role[pig],
-    recipe[ant], recipe[bluepill], recipe[boost], recipe[build-essential],
-    recipe[cron], recipe[git], recipe[hive], recipe[java::sun], recipe[jpackage],
-    recipe[jruby], recipe[nodejs], recipe[ntp], recipe[openssh], recipe[openssl],
-    recipe[rstats], recipe[runit], recipe[thrift], recipe[xfs], recipe[xml],
-    recipe[zabbix], recipe[zlib], recipe[apache2], recipe[nginx],
-    role[el_ridiculoso_cluster], role[el_ridiculoso_gordo], role[minidash],
-    role[org_final], recipe[hadoop_cluster::config_files], role[tuning]]
-
-Run List expands to 
-
-    build-essential, motd, zsh, emacs, ntp, nfs, nfs::client, xfs,
-    volumes::mount, volumes::resize, package_set, 
-    
-    hadoop_cluster,
-    hadoop_cluster::minidash, 
-    
-    cassandra, cassandra::install_from_release,
-    cassandra::autoconf, cassandra::server, cassandra::jna_support,
-    cassandra::config_files, zookeeper::default, zookeeper::server,
-    zookeeper::config_files, flume, flume::master, flume::agent,
-    flume::jruby_plugin, flume::hbase_sink_plugin, ganglia, ganglia::server,
-    ganglia::monitor, 
-    
-    hadoop_cluster::namenode, 
-    hadoop_cluster::datanode,
-    hadoop_cluster::jobtracker, 
-    hadoop_cluster::secondarynn,
-    hadoop_cluster::tasktracker, 
-    
-    zookeeper::client, 
-    hbase::master,
-    hbase::minidash, 
-    
-    minidash::server, 
-    hbase::regionserver, 
-    hbase::stargate,
-    redis, redis::install_from_release, redis::server, 
-    mysql, mysql::client,
-    cassandra::client, elasticsearch::default,
-    
-    elasticsearch::install_from_release, 
-    elasticsearch::plugins,
-    elasticsearch::client, 
-    
-    jruby, jruby::gems, 
-    
-    pig, 
-    pig::install_from_package,
-    pig::piggybank, 
-    pig::integration, 
-    
-    zookeeper, 
-    ant, bluepill, boost, cron,
-    git, hive, 
-    java::sun, jpackage, nodejs, openssh, openssl, rstats, runit,
-    thrift, xml, zabbix, zlib, apache2, nginx, hadoop_cluster::config_files,
-    tuning::default
-    
-
-From an actual run of el_ridiculoso-gordo:
-    
-      2 nfs::client
-      1 java::sun
-      1 aws::default
-      5 build-essential::default
-      3 motd::default
-      2 zsh::default
-      1 emacs::default
-      8 ntp::default
-      1 nfs::default
-      2 nfs::client
-      3 xfs::default
-     46 package_set::default
-      4 java::sun
-      8 tuning::ubuntu
-      6 apt::default
-      1 hadoop_cluster::add_cloudera_repo
-     44 hadoop_cluster::default
-      4 minidash::default
-      2 /srv/chef/file_store/cookbooks/minidash/providers/dashboard.rb
-      1 hadoop_cluster::minidash
-      2 /srv/chef/file_store/cookbooks/minidash/providers/dashboard.rb
-      1 boost::default
-      2 python::package
-      2 python::pip
-      1 python::virtualenv
-      2 install_from::default
-      7 thrift::default
-      9 cassandra::default
-      1 cassandra::install_from_release
-      6 /srv/chef/file_store/cookbooks/install_from/providers/release.rb
-      3 cassandra::install_from_release
-      1 cassandra::bintools
-      3 runit::default
-     11 cassandra::server
-      2 cassandra::jna_support
-      2 cassandra::config_files
-      6 zookeeper::default
-     15 zookeeper::server
-      3 zookeeper::config_files
-     18 flume::default
-      2 flume::master
-      3 flume::agent
-      2 flume::jruby_plugin
-      1 flume::hbase_sink_plugin
-     21 ganglia::server
-     20 ganglia::monitor
-     13 hadoop_cluster::namenode
-     11 hadoop_cluster::datanode
-     11 hadoop_cluster::jobtracker
-     11 hadoop_cluster::secondarynn
-     11 hadoop_cluster::tasktracker
-     14 hbase::default
-     11 hbase::master
-      1 hbase::minidash
-      2 /srv/chef/file_store/cookbooks/minidash/providers/dashboard.rb
-     13 minidash::server
-     11 hbase::regionserver
-     10 hbase::stargate
-      2 redis::default
-      2 redis::install_from_release
-      2 redis::default
-     16 redis::server
-      3 mysql::client
-      1 aws::default
-      7 elasticsearch::default
-      1 elasticsearch::install_from_release
-      6 /srv/chef/file_store/cookbooks/install_from/providers/release.rb
-      2 elasticsearch::plugins
-      3 elasticsearch::client
-      3 elasticsearch::config
-      1 jruby::default
-      9 /srv/chef/file_store/cookbooks/install_from/providers/release.rb
-      7 jruby::default
-     18 jruby::gems
-      2 pig::install_from_package
-      5 pig::piggybank
-      8 pig::integration
-      6 zookeeper::default
-      3 ant::default
-      5 bluepill::default
-      2 cron::default
-      1 git::default
-      1 hive::default
-      2 nodejs::default
-      4 openssh::default
-      7 rstats::default
-      1 xml::default
-     11 zabbix::default
-      1 zlib::default
-     10 apache2::default
-      2 apache2::mod_status
-      2 apache2::mod_alias
-      1 apache2::mod_auth_basic
-      1 apache2::mod_authn_file
-      1 apache2::mod_authz_default
-      1 apache2::mod_authz_groupfile
-      1 apache2::mod_authz_host
-      1 apache2::mod_authz_user
-      2 apache2::mod_autoindex
-      2 apache2::mod_dir
-      1 apache2::mod_env
-      2 apache2::mod_mime
-      2 apache2::mod_negotiation
-      2 apache2::mod_setenvif
-      1 apache2::default
-      8 nginx::default
-      9 hadoop_cluster::config_files

data/notes/design_notes-meta_discovery.md

@@ -1,59 +0,0 @@
-@temujin9 has proposed, and it's a good propose, that there should exist such a thing as an 'integration cookbook'.
-
-The hadoop_cluster cookbook should describe the hadoop_cluster, the ganglia cookbook ganglia, and the zookeeper cookbook zookeeper. Each should provide hooks that are neighborly but not exhibitionist, but should mind its own business.
-
-The job of tying those components together should belong to a separate concern. It should know how and when to copy hbase jars into the pig home dir, or what cluster service_provide'r a redis client should reference.
-
-## Practical implications
-
-* I'm going to revert out the `node[:zookeeper][:cluster_name]` attributes -- services should always announce under their cluster.
-
-* Until we figure out how and when to separate integrations, I'm going to isolate entanglements into their own recipes within cookbooks: so, the ganglia part of hadoop will become `ganglia_integration` or somesuch.
-
-## Example integrations
-
-### Copying jars
-
-Pig needs jars from hbase and zookeeper.  They should announce they have jars; pig should announce its home directory;  the integration should decide how and where to copy the jars.
-
-### Reference a service
-
-Right now in several places we have attributes like `node[:zookeeper][:cluster_name]`, used to specify the cluster that provides_service zookeeper.
-
-* Server recipes should never use `node[:zookeeper][:cluster_name]` -- they should always announce under their native cluster. (I'd kinda like to give `provides_service` some sugar to assume the cluster name, but need to find something backwards-compatible to use)
-
-* Need to take a better survey of usage among clients to determine how to do this.
-
-* cases:
-  - hbase cookbook refs: hadoop, zookeeper, ganglia
-  - flume cookbook refs: zookeeper, ganglia. 
-  - flume agents may reference several different flume provides_service'rs
-  - API using two different elasticsearch clusters
-  
-### Logging, monitoring
-
-* tell flume you have logs to pick up
-* tell ganglia to monitor you
-
-### Service Dashboard
-
-Let everything with a dashboard say so, and then let one resource create a page that links to each.
-
-
-________________________
-
-These are still forming, ideas welcome.
-
-
-
-
-Sometimes we want 
-
-* if there are volumes marked for 'mysql-table_data', use that; otherwise, the 'persistent' datastore, if any; else the 'bulk' datastore, if any; else the 'fallback' datastore (which is guaranteed to exist).
-
-* IP addresses (or hostnames):
-  - `[:private_ip, :public_ip]`
-  - `[:private_ip]`
-  - `:primary_ip`
-  
-* .  

data/notes/ec2-pricing_and_capacity.md

@@ -1,75 +0,0 @@
-## Compute Costs
-
-
-    code         	$/mo	 $/day	 $/hr	Mem/$	CPU/$	  mem 	  cpu 	cores	cpcore	storage	 disks	ebs-opt	IO
-    t1.micro		  15	  0.48	  .02	   31	   13	   .61	  0.25	  1	 0.25	      -	     0	 	Lo      
-    m1.small		  44	  1.44	  .06	   28	   17	  1.7 	  1	  1	 1	    160	     1	 	Med	
-    m1.medium		  88	  2.88	  .12	   31	   17	  3.75	  2	  2	 1	    410	     1	 	Med	
-    c1.medium		 106	  3.48	  .15	   12	   34	  1.7 	  5	  2	 2.5	    350	     1	 	Med	
-    m1.large		 175	  5.76	  .24	   31	   17	  7.5 	  4	  2	 2	    850	     2	 	Hi	
-    m1.lg+ebs		 194	  6.36	  .27	   28	   15	  7.5 	  4	  2	 2	    850	     2	  500	Hi+EBS	
-    m2.xlarge		 300	  9.84	  .41	   42	   16	 17.1 	  6.5	  2	 3.25	    420	     1	 	Med	
-    m1.xlarge		 351	 11.52	  .48	   31	   17	 15.  	  8	  4	 2	   1690	     4	 	Hi	
-    m3.xlarge		 365	 12.00	  .50	   30	   26	 15.  	 13	  4	 3.25	      -	     0	 	Med	
-    m1.xl+ebs		 387	 12.72	  .53	   28	   15	 15.  	  8	  4	 2	   1690	     4	 1000	Hi+EBS	
-    c1.xlarge		 424	 13.92	  .58	   12	   34	  7.  	 20	  8	 2.5	   1690	     4	  	Hi	
-    m2.2xlarge		 599	 19.68	  .82	   42	   16	 34.2 	 13	  4	 3.25	    850	     2	 	Hi	
-    m3.2xlarge		 731	 24.00	 1.00	   30	   26	 30.  	 26	  8	 3.25	      -	     0	 	Hi	
-    cc1.4xlarge		 950	 31.20	 1.30	   18	   26	 23.  	 33.5	  8	 4.2	   1690	     4	 	10gb	
-    m2.4xlarge		1198	 39.36	 1.64	   42	   16	 68.4 	 26	  8	 3.25	   1690	     2	 	Hi	
-    m2.4xl+ebs		1235	 40.56	 1.69	   40	   15	 68.4 	 26	  8	 3.25	   1690	     2	 1000	Hi+EBS	
-    cg1.4xlarge		1534	 50.40	 2.10	   10	   16	 22.  	 33.5	  8	 4.2	   1690	     4	 	10gb	
-    cc2.8xlarge		1753	 57.60	 2.40	   25	   37	 60.5 	 88	 16	 5.5	   3370	     2	 	10gb	
-    hi1.4xlarge		2265	 74.40	 3.10	   20	   11	 60.5 	 35.2	 16	 2.2	   2048	 ssd 2	 	10gb	
-    cr1.8xlarge		2557	 84.00	 3.50	   70	   25	244.  	 88	 16	 5.5	    240	 ssd 2	 	10gb	
-    hs1.8xlarge		3361	110.40	 4.60	   25	    8	117.  	 35	 16	 2.2	  49152	    24	 	10gb	
-
-Prices are for standard (non-reserved) instances. EBS-optimized instances are listed on their own line.
-
-
-## Storage Costs
-
-                            $/GB..mo		$/GB.mo  	$/Mio
-    EBS Volume     			$0.10
-    EBS I/O       			            	         	$0.10
-    EBS Snapshot S3			$0.083
-
-                         	Std $/GB.mo		Red.Red. $/GB.mo
-    S3 1st tb            	$0.125     	 	$0.093
-    S3 next 49tb         	$0.110     	 	$0.083
-    S3 next 450tb        	$0.095  		$0.073
-
-### Storing 1TB data
-
-(Cost of storage, neglecting I/O costs, and assuming the ratio of EBS volume size to snapshot size is as given)
-
-* http://aws.amazon.com/ec2/instance-types/
-* http://aws.amazon.com/ec2/#pricing
-
-### How much does EBS cost?
-
-The costs of EBS will be similar to the pricing structure of data storage on S3.  There are three types of costs associated with EBS.
-
-Storage Cost + Transaction Cost + S3 Snapshot Cost = Total Cost of EBS
-
-NOTE: For current pricing information, be sure to check Amazon EC2 Pricing.
-
-#### Storage Costs
-
-The cost of an EBS Volume is $0.10/GB per month.  You are responsible for paying for the amount of disk space that you reserve, not for the amount of the disk space that you actually use.  If you reserve a 1TB volume, but only use 1GB, you will be paying for 1TB.
-* $0.10/GB per month of provisioned storage
-* $0.10/GB per 1 million I/O requests
-
-#### Transaction Costs
-
-In addition to the storage cost for EBS Volumes, you will also be charged for I/O transactions. The cost is $0.10 per million I/O transactions, where one transaction is equivalent to one read or write.  This number may be smaller than the actual number of transactions performed by your application because of the Linux cache for all file systems.
-$0.10 per 1 million I/O requests
-
-#### S3 Snapshot Costs
-
-Snapshot costs are compressed and based on altered blocks from the previous snapshot backup.  Files that have altered blocks on the disk and then been deleted will add cost to the Snapshots for example.  Remember, snapshots are at the data block level.
-$0.15 per GB-month of data stored
-$0.01 per 1,000 PUT requests (when saving a snapshot)
-$0.01 per 10,000 GET requests (when loading a snapshot)
-
-NOTE:  Payment charges stop the moment you delete a volume.  If you delete a volume and the status appears as "deleting" for an extended period of time, you will not be charged for the time needed to complete the deletion.

data/notes/homebase-layout.txt

@@ -1,102 +0,0 @@
-Ironfan Homebase Layout
-=======================
-
-Your Chef Homebase contains several directories, and each contains a README.md file describing its purpose and use in greater detail.
-
-This directory structure came out of a *lot* of trial and error, and is working very well where many others didn't. This homebase makes it easy to pull in third-party pantries (cookbook collections) and track upstream changes without being locked in.
-
-## Main Directories
-
-The main assets you'll use are:
-
-* `clusters/`   - Clusters fully describe your machines, from its construction ('an 8-core machine on the Amazon EC2 cloud') to its roles ('install Cassandra, Ganglia for monitoring, and silverware to manage its logs and firewall').
-* `cookbooks/`  - Cookbooks you download or create. Cookbooks install components, for example `cassandra` or `java`.
-* `roles/`      - Roles organize cookbooks and attribute overrides to describe the specific composition of your system. For example, you install Cassandra attaching the `cassandra_server` role to your machine. (.rb or .json files)
-
-These folders hold supporting files. You're less likely to visit here regularly.
-
-* `knife/`        - Chef and cloud configuration, and their myriad attendant credentials.
-* `environments/` - Organization-wide attribute values. (.json or .rb files)
-* `data_bags/`    - Data bags are an occasionally-useful alternative to node metadata for distributing information to your machines. (.json files)
-* `certificates/` - SSL certificates generated by `rake ssl_cert` live here.
-* `tasks/`        - Rake tasks for common administrative tasks.
-* `vendor/`       - cookbooks are checked out to `vendor`; symlinks in the `cookbooks/` directory select which ones will be deployed to chef server. The vendor directory comes with the Ironfan, Opscode and (should you be a lucky customer) Ironfan Enterprise chef pantries.
-* `notes/`        - a submoduled copy of the [ironfan wiki](http://github.com/infochimps-labs/ironfan/wiki`
-
-## Directory setup
-
-The core structure of the homebase is as follows ("├─*" means "git submodule'd"):
-
-    homebase
-    ├── clusters                        - cluster definition files
-    │   └── ( clusters )
-    ├── cookbooks                       - symlinks to cookbooks
-    │   ├── @vendor/ironfan-pantry/cookbooks/...
-    │   ├── @vendor/opscode/cookbooks/...
-    │   └── @vendor/org-pantry/cookbooks/...
-    ├── environments                    - environment definition files
-    │   └── ( environments )
-    ├── data_bags                       - symlinks to data_bags
-    │   ├── @vendor/ironfan-pantry/roles/...
-    │   └── @vendor/org-pantry/roles/...
-    ├── roles                           - symlinks to roles
-    │   ├── @vendor/ironfan-pantry/roles/...
-    │   └── @vendor/org-pantry/roles/...
-    ├── vendor
-    │   ├─* ironfan-pantry              - git submodule of https://github.com/infochimps-labs/ironfan-pantry
-    │   │   ├── cookbooks
-    │   │   ├── data_bags
-    │   │   ├── roles
-    │   │   └── tasks
-    │   ├─* ironfan-enterprise          - git submodule of ironfan-enterprise, if you're a lucky customer
-    │   │   ├── cookbooks
-    │   │   ├── data_bags
-    │   │   ├── roles
-    │   │   └── tasks
-    │   ├── opscode
-    │   │   └─* cookbooks               - git submodule of https://github.com/infochimps-labs/opscode_cookbooks; itself a closely-tracked fork of https://github.com/opscode/cookbooks
-    │   └── org-pantry                  - organization specific roles, cookbooks, etc.
-    │       ├── cookbooks
-    │       ├── data_bags
-    │       ├── roles
-    │       └── tasks
-    ├── knife                           - credentials (see below)
-    ├── certificates
-    ├── config
-    ├─* notes
-    ├── tasks
-    └── vagrants                        - vagrant files (when using ironfan-ci)
-
-The `vendor/opscode/cookbooks` and `vendor/ironfan-pantry` directories are actually [git submodules](http://help.github.com/submodules/). This makes it easy to track upstream changes in each collection while still maintaining your own modifications.
-
-We recommend you place your cookbooks in `vendor/org-pantry`. If you have cookbooks &c from other pantries that have significant changes, you can duplicate it into this `vendor/org-pantry` and simply change the symlink in homebase/cookbooks/.
-
-## Knife dir setup
-
-We recommend you version your credentials directory separately from your homebase. You will want to place it under version control, but you should not place it into a central git repository -- this holds the keys to the kingdom.
-
-We exclude the chef user key (`(user).pem`) and user-specific knife settings (`knife-user-(user).rb`) from the repo as well. Each user has their own revokable client key, and their own cloud credentials set, and those live nowhere but their own computers.
-
-    knife/
-    ├── knife.rb
-    ├── credentials -> (organization)-credentials
-    ├── (organization)-credentials
-    │   ├── knife-org.rb                - org-specific stuff, and cloud assets (elastic IPs, AMI image ids, etc)
-    │   ├── (user).pem                  - your chef client key *GITIGNORED*
-    │   ├── knife-user-(user).rb        - your user-specific knife customizations *GITIGNORED*
-    │   ├── (organization)-validator.pem- chef validator key, used to create client keys
-    │   ├── client_keys
-    │   │   └── (transient client keys) - you can delete these at will; only useful if you're debugging a bad bootstrap
-    │   ├── ec2_keys
-    │   │   └── (transient client keys) - ssh keys for cloud machines (in EC2 parlance, the private half of your keypair)
-    │   ├── certificates
-    │   ├── data_bag_keys
-    │   └── ec2_certs
-    ├── bootstrap                       - knife cluster bootstrap scripts
-    ├── plugins
-    │   └── knife
-    │       └── (knife plugins)         - knife plugins
-    └── .gitignore                      - make sure not to version the secret/user-specific stuff (*-keypairs, *-credentials.rb, knife-user-*.rb)
-
-    
-(You can safely ignore the directories above that aren't annotated; they're useful in certain advanced contexts but not immediately)

data/notes/knife-cluster-commands.md

@@ -1,21 +0,0 @@
-# Ironfan Knife Commands
-
-## Available Commands
-
-Available cluster subcommands: (for details, `knife SUB-COMMAND --help`)
-
-    knife cluster list (options)                                  - show available clusters
-    knife cluster bootstrap   CLUSTER-[FACET-[INDEXES]] (options) - bootstrap all servers described by given cluster slice
-    knife cluster kick        CLUSTER-[FACET-[INDEXES]] (options) - start a run of chef-client on each server, tailing the logs and exiting when the run completes.
-    knife cluster kill        CLUSTER-[FACET-[INDEXES]] (options) - kill all servers described by given cluster slice
-    knife cluster launch      CLUSTER-[FACET-[INDEXES]] (options) - Creates chef node and chef apiclient, pre-populates chef node, and instantiates in parallel their cloud machines. With --bootstrap flag, will ssh in to machines as they become ready and launch the bootstrap process
-    knife cluster proxy       CLUSTER-[FACET-[INDEXES]] (options) - Runs the ssh command to open a SOCKS proxy to the given host, and writes a PAC (automatic proxy config) file to /tmp/ironfan_proxy-YOURNAME.pac. Only the first host is used, even if multiple match.
-    knife cluster show        CLUSTER-[FACET-[INDEXES]] (options) - a helpful display of cluster's cloud and chef state
-    knife cluster ssh         CLUSTER-[FACET-[INDEXES]] COMMAND (options) - run an interactive ssh session, or execuse the given command, across a cluster slice
-    knife cluster start       CLUSTER-[FACET-[INDEXES]] (options) - start all servers described by given cluster slice
-    knife cluster stop        CLUSTER-[FACET-[INDEXES]] (options) - stop all servers described by given cluster slice
-    knife cluster sync        CLUSTER-[FACET-[INDEXES]] (options) - Update chef server and cloud machines with current cluster definition
-    knife cluster vagrant CMD CLUSTER-[FACET-[INDEXES]] (options) - runs the given command against a vagrant environment created from your cluster definition. EARLY, use at your own risk
-
-## Examples
-

data/notes/named-cloud-objects.md

@@ -1,11 +0,0 @@
-# Named Cloud Objects
-
-To add a new machine image, place this snippet:
-
-    Chef::Config[:ec2_image_info] ||= {}
-    Chef::Config[:ec2_image_info].merge!({
-      # ... lines like this:
-      # %w[ us-west-1 64-bit ebs natty ] => { :image_id => 'ami-4d580408' },
-    })
-
-in your knife.rb or whereever. ironfan will notice that it exists and add to it, rather than clobbering it.

data/notes/philosophy.md

@@ -1,13 +0,0 @@
-## Philosophy
-
-Some general principles of how we use Chef.
-
-* *Chef server is never the repository of truth* -- it only mirrors the truth. A file is tangible and immediate to access.
-* Specifically, we want truth to live in the git repo, and be enforced by the Chef server.  This means that everything is versioned, documented and exchangeable. *There is no truth but git, and Chef is its messenger*.
-* *Systems, services and significant modifications cluster should be obvious from the `clusters` file*.  I don't want to have to bounce around nine different files to find out which thing installed a redis:server. The existence of anything that opens a port should be obvious when I look at the cluster file.
-* *Roles define systems, clusters assemble systems into a machine*.
-  - For example, a resque worker queue has a redis, a webserver and some config files -- your cluster should invoke a @whatever_queue@ role, and the @whatever_queue@ role should include recipes for the component services.
-  - the existence of anything that opens a port _or_ runs as a service should be obvious when I look at the roles file.
-* *include_recipe considered harmful* Do NOT use include_recipe for anything that a) provides a service, b) launches a daemon or c) is interesting in any way. (so: @include_recipe java@ yes; @include_recipe iptables@ no.) You should note the dependency in the metadata.rb. This seems weird, but the breaking behavior is purposeful: it makes you explicitly state all dependencies.
-* It's nice when *machines are in full control of their destiny*. Their initial setup (elastic IP, attaching a drive) is often best enforced externally. However, machines should be able independently assert things like load balancer registration which may change at any point in their lifetime.
-* It's even nicer, though, to have *full idempotency from the command line*: I can at any time push truth from the git repo to the Chef server and know that it will take hold.

data/notes/rake_tasks.md

@@ -1,24 +0,0 @@
-
-Rake Tasks
-==========
-
-The homebase contains a `Rakefile` that includes tasks that are installed with the Chef libraries. To view the tasks available with in the homebase with a brief description, run `rake -T`.
-
-Besides your `~/.chef/knife.rb` file, the Rakefile loads `config/rake.rb`, which sets:
-
-* Constants used in the `ssl_cert` task for creating the certificates.
-* Constants that set the directory locations used in various tasks.
-
-If you use the `ssl_cert` task, change the values in the `config/rake.rb` file appropriately. These values were also used in the `new_cookbook` task, but that task is replaced by the `knife cookbook create` command which can be configured below.
-
-The default task (`default`) is run when executing `rake` with no arguments. It will call the task `test_cookbooks`.
-
-The following standard Chef tasks are typically accomplished using the rake file:
-
-* `bundle_cookbook[cookbook]` - Creates cookbook tarballs in the `pkgs/` dir.
-* `install` - Calls `update`, `roles` and `upload_cookbooks` Rake tasks.
-* `ssl_cert` - Create self-signed SSL certificates in `certificates/` dir.
-* `update` - Update the homebase from source control server, understands git and svn.
-* `roles` - iterates over the roles and uploads with `knife role from file`.
-
-Most other tasks use knife: run a bare `knife cluster`, `knife cookbook` (etc) to find out more.