In MongoDB 3.2 with the switch to supporting config servers as replica sets we will use a uniform host targeting logic to figure out to which host to send a particular operation. This applies to both operations coming from the CatalogManager and operations coming through connections (i.e., queries, updates, etc to the config and admin databases).

This logic will not work in the transient state where customers are upgrading to config servers as replica sets, because they will have a MongoS version 3.2 backed by a legacy (3-host) config server. The shard targeting logic is not intended to work against such legacy config servers and for this reason, only legacy-style queries and update should be supported against the config or admin databases.

It is acceptable behaviour to have the find/getMore commands fail if run against 3.2 MongoS still running with a legacy confing server triplet.

As part of the find/getMore commands work we need to write tests to ensure this upconversion does not happen.