changing spare definitions
Merge branch 'master' of github.com:tumblr/jetpants into state_status_change

pecially if it merges an updated upstream into a topic branch.
update doc
In DB#enslave! and DB#enslave_siblings!, disable monitoring on the targets for the duration of the clone operation
Merge branch 'state_status_change' of github.com:tumblr/jetpants into state_status_change
Refactor DB#usable_spare? and Topology#query_spare_assets to allow validation check failures to include error messages. Plugins should now override DB#validate_spare instead of DB#usable_spare?, since the validation probe has been separated from the predicate.
Merge branch 'master' into state_status_change

Conflicts:
	plugins/jetpants_collins/db.rb
minor tweaks
jetpants_collins: In Shard#sync_configuration, if shard is still in :initializing state, update its pool configuration asset as normal but do NOT update any fields on its DB nodes. This way, they will not get a secondary_role prematurely, which is helpful for monitoring setups that key on that field. Also means that other concurrent jetpants runs will ignore the child shards due to having no masters, which is good, since the masters arent set up yet at this point.
need to order the spare validation checks to avoid potential fatal exceptions
Merge branch 'state_status_change'
fix syntax error from previous merge
Allow getting or setting status and state at once easily
jetpants_collins: use the new shortcut for setting status and state simultaneously in Pool#sync_configuration and Topology#claim_spares
Use new collins_status_state getting in jetpants_collins DB#validate_spare
Merge pull request #13 from tumblr/status_state_shortcut

jetpants_collins status:state shortcut
jetpants_collins: Shard#sync_configuration should set state like Pool#sync_configuration does
bump date
Starting to add support for lockless shard master promotion:
This is an alternative way to promote a master in a shard pool. Instead of
setting the old master to read_only and moving existing slaves to replicate
from the new master, we do something more like the shard split process. It
is less interruptive, but does involve two distinct configuration changes.

We build a new slave of the master, and then create new slaves off of that,
resulting in a hierarchical replication setup. Then we move reads to the
new master, followed by writes. Finally we need to eject the old master and
its old slaves from the pool entirely.

This commit just starts some of the bookkeeping changes, such as overloading
the :child state to mean "write to the shard's master's master", instead of
meaning "write to the shard's parent's master". Additionally it overloads
the :needs_cleanup state to potentially mean "eject the old nodes from this
pool". The commit includes changes to Shard#cleanup! to implement this step.
simple_tracker should implement :child state more generically now.