Re: Welcome Namgyu Kim to the PMC

[Christian Moen]

Congrats, Namgyu!

On Mon, Aug 3, 2020 at 8:19 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I am pleased to announce that Namgyu Kim has accepted the PMC's
> invitation to join.
>
> Congratulations and welcome, Namgyu!
>

Re: Deprecate Schemaless Mode?

[Gus Heck]

On Mon, Aug 3, 2020 at 5:03 PM Erick Erickson 
wrote:

> Gus’s point about implementing something before removing it is well taken,
> but we can deprecate it immediately without removing it. Gus’s point about
> dynamic fields not being found until later in the cycle is well taken, but
> not enough to persuade me.
>
> Fair enough :)


> I’m not enthusiastic about multiple getting started schemas. The whole
> motivation behind schemaless is that the user doesn’t need to know about
> schemas to get started. By providing multiple “getting started” schemas we
> require them to become aware of schemas again.
>
> Here's my theory (which may or may not be persuasive :) )

My thinking in that suggestion is that the majority of the problem is due
to the fact that people new to a technology will tend to latch onto the
defaults that come with something as being something that should be held
onto until you have a good reason to change it. This is reasonable because
changing things you don't understand willy nilly is often a road to pain.
And people DO want a safe starting point and we should give it to them
because it makes their life easier once they get a little further down the
road, but this is not compatible with the easy-start schemaless mode.
Looking at https://lucene.apache.org/solr/guide/8_5/solr-tutorial.html I
see that the initial tutorial experience is fully scripted, and the user
won't likely notice if they are told to ignore _default or guessing-proto
in favor of the tech products config set... BUT when they do get to the
point of looking at the config name they'll see the more descriptive name.
So rather than seeing "_default" and thinking "Ah ha! Here's something I
can take as gospel and not change until I have a reason!" they'll see
"guessing-proto" or "dynamic-proto" and say "Hunh, I wonder what that
means?" which is a good question for them to ask I think.

The concept of a default lays in a strong bias of not touching it (IMHO)
which will be wrong most of the time no matter what we give them as  a
default. If something must be a default I'd favor a non-managed,
non-dynamic, non-guessing minimal schema with the required fields, and an
id field, maybe a _text_ field, and a comment pointing to the section of
the ref guide where they can copy and paste in all the stuff that's
currently in our base schema as example (things like the text_ga type), IF
they want it. I get really tired of seeing mile long schemas that have a
ton of unused stuff that is retained because people didn't know if they
needed it or not...

Note that not having some default would break back compat, on bin/solr but
changing the default is also a break of sorts.


>
> All that said, maybe we could rethink the approach. My two objections are:
> 1> schemaless, by updating the schema based on a very small sample set is
> very susceptible to failing early and often
> 2> Constantly updating the config in ZK and reloading the collections
> seems very hard to get right.
>

I have for some time thought the inability to upload and download a config
(or files within a config) via the web UI was a gap. But I found it easier
to write https://plugins.gradle.org/plugin/com.needhamsoftware.solr-gradle than
add that feature to the UI :)


> So I can imagine a “getting started” mode that indexed to the glob field
> while creating a schema. Ideally, it would be necessary to enable it
> specifically rather than have it be the default. I’d imagine this being
> coupled with some kind of “export schema” button. So the process would be
> > start Solr with -Dsolr.learningmode.confg=some_config_name.
> > index a bunch of documents, perhaps prototyping the search app on the
> dynamic glob field.
> > The admin UI should have a big, intrusive banner saying “RUNNING IN
> LEARNING MODE” with instructions on what to do next.
> > In that mode there’d need to be a “save schema” button or something.
> What I’d like that to do would be examine the index and write a new schema
> somewhere. If ths was the mode, then you’d be able to run it any time.
>

+1 for anything that makes a round-trip of working with the schema easier,
but not really a fan of learning mode.


>
>
>

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Houston Putman]

The vote has failed.

I'll create the RC2 once we've fixed the autoscaling
backwards-compatibility stuff.

- Houston

On Mon, Aug 3, 2020 at 2:23 PM Marcus Eagan  wrote:

> revising my vote to 0 (non-binding) because of collection creation
> failures cited by others. Until I can confirm or deny that things function
> properly, I will abstain. I will wait to run my test until after the ticket
> is addressed.
>
> Marcus
>
> On Mon, Aug 3, 2020 at 6:14 AM Atri Sharma  wrote:
>
>> Can confirm the failure seen by Gus. Changing my vote to 0.
>>
>> On Mon, 3 Aug 2020 at 17:50, Jan Høydahl  wrote:
>>
>>> I keep getting HDFS related test failures and timeouts, so I cannot
>>> vote. (macOS)
>>>
>>> Jan
>>>
>>> > 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
>>> >
>>> > +1
>>> >
>>> > SUCCESS! [1:27:33.14892]
>>> >
>>> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan 
>>> wrote:
>>> >>
>>> >> Community,
>>> >>
>>> >> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
>>> "Amazon Corretto 8"):
>>> >>
>>> >> SUCCESS! [1:33:51.132902]
>>> >>
>>> >> I'm still going through and checking a few aforementioned issues, but
>>> non-binding +1 from me. Wanted to share with the community because most
>>> probably are not running Corretto.
>>> >>
>>> >> Hope this helps.
>>> >>
>>> >> marcus
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
>>> >>>
>>> >>> Digging a little further, I notice that the deployment that had the
>>> error has this autoscaling (whereas the working deployment does not).
>>> >>>
>>> >>> "cluster-preferences":[{
>>> >>> "minimize":"cores",
>>> >>> "precision":1},
>>> >>> {"maximize":"freedisk"}],
>>> >>> "cluster-policy":[
>>> >>> {
>>> >>> "replica":"<2",
>>> >>> "shard":"#EACH",
>>> >>> "node":"#ANY",
>>> >>> "strict":"false"},
>>> >>> {
>>> >>> "replica":"#EQUAL",
>>> >>> "node":"#ANY",
>>> >>> "strict":"false"},
>>> >>> {
>>> >>> "cores":"#EQUAL",
>>> >>> "node":"#ANY",
>>> >>> "strict":"false"}],
>>> >>>
>>> >>> So this may raise the question of whether or not we have an issue
>>> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
>>> autoscaling's error messages, but it kinda looks dodgy too since "one extra
>>> tag in cores" appears to be referring to a cores attribute that has only
>>> one value, but no idea yet if I'm reading that error message right.  ... As
>>> to how I got that, I'm pretty sure it was one of the times when my edits to
>>> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
>>> probably was not clean, and retained the old config.
>>> >>>
>>> >>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late
>>> here now) and see if I get a similar result.
>>> >>>
>>> >>>
>>> >>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
>>> 
>>>  I Got:
>>> 
>>>  Ubuntu 18.04.4 LTS:
>>>  SUCCESS! [0:53:02.203047]
>>>  Mac OS 10.13:
>>> 
>>>  SUCCESS! [1:00:57.938586]
>>> 
>>> 
>>>  BUT... when I deployed the tarball locally and tried to create a
>>> collection (single shard, _default config, via the solr UI), I got:
>>> 
>>> 
>>>  2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
>>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
>>> 
>>>  2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
>>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
>>> 
>>>  2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
>>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
>>> 
>>>  2020-08-03 03:00:07.521 INFO
>>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>>> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
>>> 
>>>  2020-08-03 03:00:07.672 ERROR
>>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>>> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
>>> operation: create failed:org.apache.solr.common.SolrException
>>> 
>>>  at
>>> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
>>> 
>>>  at
>>> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
>>> 
>>>  at
>>> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
>>> 
>>>  at
>>> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
>>> 
>>>  at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> 
>>>  at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>> 
>>>  at java.lang.Thread.run(Thread.java:745)
>>> 
>>>  Caused by: java.lang.RuntimeException: Only one extra tag supported
>>> for the tag cores in {
>>> 
>>>   "cores":"#EQUAL",
>>> 
>>>   

Re: Deprecate Schemaless Mode?

[Erick Erickson]

Putting this up top so people will read it ;) Perhaps this is all just 
overthinking. Is the crux of the matter that schemaless is the default? Would 
it suffice to make it something that had to be explicitly enabled, rather than 
be something in solrconfig? In essence, flip the current way we do things where 
we can _disable_ schemaless via "bin/solr config -c mycollection -p 8983 
-action set-user-property -property update.autoCreateFields -value false” and 
instead have it off by default and require that people _enable_ it when desired?

I think my antipathy is rooted in the fact that OOB, Solr enables schemaless. 
New users then have to somewhere find out that buried in the 1,500 pages of the 
ref guide that they can’t search is a caution that you shouldn’t take Solr to 
production as it’s configured OOB. It’s far too easy to miss. At least if we 
required that people explicitly enable it they’d have some incentive to look at 
https://lucene.apache.org/solr/guide/8_5/schemaless-mode.html where we call out 
not using it in production. Currently there isn’t any incentive to understand 
anything about schemaless before blithely going to production.

OK, on to my antipathy, some of which directly contradicts the above….

Just because we have other “getting started” tools that aren’t recommended for 
production isn’t a justification for keeping something as problematic as 
schemaless. ExtractingRequestHandler is probably the closest in that it can 
unexpectedly blow up down the road. bin/post is reasonably safe, just 
inefficient.

