Re: [DISCUSS] Community Virtual Meetup, January 2024

[raghavan m]

Thanks, Eric. I updated the page with the two topics

Everyone,
The meetup will be on 01/18 9 am pacific time, 10:30pm IST.
Please submit topics that you would like to discuss here.
https://cwiki.apache.org/confluence/display/SOLR/2024-01-18+Meeting+notes

https://meet.google.com/wek-upvd-pff

thanks,
*Raghavan*


On Fri, Jan 12, 2024 at 10:19 AM Eric Pugh 
wrote:

> I’d be interested in a discussion around:
>
> Standardizing System Property Names and Ramifications:
> https://lists.apache.org/thread/ckb3tqnjf0h66rd0mlpfblpvkrvp3wq6
>
> Migration from JIRA to Github for issues:
> https://lists.apache.org/thread/7kg0m7528h4xox1hzf5wb26fzcl9758g
>
> I’d love to also share some early plans for a 1 day Hackathon for various
> Search related projects at C / C North America coming up this year.
>
>
>
> > On Jan 11, 2024, at 6:46 PM, raghavan m  wrote:
> >
> > Hello everyone
> > So far, 1/18 is the most voted date. I’ll announce in meetup and slack
> > channels, also create a meeting notes page.
> > Please reply to this thread with any agenda/ presentation that you want
> to
> > discuss.
> >
> > Thanks
> > Raghavan
> >
> > Sent from iPhone
> >
> >
> > On Wed, Jan 10, 2024 at 10:42 PM Marcus Eagan 
> wrote:
> >
> >> On the 18th, I'll be available to join.
> >>
> >> On Wed, Jan 10, 2024 at 7:06 PM David Smiley 
> wrote:
> >>
> >>> 18th
> >>> or probably any
> >>>
> >>> On Wed, Jan 10, 2024 at 12:15 AM raghavan m 
> >>> wrote:
> >>>
>  Hey everyone,
>  Please vote for one of the following days
> 
>    - 1/15
>    - 1/16
>    - 1/17
>    - 1/18
>    - 1/19
>    - 1/22
> 
>  Time: 9 am pacific time.
>  Thanks
>  Raghavan
> 
>  Sent from iPhone
> 
> 
>  On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski  >
>  wrote:
> 
> > Awesome, thanks for volunteering Raghavan!
> >
> > Anyone have thoughts on scheduling?  Absent other strong opinions,
> >>> maybe
>  we
> > could aim for the week of Monday the 15th through Friday the 19th and
>  pick
> > a day/time in that range?
> >
> > Best,
> >
> > Jason
> >
> > On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
>  wrote:
> >
> >> Happy New Year everyone. I can volunteer for January.
> >>
> >> Sent from iPhone
> >>
> >>
> >> On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski <
> >>> gerlowsk...@gmail.com>
> >> wrote:
> >>
> >>> Hey all,
> >>>
> >>> After missing December, It's time once again to start thinking
> >>> ahead
>  to
> >> our
> >>> first Virtual Meetup in the New Year!  As always, there's two
> >> main
> >>> questions to answer in terms of planning:
> >>>
> >>> 1. Any volunteers to organize?  Organizer duties are pretty light
> >>> and
> > are
> >>> summarized here:
> >>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> >>> Volunteers
> >>> get some discretion in terms of picking a meeting time/day that
> >>> works
> > for
> >>> them.  If there are no volunteers by the end of the week, I'm
> >> more
>  than
> >>> happy to set things up for this month.
> >>>
> >>> 2. When should we meet?  I've started the discussion early this
>  month,
> > so
> >>> we've got plenty of days to choose from.  If you have any
> >> opinions,
> >> please
> >>> discuss.
> >>>
> >>> Best,
> >>>
> >>> Jason
> >>>
> >>
> >
> 
> >>>
> >>
> >>
> >> --
> >> Marcus Eagan
> >>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com <
> http://www.opensourceconnections.com/> | My Free/Busy <
> http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
>
>

Re: [DISCUSS] Community Virtual Meetup, January 2024

