[GitHub] [lucene-solr] gus-asf commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664125851 > > These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: > > There is no way to have a "machine" abstraction in Solr. We can start of a `Node` as an atomic unit. I wanted to carefully avoid the class names already taken up so that existing code can be left as it is Yeah machine is a difficult notion as it's a real world thing entirely outside java. It probably has to be optional and provided by sysprop or env var. and even so might be reducible to a property on node. Certainly detecting it would be fraught with peril. But machine designations (and rack designations) might be important to some folks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14681) Delete Jar with Command
[ https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165427#comment-17165427 ] Vantagepointx commented on SOLR-14681: -- Hi, Very informative post and really appreciate the effort you put into it. Every one now a days is trying to gather more information about http://www.vantagepointx.com/ />Forex Trading . > Delete Jar with Command > --- > > Key: SOLR-14681 > URL: https://issues.apache.org/jira/browse/SOLR-14681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Major > > We need to build logic that will delete a jar that represents a package. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14681) Delete Jar with Command
[ https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165410#comment-17165410 ] Marcus Eagan commented on SOLR-14681: - [SOLR-14604 |https://issues.apache.org/jira/browse/SOLR-14604]needs this > Delete Jar with Command > --- > > Key: SOLR-14681 > URL: https://issues.apache.org/jira/browse/SOLR-14681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Major > > We need to build logic that will delete a jar that represents a package. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14681) Delete Jar with Command
Marcus Eagan created SOLR-14681: --- Summary: Delete Jar with Command Key: SOLR-14681 URL: https://issues.apache.org/jira/browse/SOLR-14681 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Package Manager Affects Versions: master (9.0) Reporter: Marcus Eagan We need to build logic that will delete a jar that represents a package. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664094145 > Can we start simple by defining the external interface without the required changes to internal classes first? Will make a smaller PR easier to discuss. Feel free to ignore the implementing classes. That was to demonstrate one way of implementing these interfaces. I'm happy to focus on the interfaces inside the `sdk` package This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460627824
##
File path:
solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrCollection.java
##
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/** Represents a collection in Solr */
+public interface SolrCollection {
Review comment:
That should be a utility method outside
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460627654
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrCluster.java
##
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/**
+ * Represents a Solr cluster
+ */
+public interface SolrCluster {
+ /** collections in the cluster */
+ SimpleMap collections();
Review comment:
Yes, I wanted to include aliases. Where do you propose it to be there.
I would say , There should be no `Alias` class/interface.
It should be as simple as
`SolrCluster#collections#get(String name , include alias) `
and
` SolrCollection#aliases() returns List`
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrCluster.java
##
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/**
+ * Represents a Solr cluster
+ */
+public interface SolrCluster {
+ /** collections in the cluster */
+ SimpleMap collections();
Review comment:
Yes, I wanted to include aliases. Where do you propose it to be there?
I would say , There should be no `Alias` class/interface.
It should be as simple as
`SolrCluster#collections#get(String name , include alias) `
and
` SolrCollection#aliases() returns List`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460626596
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrCluster.java
##
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/**
+ * Represents a Solr cluster
+ */
+public interface SolrCluster {
Review comment:
I know. Imagine this will also be used outside of Solr as a part of
SolrJ. So if you read some client code,
`Cluster cluster;`
is less readable compared to
`SolrCluster solrCluster`;
Eventually, I would wish to replace a lot of SolrJ code/API with a standard
set of interfaces.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664095650 >These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: There is no way to have a "machine" abstraction in Solr. We can start of a `Node` as an atomic unit. I wanted to carefully avoid the class names already taken up so that existing code can be left as it is This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664094746 >I also feel this PR has a lot of overlap with the one I started to define an API for Autoscaling plugins #1684 Yes, totally.That ticket is trying to do something more than the scope of that ticket. I want to limit the scope of that ticket and have wider discussion on how a simple set of interfaces to represent the existing Solr cluster/cloud This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
chatman commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460623863
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/ClusterState.java
##
@@ -38,7 +43,7 @@
* {@link ZkStateReader#getClusterState()}.
* @lucene.experimental
*/
-public class ClusterState implements JSONWriter.Writable {
+public class ClusterState implements JSONWriter.Writable , SolrCluster {
Review comment:
Let's rename Solr luster to Cluster.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460624050
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrNode.java
##
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/**
+ * A read only view of a Solr node
+ */
+public interface SolrNode {
+
+ /** The node name */
+ String name();
+
+ String baseUrl(boolean isV2);
+
+ SimpleMap cores();
Review comment:
I would say, that is something that can be easily computed from the
`cores()` method and can be provided as a helper method elsewhere
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460622520
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/ClusterState.java
##
@@ -38,7 +43,7 @@
* {@link ZkStateReader#getClusterState()}.
* @lucene.experimental
*/
-public class ClusterState implements JSONWriter.Writable {
+public class ClusterState implements JSONWriter.Writable , SolrCluster {
Review comment:
We can have multiple implementations of `SolrCluster` .The idea of
existing classes implementing these interfaces is to have readily available
implementations
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
noblepaul commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460622100
##
File path:
solr/solrj/src/java/org/apache/solr/common/util/LinkedSimpleHashMap.java
##
@@ -0,0 +1,27 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.common.util;
+
+import java.util.LinkedHashMap;
+
+public class LinkedSimpleHashMap extends LinkedHashMap
implements SimpleMap {
Review comment:
yes, this was to demonstrate how to implement a default impl of
`SimpleMap`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11868) Deprecate CloudSolrClient.setIdField, use information from Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165394#comment-17165394 ] David Smiley commented on SOLR-11868: - Maybe also file an issue to make "id" the only allowed uniqueKey? If you agree with that, I could imagine a further simplification such that we could remove uniqueKey from the schema as well. Either you specify "id" or you don't; no need for more schema elements (complexity). > Deprecate CloudSolrClient.setIdField, use information from Zookeeper > > > Key: SOLR-11868 > URL: https://issues.apache.org/jira/browse/SOLR-11868 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > > IIUC idField has nothing to do with the field. It's really > the field used to route documents. Agreed, this is often the "id" > field, but still > In fact, over in UpdateReqeust.getRoutes(), it's passed as the "id" > field to router.getTargetSlice() and just works, even though > getTargetSlice is clearly designed to route on a field other than the > if we didn't just pass null as the "route" param. > The confusing bit is that if I have a route field defined for my > collection and want to use CloudSolrClient I have to figure out that I > need to use the setIdField method to use that field for routing. > > We should deprecate setIdField and refactor how this is used (i.e. > getRoutes). Need to beef up tests too I suspect. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664078634 While marking things internal and external is good, a stronger possibility is to code more defensively and make "new plugins" get instantiated/injected with implementations of a facade that return instances of the interfaces. If those implementations can't just be cast to internal types we then have a much higher barrier to abuse (reflection). As for package names I agree we need to think carefully about them. It is a question what the goal is too. If we're reworking the internals, sdk won't sound right at all. If we are building something only meant to be consumed by an outer layer of plugins to insulate the plugins from internal refactoring, something in that vein sounds fine (or maybe o.a.s.cloud.plugin.api?) Settling on what our goals are will help us decide what name is best. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664078634 While marking things internal and external is good, a stronger possibility to code more defensively and make "new plugins" get instantiated/injected with implementations of a facade that return instances of the interfaces. If those implementations can't just be cast to internal types we then have a much higher barrier to abuse (reflection). As for package names I agree we need to think carefully about them. It is a question what the goal is too. If we're reworking the internals, sdk won't sound right at all. If we are building something only meant to be consumed by an outer layer of plugins to insulate the plugins from internal refactoring, something in that vein sounds fine (or maybe o.a.s.cloud.plugin.api?) Settling on what our goals are will help us decide what name is best. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11868) Deprecate CloudSolrClient.setIdField, use information from Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165365#comment-17165365 ] ASF subversion and git services commented on SOLR-11868: Commit f9410e14614d1f9ebb88226c287f38cd4d0b3d1f in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f9410e1 ] SOLR-11868: CloudSolrClient.setIdField is confusing, it's really the routing field. Should be deprecated. > Deprecate CloudSolrClient.setIdField, use information from Zookeeper > > > Key: SOLR-11868 > URL: https://issues.apache.org/jira/browse/SOLR-11868 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > IIUC idField has nothing to do with the field. It's really > the field used to route documents. Agreed, this is often the "id" > field, but still > In fact, over in UpdateReqeust.getRoutes(), it's passed as the "id" > field to router.getTargetSlice() and just works, even though > getTargetSlice is clearly designed to route on a field other than the > if we didn't just pass null as the "route" param. > The confusing bit is that if I have a route field defined for my > collection and want to use CloudSolrClient I have to figure out that I > need to use the setIdField method to use that field for routing. > > We should deprecate setIdField and refactor how this is used (i.e. > getRoutes). Need to beef up tests too I suspect. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11868) Deprecate CloudSolrClient.setIdField, use information from Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11868. --- Fix Version/s: 8.7 Resolution: Fixed > Deprecate CloudSolrClient.setIdField, use information from Zookeeper > > > Key: SOLR-11868 > URL: https://issues.apache.org/jira/browse/SOLR-11868 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > > IIUC idField has nothing to do with the field. It's really > the field used to route documents. Agreed, this is often the "id" > field, but still > In fact, over in UpdateReqeust.getRoutes(), it's passed as the "id" > field to router.getTargetSlice() and just works, even though > getTargetSlice is clearly designed to route on a field other than the > if we didn't just pass null as the "route" param. > The confusing bit is that if I have a route field defined for my > collection and want to use CloudSolrClient I have to figure out that I > need to use the setIdField method to use that field for routing. > > We should deprecate setIdField and refactor how this is used (i.e. > getRoutes). Need to beef up tests too I suspect. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11868) Deprecate CloudSolrClient.setIdField, use information from Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165364#comment-17165364 ] ASF subversion and git services commented on SOLR-11868: Commit 6bf5f4a87f40cd9afd3b9104423d0fe51f287259 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6bf5f4a ] SOLR-11868: CloudSolrClient.setIdField is confusing, it's really the routing field. Should be deprecated. > Deprecate CloudSolrClient.setIdField, use information from Zookeeper > > > Key: SOLR-11868 > URL: https://issues.apache.org/jira/browse/SOLR-11868 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.2 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > IIUC idField has nothing to do with the field. It's really > the field used to route documents. Agreed, this is often the "id" > field, but still > In fact, over in UpdateReqeust.getRoutes(), it's passed as the "id" > field to router.getTargetSlice() and just works, even though > getTargetSlice is clearly designed to route on a field other than the > if we didn't just pass null as the "route" param. > The confusing bit is that if I have a route field defined for my > collection and want to use CloudSolrClient I have to figure out that I > need to use the setIdField method to use that field for routing. > > We should deprecate setIdField and refactor how this is used (i.e. > getRoutes). Need to beef up tests too I suspect. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
chatman commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664052755 As I suggested in the other PR on autoscaling, I feel we should change the package name: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664051353 Also, WDYT about marking the concrete classes DocCollection, Replica etc. with @lucene.internal to make it clear that they shouldn't be used directly from the plugins? Alternatively, we can mark these new interfaces in this PR with a new annotation (e.g. @solr.external) that signals to plugin writers that these will be stable for their use across versions. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman edited a comment on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664051353 > Gumi means “elastic” in Hebrew. I’ll change that package name to... what? I see that @noblepaul has used the name "o.a.s.common.cloud.sdk" in the other PR for SolrCloud specific interfaces. One day, I would hope all our internal code should use these interfaces, and having "sdk" then, IMHO, wouldn't be ideal. How about "o.a.s.cloud.interfaces" for that? Regarding other interfaces introduced here, how about "o.a.s.cloud.placements.interfaces" or "o.a.s.cloud.assignments.interfaces"? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman edited a comment on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664051353 > Gumi means “elastic” in Hebrew. I’ll change that package name to... what? I see that @noblepaul has used the name "o.a.s.cloud.sdk" in the other PR for SolrCloud specific interfaces. One day, I would hope all our internal code should use these interfaces, and having "sdk" then, IMHO, wouldn't be ideal. How about "o.a.s.cloud.interfaces" for that? Regarding other interfaces introduced here, how about "o.a.s.cloud.placements.interfaces" or "o.a.s.cloud.assignments.interfaces"? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664051353 > Gumi means “elastic” in Hebrew. I’ll change that package name to... what? I see that @noblepaul has used the name "o.a.s.cloud.sdk" in the other PR for SolrCloud specific interfaces. One day, I would hope all our internal code should use these interfaces, and having "sdk" then, IMHO, wouldn't be ideal. How about "o.a.s.cloud.interfaces" for that? Regarding other interfaces introduced here, how about "o.a.s.cloud.placements.interfaces" or "o.a.s.cloud.assignments.interfaces"? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
murblanc edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-66404 Snitches have a target (at least node or replica, but one could imagine Cluster, collection or shard if such snitches do not already exist). Would be helpful for all these classes to implement a common interface so they can be passed when a notch target is needed in Autoscaling plugins. (See in https://github.com/apache/lucene-solr/pull/1684/files#diff-fc8bc5eb94b9e48a24c2ec768733e72b) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
murblanc commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-66404 Snitches have a target (at least node or replica, but one could imagine Cluster, collection or shard if such snitches do not already exist). Would be helpful for all these classes to implement a common interface so they can be passed when a notch target is needed in Autoscaling plugins. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664048647 The work orders are the actions decided by the plugin to satisfy a request or requests sent by a Collection API command implementation. The chain is: Collection API -> command execution builds requests -> plugin code running, returns work orders -> collection API command execution executes the work orders resulting in cluster state changes and node changes (creating/deleting replicas). Maybe create collection doesn’t have to be decided by plugin code since it has to happen in any case when a new collection is created. It could be added by the collection api command itself (but then tricky interaction with the cluster state classes given it’s a partially built collection). Gumi means “elastic” in Hebrew. I’ll change that package name to... what? I’ll remove the cluster state classes (SolrCollection, Shard, Replica) and assume plugins get their view of cluster state elsewhere. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664047131 What does "gumi" mean? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664046970 > There’s no direct mapping between work orders and collection API. I consider work orders the basic building blocs from which collection API actions can be built. Creating a collection (adding the data in ZK, checking for the config set etc) is different from adding a replica to an existing collection. Hence the two work orders. The “new collection” doesn’t add any replicas to the collection but prepares the system to accept adding replicas replicas for the collection. Obviously when adding a replica to an existing collection, that preparation work is not required. Why can't we have a single type of work order that requests for the preparation of n number of replicas (where n is 1 in case of ADDREPLICA and n is numShards*replicationFactor in case of CREATE)? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc edited a comment on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664046112 There’s no direct mapping between work orders and collection API. I consider work orders the basic building blocs from which collection API actions can be built. Creating a collection (adding the data in ZK, checking for the config set etc) is different from adding a replica to an existing collection. Hence the two work orders. The “new collection” doesn’t add any replicas to the collection but prepares the system to accept adding replicas replicas for the collection. Obviously when adding a replica to an existing collection, that preparation work is not required. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664046112 There’s no direct mapping between work orders and collection API. I consider work orders the basic building blocs from which collection API actions can be built. Creating a replica (adding the data in ZK, checking for the config set etc) is different from adding a replica to an existing collection. Hence the two work orders. The new collection one doesn’t add any replicas to the collection but prepares the system to accept replicas for the collection (work that is not required when adding a replica to an existing collection). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664042985 Regarding the work orders, can we decouple them from the collection API commands that are used? I see CreateReplicaWorkOrder and NewCollectionWorkOrder. AFAICT, the former needs replica placement for one replica, and the latter needs placement for potentially multiple replicas. Why can't we have a generic interface for providing placements that are agnostic of the collection API used? If we don't, we'll end up with more such work orders like move replica, split shard, restore, rebalance, utilize etc. etc., which would be large surface area to deal with. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
chatman commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-664041481 > I can participate in that other PR (already did) but it duplicates seriously the effort I’ve started here. Maybe we carry the two approaches in parallel and then we’ll be able to compare what’s best in one or the other and be able to build a third one that’s even better? I think we should work on SolrCloud interfaces that packages should use in that other PR, and not define them here. I'm -1 on carrying the two approaches in parallel, but I just want for us to separate the two concerns in two PRs (this one concerning with the interfaces specific to assignment/replica placement, and the other one to define SolrCloud interfaces for the benefit of this effort as well as other plugins/packages that may want to use them). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13169) Move Replica Docs need improvement (V1 and V2 introspect)
[
https://issues.apache.org/jira/browse/SOLR-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck reassigned SOLR-13169:
---
Assignee: Gus Heck
> Move Replica Docs need improvement (V1 and V2 introspect)
> -
>
> Key: SOLR-13169
> URL: https://issues.apache.org/jira/browse/SOLR-13169
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13169.patch, screenshot-1.png, testing.txt
>
>
> At a minimum required parameters should be noted equally in both places.
> Conversation with [~ab] indicates that there are also some discrepancies in
> what is and is not actually required in docs vs code. ("in MoveReplicaCmd if
> you specify “replica” then “shard” is completely ignored")
> Also in v2 it seems shard might be inferred from the URL and in that case
> it's not clear if the URL or the json takes precedence.
> From introspect:
> {code:java}
> "move-replica": {
> "type": "object",
> "documentation":
> "https://lucene.apache.org/solr/guide/collections-api.html#movereplica;,
> "description": "This command moves a replica from one
> node to a new node. In case of shared filesystems the `dataDir` and `ulogDir`
> may be reused.",
> "properties": {
> "replica": {
> "type": "string",
> "description": "The name of the replica"
> },
> "shard": {
> "type": "string",
> "description": "The name of the shard"
> },
> "sourceNode": {
> "type": "string",
> "description": "The name of the node that
> contains the replica."
> },
> "targetNode": {
> "type": "string",
> "description": "The name of the destination node.
> This parameter is required."
> },
> "waitForFinalState": {
> "type": "boolean",
> "default": "false",
> "description": "Wait for the moved replica to
> become active."
> },
> "timeout": {
> "type": "integer",
> "default": 600,
> "description": "Timeout to wait for replica to
> become active. For very large replicas this may need to be increased."
> },
> "inPlaceMove": {
> "type": "boolean",
> "default": "true",
> "description": "For replicas that use shared
> filesystems allow 'in-place' move that reuses shared data."
> }
> {code}
> From ref guide for V1:
> MOVEREPLICA Parameters
> collection
> The name of the collection. This parameter is required.
> shard
> The name of the shard that the replica belongs to. This parameter is required.
> replica
> The name of the replica. This parameter is required.
> sourceNode
> The name of the node that contains the replica. This parameter is required.
> targetNode
> The name of the destination node. This parameter is required.
> async
> Request ID to track this action which will be processed asynchronously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664018065 These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: - **Machines** are the operating system level container or hardware and have - **Nodes** which are running solr processes on machines which have portions of - **Collections** which are logical indexes associated with a particular schema and have - **Shards** which split a collection on a routing value to allow scaling and have - **Replicas** which are duplicate copies implementing a shard often hosted on separate nodes. We should strive to apply only ONE word for each level throughout the interfaces to make them as simple and easy to understand as possible. These 5 terms all have nice clear english words that communicate their function to some extent. Core however only really means "central thing" and I have always thought it was a very confusing word to use here since it has almost no memnonic value. Slice is also good for the shard level, but I think shard is no worse and more commonly used in documentation. Although core has been used many times in the past, I don't think anyone is going to have trouble finding what they want via the terms I'm suggesting. The Cluster level concept usually ignores Machines and speaks only of nodes... I could be convinced either way on whether or not that's a good thing. For fun I drew a near worst case diagaram (omitting back references and convenience rollups) :)  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664018065 These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: - **Machines** are the operating system level container or hardware and have - **Nodes** which are running solr processes on machines which have portions of - **Collections** which are logical indexes associated with a particular schema and have - **Shards** which split a collection on a routing value to allow scaling and have - **Replicas** which are duplicate copies implementing a shard often hosted on separate nodes. We should strive to apply only ONE word for each level throughout the interfaces to make them as simple and easy to understand as possible. These 5 terms all have nice clear english words that communicate their function to some extent. Core however only really means "central thing" and I have always thought it was a very confusing word to use here since it has almost no memnonic value. Slice is also good for the shard level, but I think shard is no worse and more commonly used in documentation. Although core has been used many times in the past, I don't think anyone is going to have trouble finding what they want via the terms I'm suggesting. The Cluster level concept usually ignores Machines and speaks only of nodes... I could be convinced either way on whether or not that's a good thing. For fun I drew a near worst case diagaram (omitting back references) :)  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf commented on a change in pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf commented on a change in pull request #1694:
URL: https://github.com/apache/lucene-solr/pull/1694#discussion_r460560248
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrCluster.java
##
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/**
+ * Represents a Solr cluster
+ */
+public interface SolrCluster {
+ /** collections in the cluster */
+ SimpleMap collections();
Review comment:
Also aliases... and the Alias class returned should list the collections
provided and routing info if routed. (also law of Demeter etc...)
##
File path:
solr/solrj/src/java/org/apache/solr/common/util/LinkedSimpleHashMap.java
##
@@ -0,0 +1,27 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.common.util;
+
+import java.util.LinkedHashMap;
+
+public class LinkedSimpleHashMap extends LinkedHashMap
implements SimpleMap {
Review comment:
this class appears unused...
##
File path: solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrNode.java
##
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import org.apache.solr.common.util.SimpleMap;
+
+/**
+ * A read only view of a Solr node
+ */
+public interface SolrNode {
+
+ /** The node name */
+ String name();
+
+ String baseUrl(boolean isV2);
+
+ SimpleMap cores();
Review comment:
Possibly good to also answer the question of "what collections are
participating in this node" and what shards of Collection X are on this node.
##
File path:
solr/solrj/src/java/org/apache/solr/common/cloud/sdk/SolrCollection.java
##
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud.sdk;
+
+import
[GitHub] [lucene-solr] gus-asf edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664018065 These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: - **Machines** are the operating system level container or hardware and have - **Nodes** which are running solr processes on machines which have portions of - **Collections** which are logical indexes associated with a particular schema and have - **Shards** which split a collection on a routing value to allow scaling and have - **Replicas** which are duplicate copies implementing a shard often hosted on separate nodes. We should strive to apply only ONE word for each level throughout the interfaces to make them as simple and easy to understand as possible. These 5 terms all have nice clear english words that communicate their function to some extent. Core however only really means "central thing" and I have always thought it was a very confusing word to use here since it has almost no memnonic value. Slice is also good for the shard level, but I think shard is no worse and more commonly used in documentation. Although core has been used many times in the past, I don't think anyone is going to have trouble finding what they want via the terms I'm suggesting. The Cluster level concept usually ignores Machines and speaks only of nodes... I could be convinced either way on whether or not that's a good thing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf edited a comment on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf edited a comment on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664018065 These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: - **Machines** are the operating system level container or hardware and have - **Nodes** which are running solr processes on machines which have - **Collections** which are logical indexes associated with a particular schema and have - **Shards** which split a collection on a routing value to allow scaling and have - **Replicas** which are duplicate copies implementing a shard often hosted on separate nodes. We should strive to apply only ONE word for each level throughout the interfaces to make them as simple and easy to understand as possible. These 5 terms all have nice clear english words that communicate their function to some extent. Core however only really means "central thing" and I have always thought it was a very confusing word to use here since it has almost no memnonic value. Slice is also good for the shard level, but I think shard is no worse and more commonly used in documentation. Although core has been used many times in the past, I don't think anyone is going to have trouble finding what they want via the terms I'm suggesting. The Cluster level concept usually ignores Machines and speaks only of nodes... I could be convinced either way on whether or not that's a good thing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165300#comment-17165300
]
Mark Robert Miller commented on SOLR-14636:
---
The promised land approaches. The regular developer test run is getting
merciless.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
gus-asf commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-664018065 These interfaces look like a good way to begin. Thoughts: This is an excellent point at which to consider and then stick to a preferred set of terminology. My favorites are: - **Machines** are the operating system level container or hardware and have - **Nodes** which are running solr processes on machines which have - **Collections** which are logical indexes associated with a particular schema and have - **Shards** which split a collection on a routing value to allow scaling and have - **Replicas** which are duplicate copies implementing a shard often hosted on separate nodes. We should strive to apply only ONE word for each level throughout the interfaces to make them as simple and easy to understand as possible. These 5 terms all have nice clear english words that communicate their function to some extent. Core however only really means "central thing" and I have always thought it was a very confusing word to use here since it has almost no memnonic value. Slice is also good for the shard level, but I think shard is no worse and more commonly used in documentation. Although core has been used many times in the past, I don't think anyone is going to have trouble finding what they want via the terms I'm suggesting. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] Hronom commented on a change in pull request #1419: SOLR-14397: Vector Search in Solr
Hronom commented on a change in pull request #1419:
URL: https://github.com/apache/lucene-solr/pull/1419#discussion_r460552820
##
File path:
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/vectors/FloatVectorFieldSource.java
##
@@ -0,0 +1,213 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.queries.function.valuesource.vectors;
+
+import java.io.IOException;
+import java.nio.ByteBuffer;
+import java.nio.FloatBuffer;
+import java.nio.charset.StandardCharsets;
+import java.util.Map;
+import org.apache.lucene.index.BinaryDocValues;
+import org.apache.lucene.index.DocValues;
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.queries.function.FunctionValues;
+import org.apache.lucene.queries.function.valuesource.BytesRefFieldSource;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.BytesRefBuilder;
+import org.apache.lucene.util.mutable.MutableValue;
+import org.apache.lucene.util.mutable.MutableValueStr;
+
+/**
+ * An implementation for retrieving {@link FunctionValues} instances for
string based fields.
+ */
+public class FloatVectorFieldSource extends BytesRefFieldSource {
+
+ protected Encoding encoding;
+
+ public FloatVectorFieldSource(String field, Encoding encoding) {
+super(field);
+this.encoding = encoding;
+ }
+
+ public enum Encoding {
+STRING, // "[1.0,2.23]|[4.56,7]". Separator = "|"
+BASE64, // Base64 Encoded float[]. Separator = "|"
+BFLOAT16 // Compressed float[] to bfloat. Separator = "|"
+ }
+
+ public static float[] rawStringToVector(String stringifiedVector) {
+//format: 1.0,2.345
+
+String[] split = stringifiedVector.split(",");
+float[] output = new float[split.length];
+
+for(int i=0; i< split.length; i++) {
+ output[i] = Float.parseFloat(split[i]);
+}
+
+return output;
+ }
+
+ public static String vectorToRawString(float[] vector) {
+StringBuilder sb = new StringBuilder();
+for (int i = 0; i < vector.length; i++) {
+ if (sb.length() > 0) {
+sb.append(',');
+ }
+ sb.append(Float.toString(vector[i]));
+}
+return sb.toString();
+ }
+
+ public static BytesRef vectorToRawStringBytesRef(float[] vector){
+ BytesRefBuilder builder = new BytesRefBuilder();
+ byte[] bytes;
+ for (int i=0; i 0){
+ builder.append((byte)',');
+}
+bytes = Float.toString(vector[i]).getBytes(StandardCharsets.UTF_8);
+builder.append(bytes, 0, bytes.length);
+ }
+ return builder.get();
+ }
+
+ @Override
+ public FunctionValues getValues(Map context, LeafReaderContext
readerContext) throws IOException {
+
+ final BinaryDocValues binaryValues =
DocValues.getBinary(readerContext.reader(), field);
+ return new FunctionValues() {
+int lastDocID = -1;
+
+private BytesRef getValueForDoc(int doc) throws IOException {
+ if (doc < lastDocID) {
+throw new IllegalArgumentException("docs were sent out-of-order:
lastDocID=" + lastDocID + " vs docID=" + doc);
+ }
+ lastDocID = doc;
+ int curDocID = binaryValues.docID();
+ if (doc > curDocID) {
+curDocID = binaryValues.advance(doc);
+ }
+ if (doc == curDocID) {
+return decode(binaryValues.binaryValue());
+ } else {
+return null;
+ }
+}
+
+
+//TODO: maybe change to float[][] later... ?
+protected BytesRef decode(BytesRef encoded){
+ byte[] encodedVectors = encoded.bytes;
+ BytesRefBuilder currentEncodedVector = new BytesRefBuilder();
+ BytesRefBuilder decodedVectorString = new BytesRefBuilder();
//TODO: float[][] later
+
+ for (int i=encoded.offset; i< encoded.offset + encoded.length; i++) {
+if (encodedVectors[i] == (byte) '|' || i == encoded.offset +
encoded.length - 1) {
+ float[] currentVector = null;
+ switch (encoding) {
+case BFLOAT16:
+ //TODO
+ break;
+case BASE64:
+ currentVector =
[jira] [Commented] (SOLR-12847) Cut over implementation of maxShardsPerNode to a collection policy
[ https://issues.apache.org/jira/browse/SOLR-12847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165245#comment-17165245 ] Erick Erickson commented on SOLR-12847: --- If we put support back in for maxShardsPerNode (and, BTW, can we rename that? It's always been confusing 'cause it's not about shards really) then at least a new test I'm putting in will break (RouteFieldTest, coming soon). > Cut over implementation of maxShardsPerNode to a collection policy > -- > > Key: SOLR-12847 > URL: https://issues.apache.org/jira/browse/SOLR-12847 > Project: Solr > Issue Type: Bug > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > We've back and forth over handling maxShardsPerNode with autoscaling policies > (see SOLR-11005 for history). Now that we've reimplemented support for > creating collections with maxShardsPerNode when autoscaling policy is > enabled, we should re-look at how it is implemented. > I propose that we fold maxShardsPerNode (if specified) to a collection level > policy that overrides the corresponding default in cluster policy (see > SOLR-12845). We'll need to ensure that if maxShardsPerNode is specified then > the user sees neither violations nor corresponding suggestions because of the > default cluster policy. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
murblanc commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-663999287 I also feel this PR has a lot of overlap with the one I started to define an API for Autoscaling plugins (https://github.com/apache/lucene-solr/pull/1684). Unless we want to pursue two distinct options for these interfaces and decide later (perfectly OK if that’s the idea) I suggest we use the other PR that has also examples of how these interfaces are used (makes it easier to reason about them and decide what goes where). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7400) Collection creation fails when over-provisioning maxShardsPerNode > 1
[
https://issues.apache.org/jira/browse/SOLR-7400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-7400.
--
Resolution: Invalid
This is both very old and almost certainly a configuration issue, dataDirs are
not shared amongst multiple replicas on the same node.
> Collection creation fails when over-provisioning maxShardsPerNode > 1
> -
>
> Key: SOLR-7400
> URL: https://issues.apache.org/jira/browse/SOLR-7400
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.10.3
> Environment: HDP 2.2 / HDP Search
>Reporter: Hari Sekhon
>Priority: Major
>
> When trying to overprovision shards I've encountered an issue before where
> the additional shards are trying to use the same dataDir resulting in failure
> to obtain locks for those additional shard replicas:
> {code}curl
> 'http://host:8983/solr/admin/collections?action=CREATE=test=6=6=2=json=true'
> {
> "responseHeader":{
> "status":0,
> "QTime":3925},
> "failure":{
>
> "":"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test_shard1_replica2': Unable to create core
> [test_shard1_replica2] Caused by: Lock obtain timed out:
> NativeFSLock@/data1/solr/test/index/write.lock",
>
> "":"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test_shard6_replica1': Unable to create core
> [test_shard6_replica1] Caused by: Lock obtain timed out:
> NativeFSLock@/data1/solr/test/index/write.lock",
>
> "":"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test_shard5_replica2': Unable to create core
> [test_shard5_replica2] Caused by: Lock obtain timed out:
> NativeFSLock@/data1/solr/test/index/write.lock",
>
> "":"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test_shard2_replica1': Unable to create core
> [test_shard2_replica1] Caused by: Lock obtain timed out:
> NativeFSLock@/data1/solr/test/index/write.lock",
>
> "":"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test_shard3_replica2': Unable to create core
> [test_shard3_replica2] Caused by: Lock obtain timed out:
> NativeFSLock@/data1/solr/test/index/write.lock",
>
> "":"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test_shard4_replica1': Unable to create core
> [test_shard4_replica1] Caused by: Lock obtain timed out:
> NativeFSLock@/data1/solr/test/index/write.lock"},
> "success":{
> "":{
> "responseHeader":{
> "status":0,
> "QTime":3225},
> "core":"test_shard5_replica1"},
> "":{
> "responseHeader":{
> "status":0,
> "QTime":3234},
> "core":"test_shard6_replica2"},
> "":{
> "responseHeader":{
> "status":0,
> "QTime":3248},
> "core":"test_shard1_replica1"},
> "":{
> "responseHeader":{
> "status":0,
> "QTime":3433},
> "core":"test_shard4_replica2"},
> "":{
> "responseHeader":{
> "status":0,
> "QTime":3620},
> "core":"test_shard3_replica1"},
> "":{
> "responseHeader":{
> "status":0,
> "QTime":3800},
> "core":"test_shard2_replica2"}}}
> {code}
> It's not clear given this how you could have more than one shard per node to
> pre-provision for anticipated node growth.
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-663997462 I agree about the naming, will change, will try to make these interfaces seem more like a generic thing for SolrCloud rather than something that’s Autoscaling specific. Regarding “Pleas refer to #1694 as a separate effort to make this simpler.”, I will not at this stage. I can participate in that other PR (already did) but it duplicates seriously the effort I’ve started here. Maybe we carry the two approaches in parallel and then we’ll be able to compare what’s best in one or the other and be able to build a third one that’s even better? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1694: SOLR-14680: Provide simple interfaces to our concrete SolrCloud classes
murblanc commented on pull request #1694: URL: https://github.com/apache/lucene-solr/pull/1694#issuecomment-663994405 Can we start simple by defining the external interface without the required changes to internal classes first? Will make a smaller PR easier to discuss. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165202#comment-17165202 ] Erick Erickson commented on LUCENE-9433: [~tomoko] Sure. I anticipate a few days of things being a bit unsettled when we make the switch and push this JIRA. Hmmm, I don't think we _need_ to wait on this Jira to switch the Jenkins builds to use Gradle only, but I'll leave the timing up to Uwe & friends. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165199#comment-17165199 ] Tomoko Uchida commented on LUCENE-9433: --- [LUCENE-9441] is a bit sticky. The javadocs cannot be fixed as long as Ant build job is live, otherwise ant precommit fails with link checker error. I will fix it (and also enable the linter for gradle's check task) after we completely switch to Gradle and discard Ant build job. Can you please ping me when nightly Ant build job is stopped ? > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165191#comment-17165191 ] Tomoko Uchida edited comment on LUCENE-9321 at 7/26/20, 9:19 AM: - I've opened a PR ([https://github.com/apache/lucene-solr/pull/1695]) to make Solr snapshot build pass the linter. Could you review it? was (Author: tomoko uchida): I've opened a PR ([https://github.com/apache/lucene-solr/pull/1695|https://github.com/apache/lucene-solr/pull/1695]) to make Solr snapshot build pass the linter. Could you review it? > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 9h 10m > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165191#comment-17165191 ] Tomoko Uchida commented on LUCENE-9321: --- I've opened a PR ([https://github.com/apache/lucene-solr/pull/1695|https://github.com/apache/lucene-solr/pull/1695]) to make Solr snapshot build pass the linter. Could you review it? > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 9h 10m > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta opened a new pull request #1695: LUCENE-9321: Fix Javadoc offline link base url for snapshot build
mocobeta opened a new pull request #1695: URL: https://github.com/apache/lucene-solr/pull/1695 This includes two changes in documentation task. 1. Fix Javadoc offline link base url to make snapshot build pass `checkBrokenLinks`. 2. Explicitly disable cross-project link for `:solr:test-framework`, otherwise broken links are generated due to split package issue. See: https://github.com/apache/lucene-solr/blob/master/solr/test-framework/build.xml#L59 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