Gus’s point about implementing something before removing it is well taken, but 
we can deprecate it immediately without removing it. Gus’s point about dynamic 
fields not being found until later in the cycle is well taken, but not enough 
to persuade me. 

I’m not enthusiastic about multiple getting started schemas. The whole 
motivation behind schemaless is that the user doesn’t need to know about 
schemas to get started. By providing multiple “getting started” schemas we 
require them to become aware of schemas again.

Sorry, Anshum, but "This feature isn't trappy unless people use it in ways it 
was not intended “ is not persuasive at all. If we have such intentions, we 
should enforce them. How, I don’t quite know however. How are users supposed to 
understand that some feature is or is not intended?

All that said, maybe we could rethink the approach. My two objections are:
1> schemaless, by updating the schema based on a very small sample set is very 
susceptible to failing early and often
2> Constantly updating the config in ZK and reloading the collections seems 
very hard to get right.

So I can imagine a “getting started” mode that indexed to the glob field while 
creating a schema. Ideally, it would be necessary to enable it specifically 
rather than have it be the default. I’d imagine this being coupled with some 
kind of “export schema” button. So the process would be
> start Solr with -Dsolr.learningmode.confg=some_config_name.
> index a bunch of documents, perhaps prototyping the search app on the dynamic 
> glob field.
> The admin UI should have a big, intrusive banner saying “RUNNING IN LEARNING 
> MODE” with instructions on what to do next.
> In that mode there’d need to be a “save schema” button or something. What I’d 
> like that to do would be examine the index and write a new schema somewhere. 
> If ths was the mode, then you’d be able to run it any time.



> On Aug 3, 2020, at 2:39 PM, Gus Heck  wrote:
> 
> I almost never use schemaless mode (better named "schema guessing mode") and 
> I would never recommend it for use beyond prototyping. The primary use I see 
> for it is to throw a bunch of data at it to get a starting point for a 
> schema... say for example you want to see what tika's going to produce for 
> metadata before solidifying what you will and will not rely on. I think the 
> ability to suggest a schema is valuable and shouldn't go away. I'm all for 
> not having it be the default configuration however, and I really like the 
> suggestions linked in the ticket for features that consider a number of 
> documents before trying to guess the schema and if we implement one of those 
> I'd be for deprecation and eventual removal, but not before.
> 
> The ticket contains a suggestion of adding a catch all '*' dynamic field, but 
> we should make sure to indicate that that ALSO is not typically good for 
> production use because one garbage (or malicious) document can explode the 
> number of fields in the index, or cause cases where forgetting to add a 
> properly typed field makes it much further down the development cycle before 
> getting caught. (i.e. not caught until a user tries to sort on it and gets 1, 
> 10, 11, 2,... ), and dev churn due to data silently indexed into typo 
> variants etc.
> 
> Perhaps we should distribute more than one pre-baked config set and label 
> none of them as "default"? I'd suggest maybe
>   • 

Re: SolrClient and making requests asynchronously

[Marcus Eagan]

+1  I and a few of my former Lucidworks colleagues know the pain of the
synchronous client very well.

Thanks for the first step toward an improved design Dat and  David Smiley!

Marcus
On Sun, Aug 2, 2020 at 07:47 Atri Sharma  wrote:

> I am +1 to this approach. Some thoughts inline.
>
> How would query timeout be respected in this approach?
>
>>
>
>  The default approach might be configured to throw
>> UnsupportedOperationException, or perhaps might simply use an Executor to
>> get it done in an obvious way (assuming we can get ahold of an Executor
>> somewhere?).
>>
>
> Would that mean that we use an Executor to execute a single thread?
>
>
> >>
> CompletableFuture, and which merely takes the SolrRequest parameter and
> nothing else.  Alternatively the client could supply a CompletableFuture
> parameter that Solr will call complete() on etc. but that seems a bit less
> natural to the notion of a method that returns it's results, albeit with a
> wrapper.
>
> I would think that we allow users to specify their callback. One of the
> advantages of AsyncListener is that it a custom implementation can allow
> users to handle the behaviour of timeout and other events. We should retain
> that behaviour.
> --
> Regards,
>
> Atri
> Apache Concerted
>
-- 
Marcus Eagan

Re: Deprecate Schemaless Mode?

[Marcus Eagan]

Typo*, I meant deprecate vs. remove, which obviously cannot do.

On Mon, Aug 3, 2020 at 12:05 Marcus Eagan  wrote:

> Furthermore, just to be clear, I opened a discussion about deprecating and
> not replacing schemaless mode for two reasons:
>
> (1) the pain it has inflicted on Solr users and reputation of Solr —
> deprecation logs speak volumes.
> (2) to get a better understanding of what engineers and others in the
> community use Schemaless for to inform the design of its replacement.
>
> At no point would I argue that a feature like Schemaless is unnecessary.
> It was the first way I used Solr (the second time around, the first time I
> tried it I built my company using Elasticsearch because of other issues). I
> am of the opinion that "Schemaless Mode" has done more harm to Solr than
> good in my limited experience with the feature. Heck, *I've only been
> consulting for a week and it has already come up*. I acknowledge a very
> small sample size.
>
> I am curious as to your thoughts on these points. There are not lots of
> people getting started with Solr today relative to the other solutions on
> the market regardless of what you might assume. I am here to see if I can
> change that through a shift in how we approach user experience and the
> knowledge requisite to operate a production cluster. I hope no one takes
> offense to me challenging how some community members think about what is a
> good feature vs what is a bad one.
>
> Marcus
>
>
>
>
> On Mon, Aug 3, 2020 at 11:44 AM Marcus Eagan 
> wrote:
>
>> I know a person using it in production today. It's causing problems. They
>> could abandon Solr altogether. It seems like a schema creation wizard is
>> the right getting started motion if we know that schemaless doesn't do what
>> people think it does. It's misleading. It's also a false representation of
>> how easy it is to get started when compared to other solutions on the
>> market. If schemaless is about support new use/adoption, it should actually
>> help that more than hurt it.
>>
>> That's why I raised it. Re-branding this feature is like pig-lipsticking
>> in my mind, but you all have more experience than me and are committers. I
>> will defer to you for now. I am in favor on re-naming the feature as the
>> minimum change that should happen.
>>
>> Schemaless mode makes sense in a world where schemas are largely opaque
>> like IoT-telemetry or server logs. When you are searching data primarily
>> for human consumption, I think it is just a headache in a bottle. In the
>> cases of CSV and TSV, customers know the schema. I like to approach
>> designing software such that no one ever needs to talk to me. No
>> firefighting consulting is necessary, and you can skim the docs and proceed
>> safely. I understand others may not feel that way, but it is the future of
>> software.
>>
>> I encourage everyone here to try the newer search systems that have been
>> released and are growing rapidly to inform your opinions on this topic. I
>> am doing that because it is the concrete poured to build the common ground
>> of the future.
>>
>> On Mon, Aug 3, 2020 at 11:40 AM Anshum Gupta 
>> wrote:
>>
>>> +1 Jason.
>>>
>>> Here's some context on how this came into being.
>>>
>>> Users find it difficult to understand and create a basic schema when
>>> just trying out Solr. This mode was supposed to help them bootstrap, and
>>> one they had a better understanding of how things worked, they'd tune it
>>> before using the schema in production.
>>> This did improve the OTB experience for new users, but a lot of people
>>> abused this convenience and used this in production causing issues.
>>>
>>> As Jason mentioned, we'd better serve our users if we left this feature
>>> for the getting started experience and add warnings (in UI and responses?)
>>> so users would know what they are doing when they take this to production.
>>>
>>> This feature isn't trappy unless people use it in ways it was not
>>> intended to be used in. We just need to warn and educate people better.
>>>
>>> On Mon, Aug 3, 2020 at 10:41 AM Jason Gerlowski 
>>> wrote:
>>>
 > Is anyone on this list using schemaless mode in production or have
 you tried to?

 Schemaless mode is one of a group of Solr features present for
 convenience but not intended for production usage.  It's in the same
 boat as "bin/post", and SolrCell, and others.  These features do cause
 headaches when users ignore the documented restrictions and use them
 for more than prototyping.  But at the same time they're super
 valuable for these sort of demo-ing or getting-started use cases.  An
 easy getting-started experience is important, and schemaless et al
 serve a mostly positive role in that.

 I think we'd better serve our users if we left schemaless
 in/undeprecated, and instead focused on making it harder to
 (unknowingly) use them in ways contrary to community recommendations.
 Add louder warnings in the 

Re: Welcome Namgyu Kim to the PMC

[jim ferenczi]

Congratulations Namgyu!

Le lun. 3 août 2020 à 18:27, Steve Rowe  a écrit :

> Congrats and welcome, Namgyu!
>
> --
> Steve
>
> > On Aug 2, 2020, at 7:18 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >
> > I am pleased to announce that Namgyu Kim has accepted the PMC's
> invitation to join.
> >
> > Congratulations and welcome, Namgyu!
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Deprecate Schemaless Mode?

[Marcus Eagan]

Furthermore, just to be clear, I opened a discussion about deprecating and
not replacing schemaless mode for two reasons:

(1) the pain it has inflicted on Solr users and reputation of Solr —
deprecation logs speak volumes.
(2) to get a better understanding of what engineers and others in the
community use Schemaless for to inform the design of its replacement.

