bq: creating a core via API
This patch doesn't address this, at least not yet. Good point though, I'll see about adding that in.
bq: If someone messes with a core's configuration such that it fails on startup...
You always make my life more complicated <G>.... I can argue that either way, is this a fail-fast situation or is the robustness of driving on as well as possible worth the added difficulty in tracking down? The fast fix to the current patch would be just to remove the offending cores from the lists of cores (both lazily loaded and load-on-startup) and log an error.
This would imply that when someone tried to actually do something with the offending cores, they'd get a "core not found" message, which would be slightly misleading, but there'd be a big fat error (not info, not warn) in the log files so I'm not too worried. That would avoid the complexity of checking every time we tried to open a core. The important bit is to fail without screwing up the index files for the offending cores (two cores pointing to the same dataDir). I expect that the current behavior for, say two cores with the same name is that we use one or the other, perhaps not consistently. It's Not Right to do anything at all IMO.
I think in the discovery case, though, the chance of copying the same core.properties file to multiple places, thus having cores with the same name or data dir is much more likely....
So do you actively object to failing fast? Or are you ok with failing fast but your comments are intended to make sure we're considering all the angles? Initially I didn't want to make things more complicated, but by just not putting the offending cores in the relevant lists I think the complexity argument goes away and preserving index integrity is maintained so I'm +/-0.
Let me know...
+1 to failing to startup in this serious misconfiguration.