[
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