At no point would I argue that a feature like Schemaless is unnecessary. It
was the first way I used Solr (the second time around, the first time I
tried it I built my company using Elasticsearch because of other issues). I
am of the opinion that "Schemaless Mode" has done more harm to Solr than
good in my limited experience with the feature. Heck, *I've only been
consulting for a week and it has already come up*. I acknowledge a very
small sample size.

I am curious as to your thoughts on these points. There are not lots of
people getting started with Solr today relative to the other solutions on
the market regardless of what you might assume. I am here to see if I can
change that through a shift in how we approach user experience and the
knowledge requisite to operate a production cluster. I hope no one takes
offense to me challenging how some community members think about what is a
good feature vs what is a bad one.

Marcus




On Mon, Aug 3, 2020 at 11:44 AM Marcus Eagan  wrote:

> I know a person using it in production today. It's causing problems. They
> could abandon Solr altogether. It seems like a schema creation wizard is
> the right getting started motion if we know that schemaless doesn't do what
> people think it does. It's misleading. It's also a false representation of
> how easy it is to get started when compared to other solutions on the
> market. If schemaless is about support new use/adoption, it should actually
> help that more than hurt it.
>
> That's why I raised it. Re-branding this feature is like pig-lipsticking
> in my mind, but you all have more experience than me and are committers. I
> will defer to you for now. I am in favor on re-naming the feature as the
> minimum change that should happen.
>
> Schemaless mode makes sense in a world where schemas are largely opaque
> like IoT-telemetry or server logs. When you are searching data primarily
> for human consumption, I think it is just a headache in a bottle. In the
> cases of CSV and TSV, customers know the schema. I like to approach
> designing software such that no one ever needs to talk to me. No
> firefighting consulting is necessary, and you can skim the docs and proceed
> safely. I understand others may not feel that way, but it is the future of
> software.
>
> I encourage everyone here to try the newer search systems that have been
> released and are growing rapidly to inform your opinions on this topic. I
> am doing that because it is the concrete poured to build the common ground
> of the future.
>
> On Mon, Aug 3, 2020 at 11:40 AM Anshum Gupta 
> wrote:
>
>> +1 Jason.
>>
>> Here's some context on how this came into being.
>>
>> Users find it difficult to understand and create a basic schema when just
>> trying out Solr. This mode was supposed to help them bootstrap, and one
>> they had a better understanding of how things worked, they'd tune it before
>> using the schema in production.
>> This did improve the OTB experience for new users, but a lot of people
>> abused this convenience and used this in production causing issues.
>>
>> As Jason mentioned, we'd better serve our users if we left this feature
>> for the getting started experience and add warnings (in UI and responses?)
>> so users would know what they are doing when they take this to production.
>>
>> This feature isn't trappy unless people use it in ways it was not
>> intended to be used in. We just need to warn and educate people better.
>>
>> On Mon, Aug 3, 2020 at 10:41 AM Jason Gerlowski 
>> wrote:
>>
>>> > Is anyone on this list using schemaless mode in production or have you
>>> tried to?
>>>
>>> Schemaless mode is one of a group of Solr features present for
>>> convenience but not intended for production usage.  It's in the same
>>> boat as "bin/post", and SolrCell, and others.  These features do cause
>>> headaches when users ignore the documented restrictions and use them
>>> for more than prototyping.  But at the same time they're super
>>> valuable for these sort of demo-ing or getting-started use cases.  An
>>> easy getting-started experience is important, and schemaless et al
>>> serve a mostly positive role in that.
>>>
>>> I think we'd better serve our users if we left schemaless
>>> in/undeprecated, and instead focused on making it harder to
>>> (unknowingly) use them in ways contrary to community recommendations.
>>> Add louder warnings in the documentation (where not already present).
>>> Add warnings to the Solr logs the first time these features are used.
>>> Disable them by default (where that makes sense).  Taken to the
>>> extreme, we could even add a section into Solr's 

Re: Deprecate Schemaless Mode?

[Marcus Eagan]

I know a person using it in production today. It's causing problems. They
could abandon Solr altogether. It seems like a schema creation wizard is
the right getting started motion if we know that schemaless doesn't do what
people think it does. It's misleading. It's also a false representation of
how easy it is to get started when compared to other solutions on the
market. If schemaless is about support new use/adoption, it should actually
help that more than hurt it.

That's why I raised it. Re-branding this feature is like pig-lipsticking in
my mind, but you all have more experience than me and are committers. I
will defer to you for now. I am in favor on re-naming the feature as the
minimum change that should happen.

Schemaless mode makes sense in a world where schemas are largely opaque
like IoT-telemetry or server logs. When you are searching data primarily
for human consumption, I think it is just a headache in a bottle. In the
cases of CSV and TSV, customers know the schema. I like to approach
designing software such that no one ever needs to talk to me. No
firefighting consulting is necessary, and you can skim the docs and proceed
safely. I understand others may not feel that way, but it is the future of
software.

I encourage everyone here to try the newer search systems that have been
released and are growing rapidly to inform your opinions on this topic. I
am doing that because it is the concrete poured to build the common ground
of the future.

On Mon, Aug 3, 2020 at 11:40 AM Anshum Gupta  wrote:

> +1 Jason.
>
> Here's some context on how this came into being.
>
> Users find it difficult to understand and create a basic schema when just
> trying out Solr. This mode was supposed to help them bootstrap, and one
> they had a better understanding of how things worked, they'd tune it before
> using the schema in production.
> This did improve the OTB experience for new users, but a lot of people
> abused this convenience and used this in production causing issues.
>
> As Jason mentioned, we'd better serve our users if we left this feature
> for the getting started experience and add warnings (in UI and responses?)
> so users would know what they are doing when they take this to production.
>
> This feature isn't trappy unless people use it in ways it was not intended
> to be used in. We just need to warn and educate people better.
>
> On Mon, Aug 3, 2020 at 10:41 AM Jason Gerlowski 
> wrote:
>
>> > Is anyone on this list using schemaless mode in production or have you
>> tried to?
>>
>> Schemaless mode is one of a group of Solr features present for
>> convenience but not intended for production usage.  It's in the same
>> boat as "bin/post", and SolrCell, and others.  These features do cause
>> headaches when users ignore the documented restrictions and use them
>> for more than prototyping.  But at the same time they're super
>> valuable for these sort of demo-ing or getting-started use cases.  An
>> easy getting-started experience is important, and schemaless et al
>> serve a mostly positive role in that.
>>
>> I think we'd better serve our users if we left schemaless
>> in/undeprecated, and instead focused on making it harder to
>> (unknowingly) use them in ways contrary to community recommendations.
>> Add louder warnings in the documentation (where not already present).
>> Add warnings to the Solr logs the first time these features are used.
>> Disable them by default (where that makes sense).  Taken to the
>> extreme, we could even add a section into Solr's response that lists
>> non-production features used in serving a given request.
>>
>> There are lots of ways to address the "feature X is trappy" problem
>> without removing X together.
>>
>> On Mon, Aug 3, 2020 at 11:33 AM Marcus Eagan 
>> wrote:
>> >
>> > Community,
>> >
>> > There are many of us that have had to deal with the pain of managing
>> the schemaless mode of operation in Solr. I'm curious to get others
>> thoughts about how well it is working for them and if they would like to
>> continue to use it.
>> >
>> > I for one don't think Schemaless works as intended and favor
>> deprecating it and replacing it with some more usable but I am sure others
>> have thoughts here.
>> >
>> > Is anyone on this list using schemaless mode in production or have you
>> tried to?
>> >
>> > A preliminary discussion has occurred in this Jira ticket:
>> https://issues.apache.org/jira/browse/SOLR-14701
>> >
>> > Thank you all,
>> >
>> > Marcus Eagan
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>


-- 
Marcus Eagan

Re: Deprecate Schemaless Mode?

[Anshum Gupta]

+1 Jason.

Here's some context on how this came into being.

Users find it difficult to understand and create a basic schema when just
trying out Solr. This mode was supposed to help them bootstrap, and one
they had a better understanding of how things worked, they'd tune it before
using the schema in production.
This did improve the OTB experience for new users, but a lot of people
abused this convenience and used this in production causing issues.

As Jason mentioned, we'd better serve our users if we left this feature for
the getting started experience and add warnings (in UI and responses?) so
users would know what they are doing when they take this to production.

This feature isn't trappy unless people use it in ways it was not intended
to be used in. We just need to warn and educate people better.

On Mon, Aug 3, 2020 at 10:41 AM Jason Gerlowski 
wrote:

