[
https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709774#comment-14709774
]
Gregory Chanan commented on SOLR-7789:
--------------------------------------
{quote}In my mind, it makes the opposite impression. The fact that we have a
ZkController.getOverseerCollectionQueue and a different
ZkController.getOverseerConfigSetQueue() suggests that the two queues are
different but they are not, at least not yet. So why does this feature try to
suggest that their implementation might be different at all? These things are
easily changed so lets refactor it when we actually need to have different
queues.{quote}
I think part of the difference of opinion here is you are viewing the interface
as "this is the collection queue and this is the configset queue" -- given that
the interface is a queue your line of thinking makes sense, but perhaps having
queue as part of the interface is leaking too many implementation details
already. I'm viewing the interface as "this is where I send Collection
operation requests and this is where I send ConfigSet operation requests."
There's no same vs separate queue discussion if that is the interface. If that
were the interface, you would be arguing for a single "this is where I send
Overseer operation requests."
To be honest, I don't think this makes a huge difference either way right now.
The central issue, imo, is how you the RequestHandler differentiates which
messages are intended for which MessageHandler. In the naive way of just
throwing everything in the OCP (not saying you are arguing for that), you'd
have conflicts with say, the Collection.CREATE and ConfigSet.CREATE and would
need to make sure all the names don't conflict (a mess). So, you'd either need
to differentiate the message at the Overseer interface level "this is where I
send Collection requests and this is where I send ConfigSet operation requests"
(this is essentially what I've chosen) or each handler puts enough content in
the message so that the overseer can differentiate itself. The later could
certainly be the right way to go -- I just didn't choose it because 1) it would
require changing the existing message format and we'd have to deal with
backwards incompatibility 2) we'd need to invent some grouping concept of
operations (what are CollectionActions vs ConfigSetActions -- groups of
actions? action sets?). If we solve #1 and #2 I certainly have no objection
to having a single "this is where I send Overseer operation requests" interface.
{quote}There are already different QoS expectations within the existing
operations. For example, operations for different collections never block each
other and operations such as cluster status, overseer status and request status
never block. However, they are all managed by the same overseer and it can
continue to be the case. Yes, what operations block what is not formally
defined or enforced, which is something that can use some love.{quote}
Sure, that's just a hypothetical. I think what I wrote above is the central
issue.
{quote}I understand what you are saying. I did the same for Overseer in
SOLR-6554 which grouped all related operations and moved them into their own
classes (ClusterStateMutator, SliceMutator etc). In fact, I'd argue that
SOLR-7855 didn't go far enough – it'd be great to have individual operations
completely separate from the message processor such that they can be easily
unit tested. I am very much on board with that.
I'm just a bit confused why we have an interface if we have just one
implementation (YAGNI!) e.g. OverseerMessageHandler and
OverseerMessageHandlerSelector. Similarily, OverseerCollectionProcessor doesn't
add much over OverseerProcessor except for the static
getOverseerMessageHandlerSelector method.{quote}
Well there are two OverseerMessageHandlers now :). I see below your concern is
mainly with the Selector.
{quote}I was referring to the OverseerMessageHandlerSelector actually. I
assumed that you foresee more than one implementation in the future which would
make the dispatching more complex, hence the comment. So to dispatch a request,
at level 1, you have the OverseerMessageHandlerSelector and at level 2, you
have an OverseerMessageHandler and at level 3, you have the processMessage
inside the OverseerMessageHandler which sends the request to the right handler
method. This is the complexity that I was referring to. Perhaps, we can get rid
of OverseerMessageHandlerSelector?{quote}
The OverseerMessageHandlerSelector was really just some scaffolding to help me
with the refactor. I don't have an objection to making a single non-interface
implementation of it. Or even a canonical implementation if we adopt the
"single this is where I send Overseer operation requests" interface (e.g. it
could just do some generic logic mapping the expanded info in the message with
the set of available message handlers). That should be another jira though.
> 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]
