[ https://issues.apache.org/jira/browse/SOLR-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993364#comment-16993364 ]
Apoorv Bhawsar commented on SOLR-13936: --------------------------------------- [~ichattopadhyaya] {code:java} Status Current state: [One of "Under Discussion", "Accepted", "Rejected"] Discussion thread: here (<- link to https://mail-archives.apache.org/mod_mbox/lucene-dev/) JIRA: here (<- link to https://issues.apache.org/jira/browse/SOLR-13936) Released: Not yet Motivation To introduce api endpoints to modify configsets using rest apis. The configests in this case need not be assoiciated with a collection. Valid scenarios - 1. Cases where a configset creation automation is to be done based on a set of rules before we go ahead and create a collection on it this would be very helpful 2. Cases where there multiple collections (A and B) associated with one configset (_config) these endpoints make more sense cause the current endpoints have 2 ways of editing them via A and B which internally modifies _config only Public Interfaces Two new endpoints shall be added for schema and solrconfig changes. - /api/cluster/configset/{name}/schema - /ap/cluster/configset/{name}/config Above api endpoints are to make configsets first class citizen just like collection. No changes to be done for older collection specific endpoints Proposed Changes 1. Refactor current implementation of ManagedSchema and SolrConfig classes to be independent of SolrCore. 2. Adding new constructors that can create ManagedSchema and SolrConfig without a collection dependency i.e in such cases zk connection will be used to get resources 3. Add tests to validate them These new endpoints shall be experimental and for power users only. No impact on existing users Phasing out older behaviour is still to be debated Note : SolrConfig implementation doesn't implement a watch on zookeeper resources rightnow like ManagedSchema, because of which if a configset A is changed using these apis collections associated with it, however that is not the case with managed schema. This can be implemented if required Test Plan Test cases to check behavior have been added, since this is just a refactor of existing implementation, this is fairly easy {code} > Schema/Config endpoints to modify configset with no core/collection > ------------------------------------------------------------------- > > Key: SOLR-13936 > URL: https://issues.apache.org/jira/browse/SOLR-13936 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: config-api > Reporter: Apoorv Bhawsar > Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > All schema/config configurations should work even in cases where a collection > is not associated with them > This jira will involve > 1. Refactoring existing handler/manager to work without {{SolrCore}} > 2. Adding {{/api/cluster}} endpoints to support such modifications > Endpoints - > * {{/api/cluster/configset/\{name}/schema}} > * {{/ap/cluster/configset/\{name}/config}} -- 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