> > Is anyone on this list using schemaless mode in production or have you
> tried to?
>
> Schemaless mode is one of a group of Solr features present for
> convenience but not intended for production usage.  It's in the same
> boat as "bin/post", and SolrCell, and others.  These features do cause
> headaches when users ignore the documented restrictions and use them
> for more than prototyping.  But at the same time they're super
> valuable for these sort of demo-ing or getting-started use cases.  An
> easy getting-started experience is important, and schemaless et al
> serve a mostly positive role in that.
>
> I think we'd better serve our users if we left schemaless
> in/undeprecated, and instead focused on making it harder to
> (unknowingly) use them in ways contrary to community recommendations.
> Add louder warnings in the documentation (where not already present).
> Add warnings to the Solr logs the first time these features are used.
> Disable them by default (where that makes sense).  Taken to the
> extreme, we could even add a section into Solr's response that lists
> non-production features used in serving a given request.
>
> There are lots of ways to address the "feature X is trappy" problem
> without removing X together.
>
> On Mon, Aug 3, 2020 at 11:33 AM Marcus Eagan 
> wrote:
> >
> > Community,
> >
> > There are many of us that have had to deal with the pain of managing the
> schemaless mode of operation in Solr. I'm curious to get others thoughts
> about how well it is working for them and if they would like to continue to
> use it.
> >
> > I for one don't think Schemaless works as intended and favor deprecating
> it and replacing it with some more usable but I am sure others have
> thoughts here.
> >
> > Is anyone on this list using schemaless mode in production or have you
> tried to?
> >
> > A preliminary discussion has occurred in this Jira ticket:
> https://issues.apache.org/jira/browse/SOLR-14701
> >
> > Thank you all,
> >
> > Marcus Eagan
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: Deprecate Schemaless Mode?

[Gus Heck]

I almost never use schemaless mode (better named "schema guessing mode")
and I would never recommend it for use beyond prototyping. The primary use
I see for it is to throw a bunch of data at it to get a starting point for
a schema... say for example you want to see what tika's going to produce
for metadata before solidifying what you will and will not rely on. I think
the ability to suggest a schema is valuable and shouldn't go away. I'm all
for not having it be the default configuration however, and I really like
the suggestions linked in the ticket for features that consider a number of
documents before trying to guess the schema and if we implement one of
those I'd be for deprecation and eventual removal, but not before.

The ticket contains a suggestion of adding a catch all '*' dynamic field,
but we should make sure to indicate that that ALSO is not typically good
for production use because one garbage (or malicious) document can explode
the number of fields in the index, or cause cases where forgetting to add a
properly typed field makes it much further down the development cycle
before getting caught. (i.e. not caught until a user tries to sort on it
and gets 1, 10, 11, 2,... ), and dev churn due to data silently indexed
into typo variants etc.

Perhaps we should distribute more than one pre-baked config set and
label none of them as "default"? I'd suggest maybe

   - guessing-proto --> our current _default possibly refined, for
   protoytping
   - dynamic-proto --> a schema based on dynamic fields with a * default to
   text-general as an alternative prototyping tool less dependent on data
   order, but requiring more editing
   - managed-min --> A base on which to build a production quality managed
   schema
   - static-min --> A base on which to build a production quality classic
   (non-managed) schema

Also +1 to renaming the feature away from "Schemaless" to "Schema Guessing"

-Gus

On Mon, Aug 3, 2020 at 11:33 AM Marcus Eagan  wrote:

> Community,
>
> There are many of us that have had to deal with the pain of managing the
> schemaless mode of operation in Solr. I'm curious to get others thoughts
> about how well it is working for them and if they would like to continue to
> use it.
>
> I for one don't think Schemaless works as intended and favor deprecating
> it and replacing it with some more usable but I am sure others have
> thoughts here.
>
> Is anyone on this list using schemaless mode in production or have you
> tried to?
>
> A preliminary discussion has occurred in this Jira ticket:
> https://issues.apache.org/jira/browse/SOLR-14701
> 
>
> Thank you all,
>
> Marcus Eagan
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Deprecate Schemaless Mode?

[Jan Høydahl]

I’m against deprecating it.

Can we rename the feature as SchemaGuessing or FieldGuessing mode? That would 
set expectations right from the start. 

You may want to ask the user community too, but ask if they use it in 
development, and if they like it, since it is not made for prod use :)

Jan Høydahl

>> 3. aug. 2020 kl. 20:05 skrev Tomás Fernández Löbbe :
> 
> Agree with Jason. It's useful for prototyping and developing. I remember 
> seeing some warnings about it (in the logs?), but maybe we need more?
> 
>> On Mon, Aug 3, 2020 at 10:41 AM Jason Gerlowski  
>> wrote:
>> > Is anyone on this list using schemaless mode in production or have you 
>> > tried to?
>> 
>> Schemaless mode is one of a group of Solr features present for
>> convenience but not intended for production usage.  It's in the same
>> boat as "bin/post", and SolrCell, and others.  These features do cause
>> headaches when users ignore the documented restrictions and use them
>> for more than prototyping.  But at the same time they're super
>> valuable for these sort of demo-ing or getting-started use cases.  An
>> easy getting-started experience is important, and schemaless et al
>> serve a mostly positive role in that.
>> 
>> I think we'd better serve our users if we left schemaless
>> in/undeprecated, and instead focused on making it harder to
>> (unknowingly) use them in ways contrary to community recommendations.
>> Add louder warnings in the documentation (where not already present).
>> Add warnings to the Solr logs the first time these features are used.
>> Disable them by default (where that makes sense).  Taken to the
>> extreme, we could even add a section into Solr's response that lists
>> non-production features used in serving a given request.
>> 
>> There are lots of ways to address the "feature X is trappy" problem
>> without removing X together.
>> 
>> On Mon, Aug 3, 2020 at 11:33 AM Marcus Eagan  wrote:
>> >
>> > Community,
>> >
>> > There are many of us that have had to deal with the pain of managing the 
>> > schemaless mode of operation in Solr. I'm curious to get others thoughts 
>> > about how well it is working for them and if they would like to continue 
>> > to use it.
>> >
>> > I for one don't think Schemaless works as intended and favor deprecating 
>> > it and replacing it with some more usable but I am sure others have 
>> > thoughts here.
>> >
>> > Is anyone on this list using schemaless mode in production or have you 
>> > tried to?
>> >
>> > A preliminary discussion has occurred in this Jira ticket: 
>> > https://issues.apache.org/jira/browse/SOLR-14701
>> >
>> > Thank you all,
>> >
>> > Marcus Eagan
>> >
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Marcus Eagan]

revising my vote to 0 (non-binding) because of collection creation failures
cited by others. Until I can confirm or deny that things function properly,
I will abstain. I will wait to run my test until after the ticket is
addressed.

Marcus

On Mon, Aug 3, 2020 at 6:14 AM Atri Sharma  wrote:

> Can confirm the failure seen by Gus. Changing my vote to 0.
>
> On Mon, 3 Aug 2020 at 17:50, Jan Høydahl  wrote:
>
>> I keep getting HDFS related test failures and timeouts, so I cannot vote.
>> (macOS)
>>
>> Jan
>>
>> > 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
>> >
>> > +1
>> >
>> > SUCCESS! [1:27:33.14892]
>> >
>> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan 
>> wrote:
>> >>
>> >> Community,
>> >>
>> >> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
>> "Amazon Corretto 8"):
>> >>
>> >> SUCCESS! [1:33:51.132902]
>> >>
>> >> I'm still going through and checking a few aforementioned issues, but
>> non-binding +1 from me. Wanted to share with the community because most
>> probably are not running Corretto.
>> >>
>> >> Hope this helps.
>> >>
>> >> marcus
>> >>
>> >>
>> >>
>> >> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
>> >>>
>> >>> Digging a little further, I notice that the deployment that had the
>> error has this autoscaling (whereas the working deployment does not).
>> >>>
>> >>> "cluster-preferences":[{
>> >>> "minimize":"cores",
>> >>> "precision":1},
>> >>> {"maximize":"freedisk"}],
>> >>> "cluster-policy":[
>> >>> {
>> >>> "replica":"<2",
>> >>> "shard":"#EACH",
>> >>> "node":"#ANY",
>> >>> "strict":"false"},
>> >>> {
>> >>> "replica":"#EQUAL",
>> >>> "node":"#ANY",
>> >>> "strict":"false"},
>> >>> {
>> >>> "cores":"#EQUAL",
>> >>> "node":"#ANY",
>> >>> "strict":"false"}],
>> >>>
>> >>> So this may raise the question of whether or not we have an issue
>> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
>> autoscaling's error messages, but it kinda looks dodgy too since "one extra
>> tag in cores" appears to be referring to a cores attribute that has only
>> one value, but no idea yet if I'm reading that error message right.  ... As
>> to how I got that, I'm pretty sure it was one of the times when my edits to
>> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
>> probably was not clean, and retained the old config.
>> >>>
>> >>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late
>> here now) and see if I get a similar result.
>> >>>
>> >>>
>> >>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
>> 
>>  I Got:
>> 
>>  Ubuntu 18.04.4 LTS:
>>  SUCCESS! [0:53:02.203047]
>>  Mac OS 10.13:
>> 
>>  SUCCESS! [1:00:57.938586]
>> 
>> 
>>  BUT... when I deployed the tarball locally and tried to create a
>> collection (single shard, _default config, via the solr UI), I got:
>> 
>> 
>>  2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
>> 
>>  2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
>> 
>>  2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
>> 
>>  2020-08-03 03:00:07.521 INFO
>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
>> 
>>  2020-08-03 03:00:07.672 ERROR
>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
>> operation: create failed:org.apache.solr.common.SolrException
>> 
>>  at
>> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
>> 
>>  at
>> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
>> 
>>  at
>> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
>> 
>>  at
>> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
>> 
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 
>>  at java.lang.Thread.run(Thread.java:745)
>> 
>>  Caused by: java.lang.RuntimeException: Only one extra tag supported
>> for the tag cores in {
>> 
>>   "cores":"#EQUAL",
>> 
>>   "node":"#ANY",
>> 
>>   "strict":"false"}
>> 
>>  at
>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
>> 
>>  at
>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
>> 
>>  at
>> 

