Solr
  1. Solr
  2. SOLR-7499

Deprecate the "name" parameter from the ADDREPLICA Collection API call

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.3, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      Right now we take a "name" parameter in the ADDREPLICA call. We use that as the core name for the replica. Are there any use cases where specifying the name of the core for the replica is useful?

      Here are the disadvantages of doing so -
      1. We don't verify if the name is unique in the collection. So if a conflicting name ends up in the same node then the call will fail.
      2. If it core is created on some other node, it will fail with legacyCloud=false as that checks for uniqueness in core names.

      https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api_addreplica - The ref guide has never documented the "name" parameter.

      1. SOLR-7499.patch
        4 kB
        Varun Thacker
      2. SOLR-7499.patch
        7 kB
        Varun Thacker
      3. SOLR-7499.patch
        6 kB
        Varun Thacker

        Activity

        Hide
        Erick Erickson added a comment -

        I can go both ways on this. On the one hand, it's perfectly legitimate for an admin to want to have full control over the replica names. OTOH, it's a fine way to shoot oneself in the foot.

        It seems to me that we either remove it or make it safe. "Make it safe" means check up-front for any other core with the same name anywhere in the collection (not just on the same node) and fail if one exists.

        Overall, though, since we don't allow the user to specify names of cores when creating collections, there's no real reason to allow it on the ADDREPLICA command so let's nuke it, or at least remove it from the docs and call it "expert".

        Show
        Erick Erickson added a comment - I can go both ways on this. On the one hand, it's perfectly legitimate for an admin to want to have full control over the replica names. OTOH, it's a fine way to shoot oneself in the foot. It seems to me that we either remove it or make it safe. "Make it safe" means check up-front for any other core with the same name anywhere in the collection (not just on the same node) and fail if one exists. Overall, though, since we don't allow the user to specify names of cores when creating collections, there's no real reason to allow it on the ADDREPLICA command so let's nuke it, or at least remove it from the docs and call it "expert".
        Hide
        Noble Paul added a comment - - edited

        +1 to deprecate it. A core name is inconsequential in SolrCloud

        warn the user that it is not supported and will be removed in a future release

        Show
        Noble Paul added a comment - - edited +1 to deprecate it. A core name is inconsequential in SolrCloud warn the user that it is not supported and will be removed in a future release
        Hide
        Varun Thacker added a comment -

        Patch which ensures that you can't create a replica with a core name that is already used for that collection.

        Not sure how we would deprecate a param in this case. Just an entry to the CHANGES.txt noting the param as deprecated?

        Show
        Varun Thacker added a comment - Patch which ensures that you can't create a replica with a core name that is already used for that collection. Not sure how we would deprecate a param in this case. Just an entry to the CHANGES.txt noting the param as deprecated?
        Hide
        Noble Paul added a comment -

        add a check in the Collection API and send back a warning in response

        Show
        Noble Paul added a comment - add a check in the Collection API and send back a warning in response
        Hide
        Varun Thacker added a comment -

        Same patch as before but adds a deprecated message in the response as well if the "name" param has been specified in the ADDREPLICA call.

        Summarizing:

        • Added checks to make sure the "name" specified is unique for that collection
        • Added deprecated message when the "name" param is used. We can remove it in the future.

        If that patch is okay I'll commit this tomorrow.

        Show
        Varun Thacker added a comment - Same patch as before but adds a deprecated message in the response as well if the "name" param has been specified in the ADDREPLICA call. Summarizing: Added checks to make sure the "name" specified is unique for that collection Added deprecated message when the "name" param is used. We can remove it in the future. If that patch is okay I'll commit this tomorrow.
        Hide
        Varun Thacker added a comment -

        Updated patch to trunk. I'll commit this shortly

        Show
        Varun Thacker added a comment - Updated patch to trunk. I'll commit this shortly
        Hide
        ASF subversion and git services added a comment -

        Commit 1686827 from Varun Thacker in branch 'dev/trunk'
        [ https://svn.apache.org/r1686827 ]

        SOLR-7499: Deprecate the 'name' parameter from the ADDREPLICA Collection API call

        Show
        ASF subversion and git services added a comment - Commit 1686827 from Varun Thacker in branch 'dev/trunk' [ https://svn.apache.org/r1686827 ] SOLR-7499 : Deprecate the 'name' parameter from the ADDREPLICA Collection API call
        Hide
        ASF subversion and git services added a comment -

        Commit 1686973 from Varun Thacker in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1686973 ]

        SOLR-7499: Deprecate the 'name' parameter from the ADDREPLICA Collection API call (merged from trunk r1686827)

        Show
        ASF subversion and git services added a comment - Commit 1686973 from Varun Thacker in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1686973 ] SOLR-7499 : Deprecate the 'name' parameter from the ADDREPLICA Collection API call (merged from trunk r1686827)
        Hide
        ASF subversion and git services added a comment -

        Commit 1687495 from Varun Thacker in branch 'dev/trunk'
        [ https://svn.apache.org/r1687495 ]

        SOLR-7499: Correct formatting in CHANGES entry

        Show
        ASF subversion and git services added a comment - Commit 1687495 from Varun Thacker in branch 'dev/trunk' [ https://svn.apache.org/r1687495 ] SOLR-7499 : Correct formatting in CHANGES entry
        Hide
        ASF subversion and git services added a comment -

        Commit 1687497 from Varun Thacker in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1687497 ]

        SOLR-7499: Correct formatting in CHANGES entry

        Show
        ASF subversion and git services added a comment - Commit 1687497 from Varun Thacker in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1687497 ] SOLR-7499 : Correct formatting in CHANGES entry
        Hide
        Shalin Shekhar Mangar added a comment -

        Bulk close for 5.3.0 release

        Show
        Shalin Shekhar Mangar added a comment - Bulk close for 5.3.0 release

          People

          • Assignee:
            Varun Thacker
            Reporter:
            Varun Thacker
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development