Versions Compared

Old Version 1

changes.mady.by.user Jan Høydahl

Saved on

compared with

New Version Current

changes.mady.by.user Ishan Chattopadhyaya

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page is meant as a template for writing a SIP. To create a SIP choose Tools->Copy on this page and modify with your content and replace the heading with the next SIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state:  [One of "Under Discussion", "Accepted", "Rejected"] Under discussion

Discussion thread: SOLR-14041here (<- link to https://mail-archives.apache.org/mod_mbox/lucene-dev/)

JIRA: here (<- link to https://issues.apache.org/jira/browse/SOLR-XXXX)14041

Released:  <Solr Version>TBD

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.

Motivation

Describe the problems you are trying to solve.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

The definition of a public interface is found on the main SIP page.

Proposed Changes

...

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

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
  • If we are changing behavior how will we phase out the older behavior?
  • If we need special migration tools, describe them here.
  • When will we remove the existing behavior?

Test Plan

Describe in few sentences how the SIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

N/A

Test Plan

Test cases to check behavior have been added, since this is just a refactor of existing implementation, this is fairly easy.


Rejected Alternatives

N/AIf there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.