[Eric Pugh]

One more topic would be a discussion about a hackathon that is being proposed 
for C/C 2024 NA.

> On Jan 15, 2024, at 4:04 AM, raghavan m  wrote:
> 
> Thanks, Eric. I updated the page with the two topics
> 
> Everyone,
> The meetup will be on 01/18 9 am pacific time, 10:30pm IST.
> Please submit topics that you would like to discuss here.
> https://cwiki.apache.org/confluence/display/SOLR/2024-01-18+Meeting+notes
> 
> https://meet.google.com/wek-upvd-pff
> 
> thanks,
> *Raghavan*
> 
> 
> On Fri, Jan 12, 2024 at 10:19 AM Eric Pugh  >
> wrote:
> 
>> I’d be interested in a discussion around:
>> 
>> Standardizing System Property Names and Ramifications:
>> https://lists.apache.org/thread/ckb3tqnjf0h66rd0mlpfblpvkrvp3wq6
>> 
>> Migration from JIRA to Github for issues:
>> https://lists.apache.org/thread/7kg0m7528h4xox1hzf5wb26fzcl9758g
>> 
>> I’d love to also share some early plans for a 1 day Hackathon for various
>> Search related projects at C / C North America coming up this year.
>> 
>> 
>> 
>>> On Jan 11, 2024, at 6:46 PM, raghavan m  wrote:
>>> 
>>> Hello everyone
>>> So far, 1/18 is the most voted date. I’ll announce in meetup and slack
>>> channels, also create a meeting notes page.
>>> Please reply to this thread with any agenda/ presentation that you want
>> to
>>> discuss.
>>> 
>>> Thanks
>>> Raghavan
>>> 
>>> Sent from iPhone
>>> 
>>> 
>>> On Wed, Jan 10, 2024 at 10:42 PM Marcus Eagan 
>> wrote:
>>> 
 On the 18th, I'll be available to join.
 
 On Wed, Jan 10, 2024 at 7:06 PM David Smiley 
>> wrote:
 
> 18th
> or probably any
> 
> On Wed, Jan 10, 2024 at 12:15 AM raghavan m 
> wrote:
> 
>> Hey everyone,
>> Please vote for one of the following days
>> 
>>  - 1/15
>>  - 1/16
>>  - 1/17
>>  - 1/18
>>  - 1/19
>>  - 1/22
>> 
>> Time: 9 am pacific time.
>> Thanks
>> Raghavan
>> 
>> Sent from iPhone
>> 
>> 
>> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski >> 
>> wrote:
>> 
>>> Awesome, thanks for volunteering Raghavan!
>>> 
>>> Anyone have thoughts on scheduling?  Absent other strong opinions,
> maybe
>> we
>>> could aim for the week of Monday the 15th through Friday the 19th and
>> pick
>>> a day/time in that range?
>>> 
>>> Best,
>>> 
>>> Jason
>>> 
>>> On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
>> wrote:
>>> 
 Happy New Year everyone. I can volunteer for January.
 
 Sent from iPhone
 
 
 On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski <
> gerlowsk...@gmail.com>
 wrote:
 
> Hey all,
> 
> After missing December, It's time once again to start thinking
> ahead
>> to
 our
> first Virtual Meetup in the New Year!  As always, there's two
 main
> questions to answer in terms of planning:
> 
> 1. Any volunteers to organize?  Organizer duties are pretty light
> and
>>> are
> summarized here:
> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> Volunteers
> get some discretion in terms of picking a meeting time/day that
> works
>>> for
> them.  If there are no volunteers by the end of the week, I'm
 more
>> than
> happy to set things up for this month.
> 
> 2. When should we meet?  I've started the discussion early this
>> month,
>>> so
> we've got plenty of days to choose from.  If you have any
 opinions,
 please
> discuss.
> 
> Best,
> 
> Jason
> 
 
>>> 
>> 
> 
 
 
 --
 Marcus Eagan
 
>> 
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com <
>> http://www.opensourceconnections.com/> | My Free/Busy <
>> http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> 
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 

