What it says on the tin. The ES integration basically just starts injecting documents into the index. This works unless you've got auto_create_index set to false in which case ES will spit back at you that it couldn't create the index when trying to run bin/search index
(for a bit of background: we've got this set to false at WMF because ES has a bad habit of not creating indexes exactly as we'd like them so we don't trust it to and have an index-creation script ourselves)
auto_create_index is on by default, right? Users would have had to turn it off explicitly when configuring ElasticSearch, and we'd compensate for this by checking for the value of the setting and then printing a warning reminding them about the configuration change they made? Or is the way we're inserting documents fundamentally incorrect?
No, nothing incorrect about your usage, just need to detect the scenario and error out properly. There's two workarounds:
- Disable the setting completely, create your index, turn the setting back to how you had it
- Configure the setting to whitelist the phabricator* index and blacklist the others.
We'll be doing the latter probably.
Actually, we can work around this quite nicely after talking with folks. If auto_create_index is set to false, we just need to create an empty index and it'll figure out the mapping when the first document is inserted. In ES speak, it's just issuing a simple PUT to the bare index that doesn't exist yet: curl -s -XPUT <es-host>:9200/<index-name>
Two ways to do this I can see:
- Either adding some sort of initialization method to PhabricatorSearchEngine
- Catching the failure, trying to create the index, then bailing if we can't (or if it happens a second time).