Re: Deprecate Schemaless Mode?

[Tomás Fernández Löbbe]

Agree with Jason. It's useful for prototyping and developing. I remember
seeing some warnings about it (in the logs?), but maybe we need more?

On Mon, Aug 3, 2020 at 10:41 AM Jason Gerlowski 
wrote:

> > Is anyone on this list using schemaless mode in production or have you
> tried to?
>
> Schemaless mode is one of a group of Solr features present for
> convenience but not intended for production usage.  It's in the same
> boat as "bin/post", and SolrCell, and others.  These features do cause
> headaches when users ignore the documented restrictions and use them
> for more than prototyping.  But at the same time they're super
> valuable for these sort of demo-ing or getting-started use cases.  An
> easy getting-started experience is important, and schemaless et al
> serve a mostly positive role in that.
>
> I think we'd better serve our users if we left schemaless
> in/undeprecated, and instead focused on making it harder to
> (unknowingly) use them in ways contrary to community recommendations.
> Add louder warnings in the documentation (where not already present).
> Add warnings to the Solr logs the first time these features are used.
> Disable them by default (where that makes sense).  Taken to the
> extreme, we could even add a section into Solr's response that lists
> non-production features used in serving a given request.
>
> There are lots of ways to address the "feature X is trappy" problem
> without removing X together.
>
> On Mon, Aug 3, 2020 at 11:33 AM Marcus Eagan 
> wrote:
> >
> > Community,
> >
> > There are many of us that have had to deal with the pain of managing the
> schemaless mode of operation in Solr. I'm curious to get others thoughts
> about how well it is working for them and if they would like to continue to
> use it.
> >
> > I for one don't think Schemaless works as intended and favor deprecating
> it and replacing it with some more usable but I am sure others have
> thoughts here.
> >
> > Is anyone on this list using schemaless mode in production or have you
> tried to?
> >
> > A preliminary discussion has occurred in this Jira ticket:
> https://issues.apache.org/jira/browse/SOLR-14701
> >
> > Thank you all,
> >
> > Marcus Eagan
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Deprecate Schemaless Mode?

[Jason Gerlowski]

> Is anyone on this list using schemaless mode in production or have you tried 
> to?

Schemaless mode is one of a group of Solr features present for
convenience but not intended for production usage.  It's in the same
boat as "bin/post", and SolrCell, and others.  These features do cause
headaches when users ignore the documented restrictions and use them
for more than prototyping.  But at the same time they're super
valuable for these sort of demo-ing or getting-started use cases.  An
easy getting-started experience is important, and schemaless et al
serve a mostly positive role in that.

I think we'd better serve our users if we left schemaless
in/undeprecated, and instead focused on making it harder to
(unknowingly) use them in ways contrary to community recommendations.
Add louder warnings in the documentation (where not already present).
Add warnings to the Solr logs the first time these features are used.
Disable them by default (where that makes sense).  Taken to the
extreme, we could even add a section into Solr's response that lists
non-production features used in serving a given request.

There are lots of ways to address the "feature X is trappy" problem
without removing X together.

On Mon, Aug 3, 2020 at 11:33 AM Marcus Eagan  wrote:
>
> Community,
>
> There are many of us that have had to deal with the pain of managing the 
> schemaless mode of operation in Solr. I'm curious to get others thoughts 
> about how well it is working for them and if they would like to continue to 
> use it.
>
> I for one don't think Schemaless works as intended and favor deprecating it 
> and replacing it with some more usable but I am sure others have thoughts 
> here.
>
> Is anyone on this list using schemaless mode in production or have you tried 
> to?
>
> A preliminary discussion has occurred in this Jira ticket: 
> https://issues.apache.org/jira/browse/SOLR-14701
>
> Thank you all,
>
> Marcus Eagan
>

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

Re: Welcome Gus Heck to the PMC

[Steve Rowe]

Congrats and welcome, Gus!

--
Steve

> On Aug 2, 2020, at 7:20 PM, Ishan Chattopadhyaya  
> wrote:
> 
> I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
> join.
> 
> Congratulations and welcome, Gus!


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

Re: Welcome Namgyu Kim to the PMC

[Steve Rowe]

Congrats and welcome, Namgyu!

--
Steve

> On Aug 2, 2020, at 7:18 PM, Ishan Chattopadhyaya  
> wrote:
> 
> I am pleased to announce that Namgyu Kim has accepted the PMC's invitation to 
> join.
> 
> Congratulations and welcome, Namgyu!


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

Re: Welcome Munendra SN to the PMC

[Steve Rowe]

Congrats and welcome, Munendra!

--
Steve

> On Aug 2, 2020, at 7:19 PM, Ishan Chattopadhyaya  
> wrote:
> 
> I am pleased to announce that Munendra SN has accepted the PMC's invitation 
> to join.
> 
> Congratulations and welcome, Munendra!


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

Deprecate Schemaless Mode?

[Marcus Eagan]

Community,

There are many of us that have had to deal with the pain of managing the
schemaless mode of operation in Solr. I'm curious to get others thoughts
about how well it is working for them and if they would like to continue to
use it.

I for one don't think Schemaless works as intended and favor deprecating it
and replacing it with some more usable but I am sure others have thoughts
here.

Is anyone on this list using schemaless mode in production or have you
tried to?

A preliminary discussion has occurred in this Jira ticket:
https://issues.apache.org/jira/browse/SOLR-14701


Thank you all,

Marcus Eagan

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Atri Sharma]

Can confirm the failure seen by Gus. Changing my vote to 0.

On Mon, 3 Aug 2020 at 17:50, Jan Høydahl  wrote:

> I keep getting HDFS related test failures and timeouts, so I cannot vote.
> (macOS)
>
> Jan
>
> > 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
> >
> > +1
> >
> > SUCCESS! [1:27:33.14892]
> >
> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan 
> wrote:
> >>
> >> Community,
> >>
> >> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
> "Amazon Corretto 8"):
> >>
> >> SUCCESS! [1:33:51.132902]
> >>
> >> I'm still going through and checking a few aforementioned issues, but
> non-binding +1 from me. Wanted to share with the community because most
> probably are not running Corretto.
> >>
> >> Hope this helps.
> >>
> >> marcus
> >>
> >>
> >>
> >> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
> >>>
> >>> Digging a little further, I notice that the deployment that had the
> error has this autoscaling (whereas the working deployment does not).
> >>>
> >>> "cluster-preferences":[{
> >>> "minimize":"cores",
> >>> "precision":1},
> >>> {"maximize":"freedisk"}],
> >>> "cluster-policy":[
> >>> {
> >>> "replica":"<2",
> >>> "shard":"#EACH",
> >>> "node":"#ANY",
> >>> "strict":"false"},
> >>> {
> >>> "replica":"#EQUAL",
> >>> "node":"#ANY",
> >>> "strict":"false"},
> >>> {
> >>> "cores":"#EQUAL",
> >>> "node":"#ANY",
> >>> "strict":"false"}],
> >>>
> >>> So this may raise the question of whether or not we have an issue
> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
> autoscaling's error messages, but it kinda looks dodgy too since "one extra
> tag in cores" appears to be referring to a cores attribute that has only
> one value, but no idea yet if I'm reading that error message right.  ... As
> to how I got that, I'm pretty sure it was one of the times when my edits to
> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
> probably was not clean, and retained the old config.
> >>>
> >>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late
> here now) and see if I get a similar result.
> >>>
> >>>
> >>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
> 
>  I Got:
> 
>  Ubuntu 18.04.4 LTS:
>  SUCCESS! [0:53:02.203047]
>  Mac OS 10.13:
> 
>  SUCCESS! [1:00:57.938586]
> 
> 
>  BUT... when I deployed the tarball locally and tried to create a
> collection (single shard, _default config, via the solr UI), I got:
> 
> 
>  2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
> 
>  2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
> 
>  2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
> 
>  2020-08-03 03:00:07.521 INFO
> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
> 
>  2020-08-03 03:00:07.672 ERROR
> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
> operation: create failed:org.apache.solr.common.SolrException
> 
>  at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
> 
>  at
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
> 
>  at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
> 
>  at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
> 
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 
>  at java.lang.Thread.run(Thread.java:745)
> 
>  Caused by: java.lang.RuntimeException: Only one extra tag supported
> for the tag cores in {
> 
>   "cores":"#EQUAL",
> 
>   "node":"#ANY",
> 
>   "strict":"false"}
> 
>  at
> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
> 
>  at
> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
> 
>  at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 
>  at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 
>  at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 
>  at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 
>  at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 
>  at
> 

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Gus Heck]

https://issues.apache.org/jira/browse/SOLR-14706

On Mon, Aug 3, 2020 at 8:29 AM Gus Heck  wrote:

