I've realized that this case isn't actually useful, so I'm going to leave it out of the new cookbook.

The only time this could end up finding usable snapshots is if a snapshooting mongod instance had its volumes from a previous life mounted before it got to this point (after failover, if the old volumes were re-mounted). But in this case the volumes themselves should already contain fresher data than the snapshots, and in rare cases where that might not be true (filesystem corruption, etc), manual human intervention is required anyway.

Note that snapshooting replica set members will still find themselves from the above condition. More testing needs to be done of failover for the snapshooter node itself, but I think it will often also find the node that was its past life (unless it has already been cleaned up from the Chef server), and that is something that *is* useful.

There are ways of making snapshot location smarter if we decide it's necessary. One approach I've been considering is to cut out the Chef server entirely and add tags to EBS volumes and/or snapshots, then query the AWS API to find relevant snapshots, but this would be a major change and probably isn't worth the time/effort for now.