Hey all,
Thanks for all the feedback since I last chimed in here; a lot to
think through for sure.
> This also has associated ways to: register end points and configuration,
> manage lifecycle, collect metrics, enforce security, logging, tracing, etc.
Thanks Noble - this list is super helpful i
The invoke API should be removed as it is not used anymore
--thanks
On Tue, Dec 7, 2021 at 12:34 AM Jason Gerlowski
wrote:
> Ah, ok. Do you know if it's still used by the overseer in some capacity?
>
> I expected it would be an internal API, and undocumented as such. But
> as far as I can tel
I'm +1 for modernization
I just wanted to highlight the hurdles we need to overcome to reach there
SolrRequestHandler is the current framework that serves all requests in
Solr. This also has associated ways to
- register end points and configuration
- manage lifecycle
- collect metrics
Ilan,
I missed addressing one aspect in your mail.
On Mon, Dec 6, 2021 at 8:37 PM Ilan Ginzburg wrote:
> Ishan,
>
> > > Using a string separate from the role definitions (Ishan) makes it too
> easy to have roles for which the default configuration is unknown.
> >
> > Ilan, can you please elabora
Hi all,
I think we've captured all recent feedback in the updated proposal. Thanks
to Mike and others for helping us streamline the proposal to better suit
the current overseer role. Thanks to Ilan and others for the concept of
defaultIfAbsent concept.
I think the proposal is not only complete, but
On Mon, Dec 6, 2021 at 9:18 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> I've updated the SIP document with the recent changes. Also, added a new
> section to provide guidance for adding new roles.
>
> On Mon, Dec 6, 2021 at 8:37 PM Ilan Ginzburg wrote:
>
>> Ishan,
>>
>> > > Usin
I've updated the SIP document with the recent changes. Also, added a new
section to provide guidance for adding new roles.
On Mon, Dec 6, 2021 at 8:37 PM Ilan Ginzburg wrote:
> Ishan,
>
> > > Using a string separate from the role definitions (Ishan) makes it too
> easy to have roles for which th
Ishan,
> > Using a string separate from the role definitions (Ishan) makes it too easy
> > to have roles for which the default configuration is unknown.
>
> Ilan, can you please elaborate (perhaps with an example) as to what you mean
> here?
If the default string for all roles for nodes with no
FYI, I misspelt "Amazon Ion" to "Amazon Eon". I meant this:
https://en.wikipedia.org/wiki/Ion_(serialization_format)
On Mon, Dec 6, 2021 at 6:56 PM Eric Pugh
wrote:
> I was actually poking around trying to find out who actually in the Ruby
> world uses the wt=ruby, and all the projects that inte
On Mon, Dec 6, 2021 at 6:38 PM Jan Høydahl wrote:
> > > Also, we should not put so much emhasis on "nodes without roles
> defined" as if that should be a common way of starting nodes in a huge
> cluster.
> >
> > Jan, the need to tackle "nodes without roles defined" separately is to
> cater to tho
Ah, ok. Do you know if it's still used by the overseer in some capacity?
I expected it would be an internal API, and undocumented as such. But
as far as I can tell it's dead-functionality currently. The "invoked"
classes have to implement an "Invocable" interface. At the time the
API was intro
I was actually poking around trying to find out who actually in the Ruby world
uses the wt=ruby, and all the projects that intersect with Solr seems to do
wt=json ;-)
> On Dec 6, 2021, at 8:17 AM, Jan Høydahl wrote:
>
> I'm happy to see that there is agreement in a shift towards standard..
>
I'm happy to see that there is agreement in a shift towards standard..
Bwt - in v3, lets get rid of "wt" parameter and instead use standard HTTP
Accept header to tell Solr whether you want the response as JSON or XML. Maybe
we are even ready to deprecate XML, PYTHON, XSLT, Excel..
See https://is
> > Also, we should not put so much emhasis on "nodes without roles defined" as
> > if that should be a common way of starting nodes in a huge cluster.
>
> Jan, the need to tackle "nodes without roles defined" separately is to cater
> to those users who do not use the roles functionality; we nee
It's an internal API and not advertised. IIRC , it's used by overseer to
invoke some functionality on nodes, but the API on the node itself is
undocumented (we do not expect users to know or use them)
On Mon, Dec 6, 2021, 10:51 PM Jason Gerlowski wrote:
> Hey all,
>
> The /admin/cores API has an
> Using a string separate from the role definitions (Ishan) makes it too
easy to have roles for which the default configuration is unknown.
Ilan, can you please elaborate (perhaps with an example) as to what you
mean here?
As per my proposal, a node that was started with explicit roles, but
withou
Hey all,
The /admin/cores API has an "INVOKE" subcommand. It takes in one or
more names of classes that implement an interface called 'Invocable'.
For each provided classname, the API loads the class and calls an
'invoke' method, if present. As best as I can tell from the git
history, it was int
Are we making a non-issue into a configuration mess?
The overseer's job is diminishing by every version, and we should not fool
ourself into believing that a stray overseer will kill an upgrade, and
therefore complicate the whole role system. Also, we should not put so much
emhasis on "nodes wi
Noble got my intention correctly.
I think role specific code should only have to deal with the various
configuration options for the role. When configuration was binary (role
defined or not), then the default is one of the two values, but even then
we saw that for data we wanted default true and f
19 matches
Mail list logo