> I have reproduced the stack trace above and condition where collections
> cannot be created by upgrading an 8.6.0 with 8.6.1, filing an issue right
> now, changing my vote to -1 from +0
>
>
> On Mon, Aug 3, 2020 at 8:20 AM Jan Høydahl  wrote:
>
>> I keep getting HDFS related test failures and timeouts, so I cannot vote.
>> (macOS)
>>
>> Jan
>>
>> > 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
>> >
>> > +1
>> >
>> > SUCCESS! [1:27:33.14892]
>> >
>> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan 
>> wrote:
>> >>
>> >> Community,
>> >>
>> >> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
>> "Amazon Corretto 8"):
>> >>
>> >> SUCCESS! [1:33:51.132902]
>> >>
>> >> I'm still going through and checking a few aforementioned issues, but
>> non-binding +1 from me. Wanted to share with the community because most
>> probably are not running Corretto.
>> >>
>> >> Hope this helps.
>> >>
>> >> marcus
>> >>
>> >>
>> >>
>> >> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
>> >>>
>> >>> Digging a little further, I notice that the deployment that had the
>> error has this autoscaling (whereas the working deployment does not).
>> >>>
>> >>> "cluster-preferences":[{
>> >>> "minimize":"cores",
>> >>> "precision":1},
>> >>> {"maximize":"freedisk"}],
>> >>> "cluster-policy":[
>> >>> {
>> >>> "replica":"<2",
>> >>> "shard":"#EACH",
>> >>> "node":"#ANY",
>> >>> "strict":"false"},
>> >>> {
>> >>> "replica":"#EQUAL",
>> >>> "node":"#ANY",
>> >>> "strict":"false"},
>> >>> {
>> >>> "cores":"#EQUAL",
>> >>> "node":"#ANY",
>> >>> "strict":"false"}],
>> >>>
>> >>> So this may raise the question of whether or not we have an issue
>> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
>> autoscaling's error messages, but it kinda looks dodgy too since "one extra
>> tag in cores" appears to be referring to a cores attribute that has only
>> one value, but no idea yet if I'm reading that error message right.  ... As
>> to how I got that, I'm pretty sure it was one of the times when my edits to
>> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
>> probably was not clean, and retained the old config.
>> >>>
>> >>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late
>> here now) and see if I get a similar result.
>> >>>
>> >>>
>> >>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
>> 
>>  I Got:
>> 
>>  Ubuntu 18.04.4 LTS:
>>  SUCCESS! [0:53:02.203047]
>>  Mac OS 10.13:
>> 
>>  SUCCESS! [1:00:57.938586]
>> 
>> 
>>  BUT... when I deployed the tarball locally and tried to create a
>> collection (single shard, _default config, via the solr UI), I got:
>> 
>> 
>>  2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
>> 
>>  2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
>> 
>>  2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
>> 
>>  2020-08-03 03:00:07.521 INFO
>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
>> 
>>  2020-08-03 03:00:07.672 ERROR
>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
>> operation: create failed:org.apache.solr.common.SolrException
>> 
>>  at
>> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
>> 
>>  at
>> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
>> 
>>  at
>> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
>> 
>>  at
>> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
>> 
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 
>>  at java.lang.Thread.run(Thread.java:745)
>> 
>>  Caused by: java.lang.RuntimeException: Only one extra tag supported
>> for the tag cores in {
>> 
>>   "cores":"#EQUAL",
>> 
>>   "node":"#ANY",
>> 
>>   "strict":"false"}
>> 
>>  at
>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
>> 
>>  at
>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
>> 
>>  at
>> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
>> 
>>  at
>> 

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Gus Heck]

I have reproduced the stack trace above and condition where collections
cannot be created by upgrading an 8.6.0 with 8.6.1, filing an issue right
now, changing my vote to -1 from +0


On Mon, Aug 3, 2020 at 8:20 AM Jan Høydahl  wrote:

> I keep getting HDFS related test failures and timeouts, so I cannot vote.
> (macOS)
>
> Jan
>
> > 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
> >
> > +1
> >
> > SUCCESS! [1:27:33.14892]
> >
> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan 
> wrote:
> >>
> >> Community,
> >>
> >> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
> "Amazon Corretto 8"):
> >>
> >> SUCCESS! [1:33:51.132902]
> >>
> >> I'm still going through and checking a few aforementioned issues, but
> non-binding +1 from me. Wanted to share with the community because most
> probably are not running Corretto.
> >>
> >> Hope this helps.
> >>
> >> marcus
> >>
> >>
> >>
> >> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
> >>>
> >>> Digging a little further, I notice that the deployment that had the
> error has this autoscaling (whereas the working deployment does not).
> >>>
> >>> "cluster-preferences":[{
> >>> "minimize":"cores",
> >>> "precision":1},
> >>> {"maximize":"freedisk"}],
> >>> "cluster-policy":[
> >>> {
> >>> "replica":"<2",
> >>> "shard":"#EACH",
> >>> "node":"#ANY",
> >>> "strict":"false"},
> >>> {
> >>> "replica":"#EQUAL",
> >>> "node":"#ANY",
> >>> "strict":"false"},
> >>> {
> >>> "cores":"#EQUAL",
> >>> "node":"#ANY",
> >>> "strict":"false"}],
> >>>
> >>> So this may raise the question of whether or not we have an issue
> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
> autoscaling's error messages, but it kinda looks dodgy too since "one extra
> tag in cores" appears to be referring to a cores attribute that has only
> one value, but no idea yet if I'm reading that error message right.  ... As
> to how I got that, I'm pretty sure it was one of the times when my edits to
> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
> probably was not clean, and retained the old config.
> >>>
> >>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late
> here now) and see if I get a similar result.
> >>>
> >>>
> >>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
> 
>  I Got:
> 
>  Ubuntu 18.04.4 LTS:
>  SUCCESS! [0:53:02.203047]
>  Mac OS 10.13:
> 
>  SUCCESS! [1:00:57.938586]
> 
> 
>  BUT... when I deployed the tarball locally and tried to create a
> collection (single shard, _default config, via the solr UI), I got:
> 
> 
>  2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
> 
>  2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
> 
>  2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
> 
>  2020-08-03 03:00:07.521 INFO
> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
> 
>  2020-08-03 03:00:07.672 ERROR
> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
> operation: create failed:org.apache.solr.common.SolrException
> 
>  at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
> 
>  at
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
> 
>  at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
> 
>  at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
> 
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 
>  at java.lang.Thread.run(Thread.java:745)
> 
>  Caused by: java.lang.RuntimeException: Only one extra tag supported
> for the tag cores in {
> 
>   "cores":"#EQUAL",
> 
>   "node":"#ANY",
> 
>   "strict":"false"}
> 
>  at
> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
> 
>  at
> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
> 
>  at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 
>  at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 
>  at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 
>  at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 
> 

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Atri Sharma]

Can you share some of those failures?

On Mon, 3 Aug 2020 at 17:50, Jan Høydahl  wrote:

> I keep getting HDFS related test failures and timeouts, so I cannot vote.
> (macOS)
>
> Jan
>
> > 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
> >
> > +1
> >
> > SUCCESS! [1:27:33.14892]
> >
> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan 
> wrote:
> >>
> >> Community,
> >>
> >> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
> "Amazon Corretto 8"):
> >>
> >> SUCCESS! [1:33:51.132902]
> >>
> >> I'm still going through and checking a few aforementioned issues, but
> non-binding +1 from me. Wanted to share with the community because most
> probably are not running Corretto.
> >>
> >> Hope this helps.
> >>
> >> marcus
> >>
> >>
> >>
> >> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
> >>>
> >>> Digging a little further, I notice that the deployment that had the
> error has this autoscaling (whereas the working deployment does not).
> >>>
> >>> "cluster-preferences":[{
> >>> "minimize":"cores",
> >>> "precision":1},
> >>> {"maximize":"freedisk"}],
> >>> "cluster-policy":[
> >>> {
> >>> "replica":"<2",
> >>> "shard":"#EACH",
> >>> "node":"#ANY",
> >>> "strict":"false"},
> >>> {
> >>> "replica":"#EQUAL",
> >>> "node":"#ANY",
> >>> "strict":"false"},
> >>> {
> >>> "cores":"#EQUAL",
> >>> "node":"#ANY",
> >>> "strict":"false"}],
> >>>
> >>> So this may raise the question of whether or not we have an issue
> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
> autoscaling's error messages, but it kinda looks dodgy too since "one extra
> tag in cores" appears to be referring to a cores attribute that has only
> one value, but no idea yet if I'm reading that error message right.  ... As
> to how I got that, I'm pretty sure it was one of the times when my edits to
> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
> probably was not clean, and retained the old config.
> >>>
> >>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late
> here now) and see if I get a similar result.
> >>>
> >>>
> >>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
> 
>  I Got:
> 
>  Ubuntu 18.04.4 LTS:
>  SUCCESS! [0:53:02.203047]
>  Mac OS 10.13:
> 
>  SUCCESS! [1:00:57.938586]
> 
> 
>  BUT... when I deployed the tarball locally and tried to create a
> collection (single shard, _default config, via the solr UI), I got:
> 
> 
>  2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
> 
>  2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
> 
>  2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
> 
>  2020-08-03 03:00:07.521 INFO
> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
> 
>  2020-08-03 03:00:07.672 ERROR
> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
> operation: create failed:org.apache.solr.common.SolrException
> 
>  at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
> 
>  at
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
> 
>  at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
> 
>  at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
> 
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 
>  at java.lang.Thread.run(Thread.java:745)
> 
>  Caused by: java.lang.RuntimeException: Only one extra tag supported
> for the tag cores in {
> 
>   "cores":"#EQUAL",
> 
>   "node":"#ANY",
> 
>   "strict":"false"}
> 
>  at
> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
> 
>  at
> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
> 
>  at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 
>  at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 
>  at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 
>  at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 
>  at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 
>  at
> 

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Jan Høydahl]

