Discussion:
[jira] [Created] (SOLR-12925) Configsets API should allow update of existing configset
(too old to reply)
Alex Halovanic (JIRA)
2018-10-25 13:51:00 UTC
Permalink
Alex Halovanic created SOLR-12925:
-------------------------------------

Summary: Configsets API should allow update of existing configset
Key: SOLR-12925
URL: https://issues.apache.org/jira/browse/SOLR-12925
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: configset-api
Affects Versions: 6.6.5, master (8.0)
Reporter: Alex Halovanic


With the Configsets API it is not possible to update a configset once it has been created: the UPLOAD action will throw an exception "The configuration X already exists in zookeeper".  This is different behavior than the [other mechanisms|https://lucene.apache.org/solr/guide/using-zookeeper-to-manage-configuration-files.html] that allow uploading either a new or updated configuration to Zookeeper.

For someone trying to update a configuration, the only path given through the APIs is to delete the associated collection and configuration and start over from scratch. That, or a one-off invocation of the zk local scripts when these APIs are far superior for remote management (y).

 

Thanks,
Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@lucene.apache.org
For additional commands, e-mail: dev-***@lucene.apache.org
Eric Pugh (JIRA)
2018-10-25 14:56:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/SOLR-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663845#comment-16663845 ]

Eric Pugh commented on SOLR-12925:
----------------------------------

I have run into the same awkwardness... I have a script that uploads my security.json, and then packages up the configset and uploads it to Solr.

However, if I make changes to the schema through the Admin app, how do I preserve those locally? It's awkward to download the managed-schema.xml....

I've been experiementing with having "migrations" (inspired by Rails ActiveRecord) in my /configsets/my_config/migrations directory. It's a series of shell scripts in a numbered order, and I run them after uploading the configset to change things through the Schema API. At this point, I'm not sure if it helps or not!
Post by Alex Halovanic (JIRA)
Configsets API should allow update of existing configset
--------------------------------------------------------
Key: SOLR-12925
URL: https://issues.apache.org/jira/browse/SOLR-12925
Project: Solr
Issue Type: Improvement
Security Level: Public(Default Security Level. Issues are Public)
Components: configset-api
Affects Versions: 6.6.5, master (8.0)
Reporter: Alex Halovanic
Priority: Minor
With the Configsets API it is not possible to update a configset once it has been created: the UPLOAD action will throw an exception "The configuration X already exists in zookeeper".  This is different behavior than the [other mechanisms|https://lucene.apache.org/solr/guide/using-zookeeper-to-manage-configuration-files.html] that allow uploading either a new or updated configuration to Zookeeper.
For someone trying to update a configuration, the only path given through the APIs is to delete the associated collection and configuration and start over from scratch. That, or a one-off invocation of the zk local scripts when these APIs are far superior for remote management (y).
 
Thanks,
Alex
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@lucene.apache.org
For additional commands, e-mail: dev-***@lucene.apache.org
Gus Heck (JIRA)
2018-10-26 16:20:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/SOLR-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665370#comment-16665370 ]

Gus Heck commented on SOLR-12925:
---------------------------------

If a method other than config sets api is possible and you have gradle then you can version control the configset and quickly up/down it for diffing/updating with the gradle plugin I wrote. Obviously a workaround, but hopefully helpful. https://plugins.gradle.org/plugin/com.needhamsoftware.solr-gradle
Post by Alex Halovanic (JIRA)
Configsets API should allow update of existing configset
--------------------------------------------------------
Key: SOLR-12925
URL: https://issues.apache.org/jira/browse/SOLR-12925
Project: Solr
Issue Type: Improvement
Security Level: Public(Default Security Level. Issues are Public)
Components: configset-api
Affects Versions: 6.6.5, master (8.0)
Reporter: Alex Halovanic
Priority: Minor
With the Configsets API it is not possible to update a configset once it has been created: the UPLOAD action will throw an exception "The configuration X already exists in zookeeper".  This is different behavior than the [other mechanisms|https://lucene.apache.org/solr/guide/using-zookeeper-to-manage-configuration-files.html] that allow uploading either a new or updated configuration to Zookeeper.
For someone trying to update a configuration, the only path given through the APIs is to delete the associated collection and configuration and start over from scratch. That, or a one-off invocation of the zk local scripts when these APIs are far superior for remote management (y).
 
Thanks,
Alex
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@lucene.apache.org
For additional commands, e-mail: dev-***@lucene.apache.org
Alex Halovanic (JIRA)
2018-11-05 15:38:01 UTC
Permalink
[ https://issues.apache.org/jira/browse/SOLR-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675318#comment-16675318 ]

Alex Halovanic commented on SOLR-12925:
---------------------------------------

Thank you for the suggestions: I have been version controlling my configsets like this, but my big difficulty was that I was in a remote deployment environment (Windows PowerShell) where forcing in Java and a significant fraction of the Solr install/ZooKeeper configuration would have been very awkward.

I have now found one REST-only approach to get around this limitation that seems to be working for me:
# Use the CREATE action in the ConfigSets API to copy the existing configset to a temporary name.
# Use the MODIFYCOLLECTION action in the Collections API to alter collection.configName to this temporary name.
# Reload the collection.
# Delete the original (now unused) configset.
# Upload the updated configset under the original name.
# Modify the collection back to the original configset name.
# Reload the collection.
# Delete the temporary configset.

So this isn't entirely impossible, but it is still cumbersome with 4x as many steps as the command line.
Post by Alex Halovanic (JIRA)
Configsets API should allow update of existing configset
--------------------------------------------------------
Key: SOLR-12925
URL: https://issues.apache.org/jira/browse/SOLR-12925
Project: Solr
Issue Type: Improvement
Security Level: Public(Default Security Level. Issues are Public)
Components: configset-api
Affects Versions: 6.6.5, master (8.0)
Reporter: Alex Halovanic
Priority: Minor
With the Configsets API it is not possible to update a configset once it has been created: the UPLOAD action will throw an exception "The configuration X already exists in zookeeper".  This is different behavior than the [other mechanisms|https://lucene.apache.org/solr/guide/using-zookeeper-to-manage-configuration-files.html] that allow uploading either a new or updated configuration to Zookeeper.
For someone trying to update a configuration, the only path given through the APIs is to delete the associated collection and configuration and start over from scratch. That, or a one-off invocation of the zk local scripts when these APIs are far superior for remote management (y).
 
Thanks,
Alex
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@lucene.apache.org
For additional commands, e-mail: dev-***@lucene.apache.org

Loading...