[
https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712032#comment-14712032
]
Gregory Chanan commented on SOLR-7789:
--------------------------------------
bq. Sometimes we use ConfigSet and sometimes ConfigSets? Do we have the right
distinction? Can we call it out explicitly somewhere?
I tried to follow the Collection(s) example, sometimes it is Collection (e.g.
OverseerCollectionProcessor), sometimes it is Collections (CollectionsHandler).
I agree that this can be cleaned up, but would rather do it in a future patch.
bq. More comments giving overview and rationale of class breakup? As Shalin
noted, the class hierarchy is a bit denser to get a handle on.
Good idea, I'll probably just get rid of the Selector interface as Shalin
suggested and see where we stand there.
{quote}Not the biggest fan of adding more tests with easymock - this stuff is
such a pain to ramp up on for most committers when refactoring or making
changes. I guess what can you do though. Many committers have expressed dislike
with having to deal with the collections API test like this, but it’s hard to
argue around once someone presents working, useful tests. Some deeper things
are just difficult to build simple mocks for.{quote}
There's actually no EasyMock additions in this patch -- that's just showing up
in the diff for some reason because some of the files are renamed. I'll make
sure to use "svn move" or whatever is the correct command when I commit.
bq. Typo - * 1) collection-related Overseer messagess
Will fix.
{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}
That's a good idea, was going to leave for another JIRA but we could do it here.
bq. Beasting Test fails:
Not too concerning because they are timeouts, most likely just means we need to
scale down the number of iterations. I'll try out the beasting script.
> 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: [email protected]
For additional commands, e-mail: [email protected]
