On 3/28/2015 12:27 PM, Erick Erickson wrote: > 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.
+1 All this sounds good to me. A somewhat unimportant curiosity: Do you anticipate that we would eventually fold the CoreAdmin functionality right into the Collections API, or would it simply remain an invisible API that an expert could use if they really wanted to? SOLR-7316 seems like a reasonable candidate for the work, but I can understand any desire to start with a clean slate on a new issue where there's no baggage. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