I keep getting HDFS related test failures and timeouts, so I cannot vote. 
(macOS)

Jan

> 3. aug. 2020 kl. 09:43 skrev Atri Sharma :
> 
> +1
> 
> SUCCESS! [1:27:33.14892]
> 
> On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan  wrote:
>> 
>> Community,
>> 
>> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64: 
>> "Amazon Corretto 8"):
>> 
>> SUCCESS! [1:33:51.132902]
>> 
>> I'm still going through and checking a few aforementioned issues, but 
>> non-binding +1 from me. Wanted to share with the community because most 
>> probably are not running Corretto.
>> 
>> Hope this helps.
>> 
>> marcus
>> 
>> 
>> 
>> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
>>> 
>>> Digging a little further, I notice that the deployment that had the error 
>>> has this autoscaling (whereas the working deployment does not).
>>> 
>>> "cluster-preferences":[{
>>> "minimize":"cores",
>>> "precision":1},
>>> {"maximize":"freedisk"}],
>>> "cluster-policy":[
>>> {
>>> "replica":"<2",
>>> "shard":"#EACH",
>>> "node":"#ANY",
>>> "strict":"false"},
>>> {
>>> "replica":"#EQUAL",
>>> "node":"#ANY",
>>> "strict":"false"},
>>> {
>>> "cores":"#EQUAL",
>>> "node":"#ANY",
>>> "strict":"false"}],
>>> 
>>> So this may raise the question of whether or not we have an issue upgrading 
>>> an 8.6.0 version to 8.6.1... also, not very familiar with autoscaling's 
>>> error messages, but it kinda looks dodgy too since "one extra tag in cores" 
>>> appears to be referring to a cores attribute that has only one value, but 
>>> no idea yet if I'm reading that error message right.  ... As to how I got 
>>> that, I'm pretty sure it was one of the times when my edits to cloud.sh 
>>> errored and  tried to deploy an existing branch_8x build. Zk probably was 
>>> not clean, and retained the old config.
>>> 
>>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late here 
>>> now) and see if I get a similar result.
>>> 
>>> 
>>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
 
 I Got:
 
 Ubuntu 18.04.4 LTS:
 SUCCESS! [0:53:02.203047]
 Mac OS 10.13:
 
 SUCCESS! [1:00:57.938586]
 
 
 BUT... when I deployed the tarball locally and tried to create a 
 collection (single shard, _default config, via the solr UI), I got:
 
 
 2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ] 
 o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
 
 2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ] 
 o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
 
 2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ] 
 o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
 
 2020-08-03 03:00:07.521 INFO  
 (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr) [ 
   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
 
 2020-08-03 03:00:07.672 ERROR 
 (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr) [ 
   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test 
 operation: create failed:org.apache.solr.common.SolrException
 
 at 
 org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
 
 at 
 org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
 
 at 
 org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
 
 at 
 org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
 
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 
 at java.lang.Thread.run(Thread.java:745)
 
 Caused by: java.lang.RuntimeException: Only one extra tag supported for 
 the tag cores in {
 
  "cores":"#EQUAL",
 
  "node":"#ANY",
 
  "strict":"false"}
 
 at 
 org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
 
 at 
 org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
 
 at 
 java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
 
 at 
 java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
 
 at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
 
 at 
 java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
 
 at 
 java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
 
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
 
 at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
 
 at 
 

BadApple report, but please read the first bit

[Erick Erickson]

There are several tests that are causing a lot of noise:

SharedFSAutoReplicaFailoverTest is failing 90%+ of the time.
TestBulkSchemaConcurrent 31%
StressHdfsTest  16%
SchemaApiFailureTest 13.88%

I encourage people to look at: 
http://fucit.org/solr-jenkins-reports/failure-report.html and see if anything 
looks like it is affected by recent work. TestBulkSchemaConcurrent has been 
failing off and on for a long time, but the failure rate picked up dramatically 
in the last couple of weeks. Ditto SchemaApiFailureTest.

Do we even care about Hdfs? Are we deprecating it or not?

Holding relatively steady otherwise:

Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0  had  82 failures
Week: 1  had  94 failures
Week: 2  had  502 failures
Week: 3  had  19 failures


Failures in Hoss' reports for the last 4 rollups.

There were 562 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   0.3 1271  8  RollingRestartTest.test
 0123  93.3   41 36  SharedFSAutoReplicaFailoverTest.test
 0123   3.5  627 16  
TestCircuitBreaker.testBuildingMemoryPressure
 0123   1.0  627  8  TestCircuitBreaker.testResponseWithCBTiming
 0123   5.8 1483 79  TestContainerPlugin.testApiFromPackage
 0123   2.3 1335 23  TestDistributedGrouping.test



Full report:
DO NOT ENABLE LIST:
MoveReplicaHDFSTest.testFailedMove
MoveReplicaHDFSTest.testNormalFailedMove
TestControlledRealTimeReopenThread.testCRTReopen
TestICUNormalizer2CharFilter.testRandomStrings
TestICUTokenizerCJK
TestImpersonationWithHadoopAuth.testForwarding
TestLTRReRankingPipeline.testDifferentTopN
TestRandomChains


DO NOT ANNOTATE LIST
CdcrBidirectionalTest.testBiDir
IndexSizeTriggerTest.testMergeIntegration
IndexSizeTriggerTest.testMixedBounds
IndexSizeTriggerTest.testSplitIntegration
IndexSizeTriggerTest.testTrigger
InfixSuggestersTest.testShutdownDuringBuild
ShardSplitTest.test
ShardSplitTest.testSplitMixedReplicaTypes
ShardSplitTest.testSplitWithChaosMonkey
Test2BPostings.test
TestLatLonShapeQueries.testRandomBig
TestPackedInts.testPackedLongValues
TestRandomChains.testRandomChainsWithLargeStrings
TestTriggerIntegration.testSearchRate

SuppressWarnings count: last week: 4,825, this week: 4,825, delta 0


*** Files with increased @SuppressWarnings annotations:


*** Files with decreased @SuppressWarnings annotations:


Processing file (History bit 3): HOSS-2020-08-03.csv
Processing file (History bit 2): HOSS-2020-07-27.csv
Processing file (History bit 1): HOSS-2020-07-20.csv
Processing file (History bit 0): HOSS-2020-07-13.csv


Number of AwaitsFix: 33 Number of BadApples: 4


**Annotated tests that didn't fail in the last 4 weeks.

  **Tests removed from the next two lists because they were specified in 
'doNotEnable' in the properties file
 MoveReplicaHDFSTest.testNormalFailedMove

  **Annotations can be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 0


Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0  had  82 failures
Week: 1  had  94 failures
Week: 2  had  502 failures
Week: 3  had  19 failures


Failures in Hoss' reports for the last 4 rollups.

There were 562 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   0.3 1271  8  RollingRestartTest.test
 0123  93.3   41 36  SharedFSAutoReplicaFailoverTest.test
 0123   3.5  627 16  
TestCircuitBreaker.testBuildingMemoryPressure
 0123   1.0  627  8  TestCircuitBreaker.testResponseWithCBTiming
 0123   5.8 1483 79  TestContainerPlugin.testApiFromPackage
 0123   2.3 1335 23  TestDistributedGrouping.test


Failures over the last 4 weeks, but not every week. Ordered most-recent first:



   Report   Pct runsfails   test
 0121.3 1174 19  BasicDistributedZkTest.test
 0126.0 1261 57  CloudExitableDirectoryReaderTest.test
 0124.2 6274189  
CloudExitableDirectoryReaderTest.testCreepThenBite
 0123.3 1246 27  
CloudExitableDirectoryReaderTest.testWhitebox
 0120.5 1189  9  

Re: Welcome Namgyu Kim to the PMC

[Jan Høydahl]

Welcome, Namgyu!

> 3. aug. 2020 kl. 01:18 skrev Ishan Chattopadhyaya :
> 
> I am pleased to announce that Namgyu Kim has accepted the PMC's invitation to 
> join.
> 
> Congratulations and welcome, Namgyu!


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

Re: Welcome Gus Heck to the PMC

[Jan Høydahl]

Welcome, Gus!

> 3. aug. 2020 kl. 01:20 skrev Ishan Chattopadhyaya :
> 
> I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
> join.
> 
> Congratulations and welcome, Gus!


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

Re: Welcome Munendra SN to the PMC

[Jan Høydahl]

Welcome Munendra!

> 3. aug. 2020 kl. 01:19 skrev Ishan Chattopadhyaya :
> 
> I am pleased to announce that Munendra SN has accepted the PMC's invitation 
> to join.
> 
> Congratulations and welcome, Munendra!


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

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Atri Sharma]

+1

SUCCESS! [1:27:33.14892]

On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan  wrote:
>
> Community,
>
> Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64: "Amazon 
> Corretto 8"):
>
> SUCCESS! [1:33:51.132902]
>
> I'm still going through and checking a few aforementioned issues, but 
> non-binding +1 from me. Wanted to share with the community because most 
> probably are not running Corretto.
>
> Hope this helps.
>
> marcus
>
>
>
> On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:
>>
>> Digging a little further, I notice that the deployment that had the error 
>> has this autoscaling (whereas the working deployment does not).
>>
>> "cluster-preferences":[{
>> "minimize":"cores",
>> "precision":1},
>> {"maximize":"freedisk"}],
>> "cluster-policy":[
>> {
>> "replica":"<2",
>> "shard":"#EACH",
>> "node":"#ANY",
>> "strict":"false"},
>> {
>> "replica":"#EQUAL",
>> "node":"#ANY",
>> "strict":"false"},
>> {
>> "cores":"#EQUAL",
>> "node":"#ANY",
>> "strict":"false"}],
>>
>> So this may raise the question of whether or not we have an issue upgrading 
>> an 8.6.0 version to 8.6.1... also, not very familiar with autoscaling's 
>> error messages, but it kinda looks dodgy too since "one extra tag in cores" 
>> appears to be referring to a cores attribute that has only one value, but no 
>> idea yet if I'm reading that error message right.  ... As to how I got that, 
>> I'm pretty sure it was one of the times when my edits to cloud.sh errored 
>> and  tried to deploy an existing branch_8x build. Zk probably was not clean, 
>> and retained the old config.
>>
>> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late here 
>> now) and see if I get a similar result.
>>
>>
>> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
>>>
>>> I Got:
>>>
>>> Ubuntu 18.04.4 LTS:
>>> SUCCESS! [0:53:02.203047]
>>> Mac OS 10.13:
>>>
>>> SUCCESS! [1:00:57.938586]
>>>
>>>
>>> BUT... when I deployed the tarball locally and tried to create a collection 
>>> (single shard, _default config, via the solr UI), I got:
>>>
>>>
>>> 2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ] 
>>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
>>>
>>> 2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ] 
>>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
>>>
>>> 2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ] 
>>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
>>>
>>> 2020-08-03 03:00:07.521 INFO  
>>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr) [  
>>>  ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
>>>
>>> 2020-08-03 03:00:07.672 ERROR 
>>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr) [  
>>>  ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test operation: 
>>> create failed:org.apache.solr.common.SolrException
>>>
>>> at 
>>> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
>>>
>>> at 
>>> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
>>>
>>> at 
>>> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
>>>
>>> at 
>>> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
>>>
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>> Caused by: java.lang.RuntimeException: Only one extra tag supported for the 
>>> tag cores in {
>>>
>>>   "cores":"#EQUAL",
>>>
>>>   "node":"#ANY",
>>>
>>>   "strict":"false"}
>>>
>>> at 
>>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
>>>
>>> at 
>>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
>>>
>>> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
>>>
>>> at 
>>> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
>>>
>>> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>>>
>>> at 
>>> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>>>
>>> at 
>>> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>>>
>>> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>>
>>> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>>>
>>> at 
>>> org.apache.solr.client.solrj.cloud.autoscaling.Policy.(Policy.java:144)
>>>
>>> at 
>>> org.apache.solr.client.solrj.cloud.autoscaling.AutoScalingConfig.getPolicy(AutoScalingConfig.java:372)
>>>
>>> at 
>>> org.apache.solr.cloud.api.collections.Assign.usePolicyFramework(Assign.java:300)
>>>
>>> at 
>>> 

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Marcus Eagan]

