Sounds good to me, except that we have to reconcile some of the objections in the past to collection API additions, like with https://issues.apache.org/jira/SOLR-6278
In short, collection API provides you a way to operate on collections. Operationally you would often also want functionality based off physical location (e.g. I need to decommission this machine, so boot and delete everything on it), core admin appeared to be the place for it.. On 28 Mar 2015 18:28, "Erick Erickson" <[email protected]> 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. > > Erick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
