Mark Haase's comments made me look at the core admin API CREATE command and... it's a mess. We've bolted so much stuff on the core admin API to support SolrCloud that it's _really_ confusing.
Plus, we want to move toward ZK as the "one source of truth", so deprecating the external-facing core admin API seems related at least. So a couple of straw-man proposals to kick off the discussion: 1> Deprecate the core admin API (i.e. documenting it for external users) and make it internal-only. Fold any functionality we still want to support at a user level into the collections API. I mean a core on a machine is really just a single-node collection sans Zookeeper, right? 2> Simplify the user-facing bits of the core admin API, especially CREATE, to make it less trappy. Maybe just not even support at all the older way of pre-creating a directory with a conf etc. in it then creating the core and require configsets? We could nuke instanceDir, which is a confusing name now anyway. 3> Change the docs to support a simple use-case. Label the core admin API "expert" (although that's not really something we put in user's faces, more a dev thing but you get the idea). 3a> Split the docs around CREATE into a non-cloud section and an additional cloud section. 3b> stop documenting the cloud-specific bits here and consider those an implementation detail for SolrCloud. 3c> I'm really not all that enthused about considering this just a doc issue that tries to deal with both cloud and non-cloud variants. 4> ??? Note that I'm not saying _remove_ the Core Admin API, since it's what we use to implement the Collections API. Just don't expose it to the user through the documentation; make it an implementation detail I find Hasse rather abrasive, but that doesn't alter the fact that he happens to be right when he says that this stuff is hard to get right unless you're very clear what's going on from a historical perspective. Trying to support both the historical usage and the new SolrCloud usage in the same API is confusing at best. I can raise a JIRA if one hasn't been raised, didn't see one on a quick glance. Erick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