Community,

Results from my local smoke test (Mac OS 10.15.5 | 1.8.0_265, x86_64:
"Amazon Corretto 8"):

SUCCESS! [1:33:51.132902]

I'm still going through and checking a few aforementioned issues, but
non-binding +1 from me. Wanted to share with the community because most
probably are not running Corretto.

Hope this helps.

marcus



On Sun, Aug 2, 2020 at 9:36 PM Gus Heck  wrote:

> Digging a little further, I notice that the deployment that had the error
> has this autoscaling (whereas the working deployment does not).
>
> "cluster-preferences":[{
> "minimize":"cores",
> "precision":1},
> {"maximize":"freedisk"}],
> "cluster-policy":[
> {
> "replica":"<2",
> "shard":"#EACH",
> "node":"#ANY",
> "strict":"false"},
> {
> "replica":"#EQUAL",
> "node":"#ANY",
> "strict":"false"},
> {
> "cores":"#EQUAL",
> "node":"#ANY",
> "strict":"false"}],
>
> So this may raise the question of whether or not we have an issue
> upgrading an 8.6.0 version to 8.6.1... also, not very familiar with
> autoscaling's error messages, but it kinda looks dodgy too since "one extra
> tag in cores" appears to be referring to a cores attribute that has only
> one value, but no idea yet if I'm reading that error message right.  ... As
> to how I got that, I'm pretty sure it was one of the times when my edits to
> cloud.sh errored and  tried to deploy an existing branch_8x build. Zk
> probably was not clean, and retained the old config.
>
> Tomorrow I'll try to deploy 8_6_0 and then upgrade it to 8_6_1 (late here
> now) and see if I get a similar result.
>
>
> On Sun, Aug 2, 2020 at 11:59 PM Gus Heck  wrote:
>
>> I Got:
>>
>> Ubuntu 18.04.4 LTS:
>> SUCCESS! [0:53:02.203047]
>> Mac OS 10.13:
>>
>> SUCCESS! [1:00:57.938586]
>>
>>
>> BUT... when I deployed the tarball locally and tried to create a
>> collection (single shard, _default config, via the solr UI), I got:
>>
>>
>> 2020-08-03 02:55:15.585 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (2)
>>
>> 2020-08-03 02:55:21.288 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
>>
>> 2020-08-03 02:55:26.705 INFO  (zkCallback-14-thread-1) [   ]
>> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (3) -> (4)
>>
>> 2020-08-03 03:00:07.521 INFO
>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>> [   ] o.a.s.c.a.c.CreateCollectionCmd Create collection test
>>
>> 2020-08-03 03:00:07.672 ERROR
>> (OverseerThreadFactory-22-thread-1-processing-n:192.168.2.106:8981_solr)
>> [   ] o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: test
>> operation: create failed:org.apache.solr.common.SolrException
>>
>> at
>> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:347)
>>
>> at
>> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:264)
>>
>> at
>> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:517)
>>
>> at
>> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:212)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>
>> at java.lang.Thread.run(Thread.java:745)
>>
>> Caused by: java.lang.RuntimeException: Only one extra tag supported for
>> the tag cores in {
>>
>>   "cores":"#EQUAL",
>>
>>   "node":"#ANY",
>>
>>   "strict":"false"}
>>
>> at
>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.(Clause.java:122)
>>
>> at
>> org.apache.solr.client.solrj.cloud.autoscaling.Clause.create(Clause.java:235)
>>
>> at
>> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
>>
>> at
>> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
>>
>> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>>
>> at
>> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>>
>> at
>> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>>
>> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>
>> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>>
>> at
>> org.apache.solr.client.solrj.cloud.autoscaling.Policy.(Policy.java:144)
>>
>> at
>> org.apache.solr.client.solrj.cloud.autoscaling.AutoScalingConfig.getPolicy(AutoScalingConfig.java:372)
>>
>> at
>> org.apache.solr.cloud.api.collections.Assign.usePolicyFramework(Assign.java:300)
>>
>> at
>> org.apache.solr.cloud.api.collections.Assign.usePolicyFramework(Assign.java:277)
>>
>> at
>> org.apache.solr.cloud.api.collections.Assign$AssignStrategyFactory.create(Assign.java:661)
>>
>> at
>> org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:415)
>>
>> at
>> 

Re: Welcome Gus Heck to the PMC

[Noble Paul]

Welcome Gus!

On Mon, Aug 3, 2020 at 1:10 PM Koji Sekiguchi
 wrote:
>
> Welcome, Gus!
>
> Koji
>
> On 2020/08/03 8:20, Ishan Chattopadhyaya wrote:
> > I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
> > join.
> >
> > Congratulations and welcome, Gus!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Welcome Namgyu Kim to the PMC

[Noble Paul]

Welcome Namgyu!

On Mon, Aug 3, 2020 at 5:16 PM Adrien Grand  wrote:
>
> Welcome!
>
> On Mon, Aug 3, 2020 at 5:12 AM Koji Sekiguchi  
> wrote:
>>
>> Welcome, Namgyu!
>>
>> Koji
>>
>> On 2020/08/03 8:18, Ishan Chattopadhyaya wrote:
>> > I am pleased to announce that Namgyu Kim has accepted the PMC's invitation 
>> > to join.
>> >
>> > Congratulations and welcome, Namgyu!
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Adrien



-- 
-
Noble Paul

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

Re: Welcome Munendra SN to the PMC

[Noble Paul]

Welcome Munendra!

On Mon, Aug 3, 2020 at 1:11 PM Koji Sekiguchi
 wrote:
>
> Welcome, Munendra!
>
> Koji
>
> On 2020/08/03 8:19, Ishan Chattopadhyaya wrote:
> > I am pleased to announce that Munendra SN has accepted the PMC's invitation 
> > to join.
> >
> > Congratulations and welcome, Munendra!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Welcome Namgyu Kim to the PMC

[Adrien Grand]

Welcome!

On Mon, Aug 3, 2020 at 5:12 AM Koji Sekiguchi 
wrote:

> Welcome, Namgyu!
>
> Koji
>
> On 2020/08/03 8:18, Ishan Chattopadhyaya wrote:
> > I am pleased to announce that Namgyu Kim has accepted the PMC's
> invitation to join.
> >
> > Congratulations and welcome, Namgyu!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Adrien