There were additional discussions that happened after this vote started, so
this vote is inconclusive/closed/failed.
On Fri, Nov 26, 2021 at 11:51 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Ah, I didn't realize that; thanks Mike. Lets extend this vote from 72
> hours to 1 week.
I'm +1 on this. It "looks" complicated at first, but simplifies all
headaches going forward.
On Sun, Dec 5, 2021 at 11:46 AM Noble Paul wrote:
> I shall update the SIP proposal if we have a consensus on this
> configuration
>
> On Sun, Dec 5, 2021 at 4:58 PM Noble Paul wrote:
>
>>
>>
>> On Sun,
I shall update the SIP proposal if we have a consensus on this configuration
On Sun, Dec 5, 2021 at 4:58 PM Noble Paul wrote:
>
>
> On Sun, Dec 5, 2021 at 4:47 PM Gus Heck wrote:
>
>> I like this in that it's an example of how the overseer might be extended
>> without creating a new role :)
>>
On Sat, Dec 4, 2021 at 3:32 AM Timothy Potter wrote:
> Why do we keep talking about Restlet here? Restlet is a stale (at
> best) project, so not sure why it keeps coming up in a discussion
> about modernizing our API? Integration with it in Solr was introduced
> nearly 10 years ago, time to move
Hi Tim,
You bring up great suggestions for improvement to Solr, I really think we
should do something to address all of those as soon as possible. However,
you misunderstand the comments here and mischaracterize Noble's intentions
here.
This discussion was about Jason discussing "Solr's custom an
On Sun, Dec 5, 2021 at 4:47 PM Gus Heck wrote:
> I like this in that it's an example of how the overseer might be extended
> without creating a new role :)
>
> Not entirely sure if I'm for or against an enum implementation here, but
> it makes me a bit nervous. Enums with complexity can quickly g
I like this in that it's an example of how the overseer might be extended
without creating a new role :)
Not entirely sure if I'm for or against an enum implementation here, but it
makes me a bit nervous. Enums with complexity can quickly get into
difficulty for unit tests (especially if one wante
typo
-
On Sun, Dec 5, 2021 at 2:37 PM Noble Paul wrote:
> I recommend the following format for the role spec
>
> roles=:
>
> each role will have an enum of allowed values and a default value
>
>
>- role name: *data*
> - values: [*on*, *off]*
> - default: *allowed*
>
>
-
On Sat, Dec 4, 2021 at 7:01 PM Ilan Ginzburg wrote:
> If we go with no negative node roles and overseer node role is not strict
> (i.e. it’s a "preferred overseer"), then one would need to define a second
> node role "no_overseer" to explicitly exclude a node from ever becoming
> overseer (which
I recommend the following format for the role spec
roles=:
each role will have an enum of allowed values and a default value
- role name: *data*
- values: [*on*, *off]*
- default: *allowed*
- role name: *overseer*
- values: [*allowed*, *disallowed*, *preferred]*
-
If we go with no negative node roles and overseer node role is not strict
(i.e. it’s a "preferred overseer"), then one would need to define a second
node role "no_overseer" to explicitly exclude a node from ever becoming
overseer (which I think is a useful feature until we switch the cluster
defaul
11 matches
Mail list logo