Re: [DISCUSS] Standardizing sysprop naming

[David Smiley]

The categories and your comments make sense to me.

I looked across some of the individual proposals:

> collection.configName
Where is this used as a system property override?  I looked and don't see
it.

"enabled" vs "disabled": can we standardize on "enabled"?

> managed.schema.mutable

In this case (and likely others if I found one), there is no production
code containing this string.  It is only a test config file containing
${managed.schema.mutable} and probably test code that sets it.  I don't
think we should put these in the list; the list is long enough as it is.

> disable.configEdit. => solr.configset.edit.disabled
We should then broaden its use to cover the configset broadly, thus block
the schema edit API and maybe more.  Right now it only covers mutability of
solrconfig.xml (via a JSON overlay).  I'm good with that, but it increases
the scope.

On Fri, Jan 12, 2024 at 6:39 AM Jan Høydahl  wrote:

> I like the simplicity of lowercasing and changing underscore for dot, so
> if we can avoid camelCase that would be best.
>
>
> I started a WIKI page for easier collaboration on this topic:
> https://cwiki.apache.org/confluence/display/SOLR/System+property+naming+structure
>
> There I enumerated each source folder and tried to deduce some commonality
> and structure.
>
> I also enumerated all current sysProps used in the codebase (by scanning
> src for various System.getProperty, Boolean.getBoolean, EnvUtils.getProp
> variations). That is the second table on the page. Looking at all those
> system property names we have today is depressing, they are all over the
> place and 157 in number (although some are zk, hadoop or java owned and
> some relate to tests).
>
> I did a small stab on mapping those old props to a new proposed name, but
> the list is looong, so good with some collaboration on this. I experience
> that the shape of the hiearchy molds as I encounter more real-life
> examples. And there are tons of decisions, e.g. wether we should force
> solr.security as a prefix for all things security or to keep the shorter
> solr.auth.*. Same with solr.search.*
>
> It is also encouraging to see the list of existing solr.xxx keys in use
> that are already well structured (solr.jetty.keystore.password,
> solr.kerberos.keystore.password, solr.log.level etc).
>
> Jan
>
>
> > 11. jan. 2024 kl. 03:36 skrev David Smiley :
> >
> > On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl  > wrote:
> >
> >> Hi,
> >>
> >>> Using this one as an example; what would you propose?:
> >>> * solr.shardSplit.checkDiskSpace.enabled
> >>
> >> The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better.
> >> But say we standardized the first component layer to be one of "query",
> >> "index", "collection", "schema", "cluster", "node" or whatever set of
> >> top-level components make sense. Then I guess shard split would be
> >> "solr.collection.shard.split.checkDiskSpace.enabled" or similar.
> However, I
> >> find it hard to find good generic top-level categories for Solr that are
> >> consise and no overlapping.
> >>
> >
> > So the module can't be camel-case but checkDiskSpace can?  What about
> > hyphens in a sys prop, mapped to an underscore in an env var?
> >
> >> "solr.collection.shard.split.checkDiskSpace.enabled"
> >
> > Not bad.
> > I bet it's hard to find good generic top-level categories.Feel free
> to
> > take a stab at this and share for review.  It doesn't need to be perfect,
> > just not nausea inducing :-)
> >
> >
> >>> Are you saying the camel case is a problem?
> >>
> >> No necessarily. The concern was that there should be a well-defined way
> to
> >> translate an SOLR_ENV_VAR into system property, so we don't need to
> touch
> >> bin/solr[.cmd] every single time. And it would be hard for an algorithm
> to
> >> know that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED
> >> env.var into the exact combination of dot separation and camelCase used
> >> above. An alternative could be using a combination of underscore and
> dash,
> >> such as "SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate
> >> underscore with dot and dash with Camelcase. We'd need to disallow dash
> in
> >> property names then...
> >>
> >
> > Alternatively simply normalize both sys props and env vars using the same
> > scheme.  In theory it would allow crazy variation but if we only document
> > each named toggle a certain way then it doesn't matter.
>
>