lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-7789) Introduce a ConfigSet management API
Date Tue, 25 Aug 2015 22:55:46 GMT

    [ https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712131#comment-14712131
] 

Gregory Chanan commented on SOLR-7789:
--------------------------------------

{quote}


    Should we just pass the zkclient and simplify this constructor a bit? These boilerplate
type class have such long constructors.

    Overseer.getCollectionQueue(zkStateReader.getZkClient(), stats),
    Overseer.getRunningMap(zkStateReader.getZkClient()),å
    Overseer.getCompletedMap(zkStateReader.getZkClient()),
    Overseer.getFailureMap(zkStateReader.getZkClient())
{quote}

Actually, I think this is a little more complicated.  The runningMap/completedMap/failureMap
are used by the CollectionsHandler to check for async tasks.  If the collection queue is collection
specific the maps should be as well.  It probably makes sense to just group this stuff together
in a single object, like "OverseerTaskQueueState" or "OverseerTaskQueueAsyncState" that just
holds these objects.  Then there can be just a "getCollectionQueueState" and "getConfigSetQueueState"
or whatever.  That would simplify the constructor above as well.  But I think this should
be in another jira.

> Introduce a ConfigSet management API
> ------------------------------------
>
>                 Key: SOLR-7789
>                 URL: https://issues.apache.org/jira/browse/SOLR-7789
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>         Attachments: SOLR-7789.patch, SOLR-7789.patch, SOLR-7789.patch, SOLR-7789.patch
>
>
> SOLR-5955 describes a feature to automatically create a ConfigSet, based on another one,
from a collection API call (i.e. one step collection creation).  Discussion there yielded
SOLR-7742, Immutable ConfigSet support.  To close the loop, we need support for a ConfigSet
management API.
> The simplest ConfigSet API could have one operation:
> create a new config set, based on an existing one, possible modifying the ConfigSet properties.
 Note you need to be able to modify the ConfigSet properties at creation time because otherwise
Immutable could not be changed.
> Another logical operation to support is ConfigSet deletion; that may be more complicated
to implement than creation because you need to handle the case where a collection is already
using the configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message