[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13717517#comment-13717517 ] Mark Miller commented on SOLR-4998: --- I think for things like: - public static final String MAX_SHARDS_PER_NODE = maxShardsPerNode; + public static final String MAX_REPLICAS_PER_NODE = maxReplicasPerNode; We have to be really careful. Solr does not error/warn on unknown params - existing users might keeping using the existing param for a long time, and not even notice it no longer has an affect. I think if we make any type of change like that, we should be sure to support them as an alias or perhaps explicitly look for the old key and fail if it's found. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta Attachments: SOLR-4998.patch The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13717532#comment-13717532 ] Anshum Gupta commented on SOLR-4998: Sure, will add an alias for the same perhaps with a WARN log saying it's to be deprecated? Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta Attachments: SOLR-4998.patch The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703604#comment-13703604 ] Yonik Seeley commented on SOLR-4998: The maxShardsPerNode parameter uses shard in the incorrect sense I believe? It's kind of a questionable parameter anyway since it doesn't make sense in the context of nodes that may have different capacities. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[
https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703917#comment-13703917
]
Jack Krupansky commented on SOLR-4998:
--
bq. The maxShardsPerNode parameter uses shard in the incorrect sense I
believe?
Uhhh... and I was under the impression that it was using it the right way!
Sigh.
I wasn't following SOLR-4114 closely enough, but I do recall that when I read
it is much easier to move an entire existing shards from one Solr server to
another one that just joined the cluter than it is to split an exsiting shard
among the Solr that used to run it and the new Solr, I [mis]interpreted that
as meaning that shard meant slice or logical shard and that I could have
multiple logical shard/slice key ranges on a single node, so that as
shards/slices got too big for that single node, they could be trivially moved
to new nodes. In other words, that each node could support multiple key hash
ranges. For example, start with 64 logical shards on 4 machines at 16 logical
shards per node, and then be able to incrementally grow up to 64 logical shards
on 64 nodes without any shard splitting needed. Boy, was I wrong! Wow.
Honestly, from my recollections of the email discussions at the time, I would
have sworn on a stack of bibles that Per, et al were talking about (logical)
shards, NOT what we now refer to as replicas or physical shards.
See:
https://issues.apache.org/jira/browse/SOLR-4114
SOLR-4114 - Collection API: Allow multiple shards from one collection on the
same Solr server
Shame on me for not reading the patch carefully to see what I see now in the
code:
{code}
int maxShardsAllowedToCreate = maxShardsPerNode * nodeList.size();
int requestedShardsToCreate = numSlices * repFactor;
{code}
When what I expected was something like:
{code}
int requestedLogicalShardsPerNode = (numSlices + maxShardsPerNode - 1) /
maxShardsPerNode;
{code}
I mean, it was already easy enough to add replica nodes for SolrCloud anyway,
so the ultimate implementation did not add a great value to SolrCloud, compared
to the value it would have added if multiple logical shards could have been
supported per node.
OTOH, maybe the overhead for SplitShard is modest enough that it delivers the
same final value - scaling document capacity, as opposed to scaling query
capacity which SOLR 4114 now seems more focused on.
Oh well...
Make the use of Slice and Shard consistent across the code and document base
Key: SOLR-4998
URL: https://issues.apache.org/jira/browse/SOLR-4998
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Affects Versions: 4.3, 4.3.1
Reporter: Anshum Gupta
The interchangeable use of Slice and Shard is pretty confusing at times. We
should define each separately and use the apt term whenever we do so.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702306#comment-13702306 ] Hoss Man commented on SOLR-4998: FWIW... My opinions on the broader concerns about fixing/changing terminology... * keeping the HTTP/user/solrj based client APIs consistent should be more important then worrying about the java/internals based APIs only used inside the war * keeping the code understandable should be more important then worrying about backcompat of the java/internal based APIs only used inside the war (https://twitter.com/jeremyckahn/status/351814031054602240) My way of thinking about solrcloud (as a relative novice in this area) is... * collections are made up of distinct (logical) shards * shards are made of of redundant (concrete) replicas * replicas are implemented as (physical) SolrCores ...if i'm wrong i'm wrong -- but that seems fairly straight forward and easy to understand. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702395#comment-13702395 ] Mark Miller commented on SOLR-4998: --- bq. but people outside of here rarely use/see 'Slice' and so as Yonik suggested I don't think that's a problem in code - the javadoc defines this term and it's very simple to understand - it's very unambiguous what it means in the code. I think there are people that use it too - this is not some internal API - this java code is what you use to explore zookeeper and look at the cluster state - I know of lots of code outside the project that uses it and I'm against simply changing these APIs that have now been in use for years just so we can have getShard rather than the much less ambiguous getSlice. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702428#comment-13702428 ] Anshum Gupta commented on SOLR-4998: bq. it's very unambiguous what it means in the code The problem from how much I've explored is with the use of the term shard. It(Shard) switches back and forth between meaning what I understand as a Replica and a Slice. Having said that, all the documentation uses Shard and so the least we need to do is: 1. At least vote in and have 'shard' mean the same thing everywhere. (Slice is pretty unambiguous) 2. Document the terms Slice, Shard and Replica after we decide on how do we define a shard. I had already started to change stuff and replace 'Slice' with 'Shard'. Also, change Shard to replica wherever that's the intended use. Now I guess, I'd want to have a consensus before putting up the patch as it'd be a very high maintenance patch (for as long as stays un-committed). Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702501#comment-13702501 ] Jack Krupansky commented on SOLR-4998: -- I was going to propose that we discourage the use of the term slice outside of the core Solr code, but... that's where we run into ClusterState being exposed to the whole world in SolrJ, with slice being the preferred term there instead of shard. It is interesting that the clusterstate.json JSON itself doesn't have the terminology problem since it consists primarily of values, like shard IDs, and does in fact use shards as the map name for... slices. So, clusterstate.json and the Zookeeper browser in the Solr Admin UI seem fine, as is. Back to the ClusterState class exposed in SolrJ... it really is heavily slice oriented, but... the good news is that it's only references to shard are for shardId, with an explicit equivalence of slice and shard as in getShardId... Get the slice/shardId for a core. Replica is the main object below slice, so we don't see the logical/physical shard distinction here in ClusterState. So, I think we can finesse the problem by adding a ClusterState Javadoc caveat of Slice and shard are the same in ClusterState; slice name is the same as shard ID. Do we have any explicit doc for clusterstate.json? Not that I know of (my book will have it though in a few weeks!). The point is that the map keys below the shards map key are shard IDs. And we can note that shard ID is sometimes referred to as a slice name. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702878#comment-13702878 ] Otis Gospodnetic commented on SOLR-4998: So is CloudState really the only public exposure of slice? Why not rename it *just* there then, at least? Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702892#comment-13702892 ] Mark Miller commented on SOLR-4998: --- Being a coder and a user is two different things in my opinion. As it is we would have define shard in the code - it's ambiguous - and you are already fighting with preconceived notions of it's definition. In the code, slice is not ambiguous and calls for reading the definition of it in javadoc. It's been around for some time now, and there has been no large outcry. I'm fine with changing these API's for real gains, but I don't find this a gain given the current discussion, so I don't think the disruption in the rename is worth it at all. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[
https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702923#comment-13702923
]
Jack Krupansky commented on SOLR-4998:
--
I stumbled across this logging message as well, in
OverseerCollectionProcessor.createCollection:
{code}
for (int i = 1; i = numSlices; i++) {
for (int j = 1; j = repFactor; j++) {
String nodeName = nodeList.get((repFactor * (i - 1) + (j - 1)) %
nodeList.size());
String sliceName = shard + i;
String shardName = collectionName + _ + sliceName + _replica + j;
log.info(Creating shard + shardName + as part of slice
+ sliceName + of collection + collectionName + on
+ nodeName);
{code}
I think that could just become:
{code}
log.info(Creating replica + shardName + as part of shard
+ sliceName + of collection + collectionName + on
+ nodeName);
{code}
And in OverseerCollectionProcessor.splitShard:
{code}
log.info(Creating shard + subShardName + as part of slice
+ subSlice + of collection + collectionName + on
+ nodeName);
{code}
Could become:
{code}
log.info(Creating replica + subShardName + as part of shard
+ subSlice + of collection + collectionName + on
+ nodeName);
{code}
Make the use of Slice and Shard consistent across the code and document base
Key: SOLR-4998
URL: https://issues.apache.org/jira/browse/SOLR-4998
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Affects Versions: 4.3, 4.3.1
Reporter: Anshum Gupta
The interchangeable use of Slice and Shard is pretty confusing at times. We
should define each separately and use the apt term whenever we do so.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702926#comment-13702926 ] Jack Krupansky commented on SOLR-4998: -- bq. is CloudState really the only public exposure of slice? ClusterState has references to Slices and Slice. It also refers to DocCollection which refers to Slices/Slice. So, there are three publically exposed classes in SolrJ referring to Slices/Slice. And, for reference, CloudSolrServer#getZkStateReader().getClusterState() is how the app developer gets to ClusterState. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702934#comment-13702934 ] Anshum Gupta commented on SOLR-4998: bq. I'm fine with changing these API's for real gains, but I don't find this a gain given the current discussion, so I don't think the disruption in the rename is worth it at all. It's just an attempt to ensure that we 1. converge on a convention (Slice vs Shard) going forward. 2. Fix as much as we can in the current code, perhaps in the least invasive manner, if you suggest not changing everything. bq. I stumbled across this logging message as well, in OverseerCollectionProcessor.createCollection: That is exactly what I mean by 'shard' being used ambiguously all over. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700049#comment-13700049 ] Yonik Seeley commented on SOLR-4998: bq. But would we want it to mean what Otis mentioned/understood? I don't think so. But at this point, since we've never, ever, gotten everyone to agree on all the terminology, perhaps I'll just wait for someone to put up a patch. As Mark says, good luck ;-) Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700173#comment-13700173 ] Jack Krupansky commented on SOLR-4998: -- bq. As Mark says, good luck +1 Shard is the proper term for Solr users to be using. If you hear somebody say slice, simply remind them that they should be saying shard and otherwise presume that they do mean shard. The SolrCloud wiki glossary is the current bible on the topic, coupled with Yonik's more concise summary as collection==Listshard Shard==Listreplica. We went through a previous round of terminology debates a year ago (or whenever it was) and Yonik updated the wiki back in January. I think it is fairly stable now. The real challenge is simply to educate and otherwise cajole people to use the proper terminology. I'll do my part - I'll be starting to write the concepts and glossary sections of my coverage of SolrCloud for my book in the coming weeks. I think we should follow accepted principles of interface design, and be careful not to blur or cross the line between interface - what the outside world sees - and implementation - how the interface is implemented internally. So, at this point, I don't see any urgency to change the external definition of the SolrCloud interface - shard - yes, slice - no. But if the main concern is to recast the implementation of SolrCloud as Shard rather than Slice, at least make it clear that that is the actual purpose of this Jira. It might be useful to check any logging messages to verify that they refer to shard rather than slice. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700329#comment-13700329 ] Otis Gospodnetic commented on SOLR-4998: I am not sure what naming conventionS Solr code is using. I know most people are inconsistent and so the code is also often inconsistent. Here we see this inconsistency leads to a lot of confusion. I think it's great Anshum initiated this. My personal preference would be to: * pick the terminology that makes sense and is easy to explain and understand * adjust BOTH code and documentation to match that, even if it means renaming classes and variables, because it's only going to get harder to do that if it's not done now. OK, here is another attempt: # A Cluster has Collections # A Collection is a logical index # A Collection has as many Shards as numShards # A Shard is a logical index subset # There are as many physical instances of a given Shard as the Collection's replicationFactor # These physical instances are called Replicas # Each Replica contains a Core # A Core is a single physical Lucene index # One Replica in each Shard is labeled a Leader # Any Replica can become a Leader through election if previous Leader goes away # Each Shard has 1 or more Replicas with exactly 1 of those Replicas acting as the Leader I think this is it, no? Visually, by logical role: ||shard 1||shard 2||shard 3|| |leader 1.1|leader 2.1|leader 3.1| |replica 1.2|replica 2.2|replica 3.2| |replica 1.3|replica 2.3|replica 3.3| |replica 1.4|replica 2.4|replica 3.4| |replica 1.5|replica 2.5|replica 3.5| So we would say that the above Collection has: * 3 Shards * 5 Replicas * in each Shard 1 Replica *acts as* a Leader If we ignore roles then this same Collection has the following physical structure: |replica 1.1|replica 2.1|replica 3.1| |replica 1.2|replica 2.2|replica 3.2| |replica 1.3|replica 2.3|replica 3.3| |replica 1.4|replica 2.4|replica 3.4| |replica 1.5|replica 2.5|replica 3.5| Yes/no? Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700351#comment-13700351 ] Jack Krupansky commented on SOLR-4998: -- For amusement, consider the ElasticSearch terminology: http://www.elasticsearch.org/guide/reference/glossary/ (Hmmm... just to create trouble in the spirit of independence day, maybe I'll consider an appendix in my book which gives a terminology mapping for developers looking to upgrade from ElasticSearch to SolrCloud!) Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700386#comment-13700386 ] Mark Miller commented on SOLR-4998: --- Personally, I'm happy with the current slice/replica terminology in the code and I don't much care if it matches the external doc terminology. We have agreed and disagreed on all these points in the past, and I'm sure we will again in the future - looking forward to the next dust up - but I certainly don't think its worth breaking all those api's to change the names in the code now - unless it's a couple minor consistency issues. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700443#comment-13700443 ] Otis Gospodnetic commented on SOLR-4998: bq. http://www.elasticsearch.org/guide/reference/glossary/ Much simpler and cleaner, IMHO: * primary shard * replica shard So in ES a primary shard is a real physical thing and a replica is a real physical thing as well. I think that's easier than saying a shard is a logical concept and that inside a shard there are replicas, but some are called leaders and others are calledwell, replicas. This also allows the Collection (Index in ES terminology) creation API to take num_shards and num_replicas parameters, which is less confusing than agreeing what replicationFactor means - is it the total number of replicas in a shard or the number of non-leader replicas. It may be too late to change this in SolrCloud now even if everyone agreed... Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700450#comment-13700450 ] Anshum Gupta commented on SOLR-4998: bq. So I agree, there is really no need for Slice here. I already forgot about that term. It's just a term that we used for (what we're now calling) Shards. It's deep in the code. At the same time considering that this has the least exposure to the outside world, it's our best bet at being changed. bq. People will refer to physical copies, those Replicas, as Shards. Exactly what yonik said. There's confusion in the use of the term Shard but I believe it's just a matter of clean documentation. bq. Would introducing the term Follower help? I wouldn't want that extra element introduced. A 'leader' is just a specific non-default role for a Replica wherein it does some extra bit. Again, we could just fix our documentation on that. bq. Personally, I'm happy with the current slice/replica terminology in the code and I don't much care if it matches the external doc terminology. +1, but people outside of here rarely use/see 'Slice' and so as Yonik suggested, it seems better to converge towards 'Shard' and 'Replicas'. That is what I'm working on, doing away with 'Slice'. bq. but I certainly don't think its worth breaking all those api's to change the names in the code now - unless it's a couple minor consistency issues. This certainly would mean breaking back-compat with a few things at least. May be more. I am almost half way through and already have a good 250k patch with instances where Slice and Shard are used interchangeably. There are other places where a Replica is referred to as a Shard. So it's just all mixed up. bq. It may be too late to change this in SolrCloud now even if everyone agreed... I don't think we can/should make a change that drastic. As long as it's a little consistent and documented, Shard and Replicas should work fine for us. To get an opinion, do you guys think we shouldn't be 'touching' public APIs? Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700451#comment-13700451 ] Shalin Shekhar Mangar commented on SOLR-4998: - bq. To get an opinion, do you guys think we shouldn't be 'renaming' public APIs? Which public APIs? All public APIs already use shard instead of slice, don't they? Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700454#comment-13700454 ] Anshum Gupta commented on SOLR-4998: bq. Which public APIs? All public APIs already use shard instead of slice, don't they? To be clear, I'm talking about the Java APIs and not the HTTP calls. Calls like getSlice(), getSliceMap() etc. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700458#comment-13700458 ] Jack Krupansky commented on SOLR-4998: -- A... now we're getting somewhere. The crux of the real problem is the fact that the internal cluster state, which does of course include slice and contextual references to shards and replicas is completely exposed to the external world via CloudSolrServer.getZkStateReader().getClusterState(). Uhhh... I was thinking completely in terms of what a user needs to know in terms of query and update and overall operations, but ClusterState is a whole level deeper down in the guts of SolrCloud. Yonik, now what do you have to say?! Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699089#comment-13699089 ] Anshum Gupta commented on SOLR-4998: Here's my take on what I think these terms should refer to. Any feedback suggestions would be great: Slice: The higher level, logical representation. Shard: The entity representing any physical index belonging to a Slice. Collection has Slices Slices have Shards I'll take this up. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699094#comment-13699094 ] Mark Miller commented on SOLR-4998: --- Good luck :) Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[
https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699583#comment-13699583
]
Otis Gospodnetic commented on SOLR-4998:
bq. Slice: The higher level, logical representation.
But of what? :)
A Slice represents a set of shards: the leader shard + all its replicas in a
Collection.
{quote}
Collection has Slices
Slices have Shards
{quote}
And I thought it's:
# Cluster has Collections
# Collections are Logical Indices
# Collection has Shards
# Shards are Physical Indices
# A Shard can be a Leader or a Replica
# Leader/Replica are just Roles a Shard can have
# A Replica can become a Leader through election if previous Leader goes away
# Collection has Slices
# A Slice is a Logical Set of Shards containing the Leader + all its Replicas
# A Slice has as many Shards as the Collection's numShards
If this is right, it deserves a Wiki page.
If this is wrong, it needs a fix and then a Wiki page.
Make the use of Slice and Shard consistent across the code and document base
Key: SOLR-4998
URL: https://issues.apache.org/jira/browse/SOLR-4998
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Affects Versions: 4.3, 4.3.1
Reporter: Anshum Gupta
The interchangeable use of Slice and Shard is pretty confusing at times. We
should define each separately and use the apt term whenever we do so.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[
https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699628#comment-13699628
]
Yonik Seeley commented on SOLR-4998:
{quote}
Collection has Slices
Slices have Shards
{quote}
Currently in the code, Slices have Replicas:
Collection==ListSlice Slice==ListReplica
Currently in the external interfaces and documentation, a Slice is a shard:
collection==Listshard Shard==Listreplica
So it seems your proposal is to pick neither ;-)
Shard is a term that has been around too long and has too many meanings (which
is normally fine in English since the ambiguity is normally resolved by context
- and there are always tons of ambiguities in both spoken and written English).
In code though, context can be harder to establish and I've been trying to
stay away from shard as it has always been ambiguous (meaning either/both
logical and physical).
*If* we wanted to unify the code and external interfaces + documentation, then
the most reasonable thing would seem to be to standardize on the latter - that
way there are no back compat issues (at least at the non-code level).
What does make sense at least is making the code consistent (existing uses of
Shard changed to Slice or Replica depending on it's actual meaning). This
disambiguation would need to be done anyway, even if we decided we wanted to
change either Slice or Replica to Shard in the code.
Make the use of Slice and Shard consistent across the code and document base
Key: SOLR-4998
URL: https://issues.apache.org/jira/browse/SOLR-4998
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Affects Versions: 4.3, 4.3.1
Reporter: Anshum Gupta
The interchangeable use of Slice and Shard is pretty confusing at times. We
should define each separately and use the apt term whenever we do so.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699693#comment-13699693 ] Jan Høydahl commented on SOLR-4998: --- We should fit core in this dictionary as well. In Admin UI all you see is core. Core is the lowest level, the physical index of a shard is represented as a core, however I guess we can simplify and say shard==core? I'm all for cleaning up this terminology. When I teach courses, people are always confused by shard, replica, slice, replication factor, leader, master, slave So perhaps we should formally say Shard replica when we talk about replicas/slaves. And kill the term slice if it does not give extra value over shard. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699727#comment-13699727 ] Yonik Seeley commented on SOLR-4998: bq. We should fit core in this dictionary as well. In Admin UI all you see is core. It would be nice if we could reduce the use of core in general since it normally is a lower level implementation detail in cloud. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699745#comment-13699745 ] Anshum Gupta commented on SOLR-4998: [~otis] That's correct. Thanks for adding all of the context into it. I just wanted to get the discussion started so that we could converge and then move to the terminology. I'll create a wiki page as soon as we have a consensus on what's the best possible terminology. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699748#comment-13699748 ] Anshum Gupta commented on SOLR-4998: bq. What does make sense at least is making the code consistent (existing uses of Shard changed to Slice or Replica depending on it's actual meaning). Right, I'll be happy to move to Slice and Replica, just that it may translate to a lot of external changes. We certainly would want to be consistent between the code and the external docs/calls. That was one of my motivations to use 'Shard'. I am stil all for suggestions. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699752#comment-13699752 ] Yonik Seeley commented on SOLR-4998: bq. A Slice has as many Shards as the Collection's numShards Otis: not quite - a shard in the API is logical. http://wiki.apache.org/solr/SolrCloud#Managing_collections_via_the_Collections_API numShards: The number of logical shards (sometimes called slices) to be created as part of the collection. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4998) Make the use of Slice and Shard consistent across the code and document base
[ https://issues.apache.org/jira/browse/SOLR-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699758#comment-13699758 ] Anshum Gupta commented on SOLR-4998: But would we want it to mean what Otis mentioned/understood? i.e. Replicas to be replaced by Shards? It's just all mixed up right now. Also, I'm not sure where but I guess I have seen 'shards' used that way in the code somewhere. Make the use of Slice and Shard consistent across the code and document base Key: SOLR-4998 URL: https://issues.apache.org/jira/browse/SOLR-4998 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3, 4.3.1 Reporter: Anshum Gupta The interchangeable use of Slice and Shard is pretty confusing at times. We should define each separately and use the apt term whenever we do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
