Just finished setting up a kvstore collection within the collections.conf and pushed it out through the deployer to our search head cluster. Per the Distributed Management Console, everything is looking good on all search head members in the cluster and I can find the collection within the settings of an actual SH member. Upon creating a new lookup definition that will reference this kvstore, I still only see 'file-base' and 'external' as options. Odd.
Decided to create another kvstore, but this time via the API. The kvstore was created successfully and per the DMC, things again were looking good and I was able to find the collection on all the SH members in the cluster. Still no 'kvstore' option when creating a lookup unfortunately.
Next tried creating the lookup manually within the transforms.conf and pushing it through the deployer. Lookup shows up on all the SH members in the cluster, although, when I open it up to review its configuration, it looks broken. The name and fields_list are there, but no mention of the kvstore collection I specified. Rather, it shows me a random CSV file and an empty 'command' field. At least it shows 'kvstore' in the type list for that specific lookup, but doesn't mean much if it's broken.
Decided to restart the specific SH I happened to be on to see if anything would change. Nothing.
Curious if anyone knows the reason for why the 'kvstore' type would be missing in a 6.2.x search head clustered environment? My testing in a stand-alone environment was successful.
I figured out and fixed the issue. FYI to those migrating apps from a 6.1.x environment over to a 6.2.x environment...be careful about the xml files located in the etc/apps/search/default/data/ui/manager directory. The datatransformslookups.xml file contains additional references for 'KV store' that our 6.1.x environment did not. Rather than using the default search app that came with 6.2.x, we replaced it with our 6.1.x version due to number of knowledge objects clients had created and didn't want to go through the work of re-creating them.
In any case, the fix was to use the new 6.2.x files that came with the product. Once everything was pushed through the deployer, things were looking good.