Charles: And it's especially trappy that the admin UI has this "cores" page. Another very significant bit of work would be revamping this too. There's work being done to move the Solr admin UI to Angular JS, maybe that'll be the avenue for this switch too.
Thanks for you comments! On Mon, Mar 30, 2015 at 10:19 AM, Reitzel, Charles <[email protected]> wrote: > As a Solr user, my feeling is that the proposal would be a significant > improvement in the product design. A significant piece of related work, imo, > would be to update all of the examples and "getting started" docs. > Likewise, isn't the plan for migration from 4.x to 5.x (wrt to maintenance, > monitoring, ETL, etc.) is affected by this issue? I feel clarity and > stability in these areas would help adoption of 5.x. > > Re: SOLR-6278, My feeling is that the term "core" could just go away with the > public API . There should be a single, clear cut way to address individual > replicas, of any given shard, within any collection. Even if there is only > one replica (the leader) and only one shard, the addressing scheme and > terminology remain the same. > > If there are functional gaps in the Collections API, fill them as needed - > perhaps by delegating to the internal "Admin" service at the node level. But > please keep the public parameters and terminology consistent. There should > be only one way to do it ... > > On Saturday, March 28, 2015 9:17 PM, Yonik Seeley [mailto:[email protected]] > wrote: >> >> On Sat, Mar 28, 2015 at 2:27 PM, Erick Erickson <[email protected]> >> wrote: >> > 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? >> >> +1, this is the position I've advocated in the past as well. >> >> -Yonik > > On Sunday, March 29, 2015 7:53 PM, Ramkumar R. Aiyengar > [mailto:[email protected]] wrote: >> >> 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. > > > ************************************************************************* > This e-mail may contain confidential or privileged information. > If you are not the intended recipient, please notify the sender immediately > and then delete it. > > TIAA-CREF > ************************************************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
