Re: [Operator] [VOTE] Release the Solr Operator v0.8.0 RC1

2023-10-19 Thread Arrieta, Alejandro 
Hello Team,

+1 non-binding

...
Local end-to-end cluster test successfully run!




Successfully smoke tested the Solr Operator v0.8.0!

Kind Regards,
Alejandro Arrieta

On Thu, Oct 19, 2023 at 11:53 PM Mark Miller  wrote:

> +1
>
> Successfully smoke tested the Solr Operator v0.8.0!
>
> On Mon, Oct 16, 2023 at 2:37 PM Jason Gerlowski 
> wrote:
>
> > Please vote for release candidate 1 for the Solr Operator v0.8.0
> >
> > The artifacts can be downloaded from:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0
> >
> > You can run the full smoke tester, with instructions below.
> > However, it is also encouraged to go and use the artifacts yourself in
> > a test Kubernetes cluster.
> > The smoke tester does not require you to download or install the RC
> > artifacts before running.
> > If you plan on just running the smoke tests, then ignore all other
> > instructions.
> >
> > The artifacts are laid out in the following way:
> >   * solr-operator-v0.8.0.tgz - Contains the source release
> >   * crds/ - Contains the CRD files
> >   * helm-charts/ - Contains the Helm release packages
> >
> > The RC Docker image can be found at:
> >   apache/solr-operator:v0.8.0-rc1
> >
> > The RC Helm repo can be added with:
> >   helm repo add apache-solr-rc
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/helm-charts
> >
> > You can install the RC Solr Operator and Solr CRDs and an example Solr
> > Cloud with:
> >   curl -sL0 "https://dist.apache.org/repos/dist/release/solr/KEYS"; |
> > gpg --import --quiet
> >   # This will export your public keys into a format that helm can
> > understand.
> >   # Skip verification by removing "--verify" in the helm command below.
> >   if ! (gpg --no-default-keyring --keyring=~/.gnupg/pubring.gpg
> > --list-keys "60392455"); then gpg --export >~/.gnupg/pubring.gpg; fi
> >   kubectl create -f
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/crds/all-with-dependencies.yaml
> > || \
> > kubectl replace -f
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/crds/all-with-dependencies.yaml
> >   helm install --verify solr-operator apache-solr-rc/solr-operator
> > --set image.tag=v0.8.0-rc1
> >   helm install --verify example apache-solr-rc/solr
> >
> > You can run the full smoke tester directly with this command: (First
> > checkout the release-0.8 branch of the solr-operator)
> >
> > # First clear your go-mod cache to make sure old cache entries don't
> > cause smoke test failures
> > make mod-clean
> > ./hack/release/smoke_test/smoke_test.sh -v "v0.8.0" -s "f2c2710" -i
> > "apache/solr-operator:v0.8.0-rc1" -g "60392455" \
> > -l '
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0
> > '
> >
> > If you want to run the smoke test with a specific version of
> > kubernetes, use the -k option with a full version tag. (e.g. -k
> > v1.19.3)
> > If you want to run the smoke test with a custom version of solr, use
> > the -t option with an official Solr image version. (e.g. -t 8.10.0)
> >   However, for this smoke test, you must use a solr version that
> > supports incremental backups. (i.e. 8.9+)
> >
> > Make sure you have the following installed before running the smoke test:
> >   - Docker (Give it enough memory and CPU to run ~12 containers, 3 of
> > which are Solr nodes)
> > More information on required resources can be found here:
> >
> https://kind.sigs.k8s.io/docs/user/quick-start/#settings-for-docker-desktop
> >   - Go 1.20
> >   - Kubectl
> >   - GnuPG
> >   - Helm v3.4.0+
> >   - Kustomize (v4.0.0+) This will be installed for you, but NOT
> > upgraded if a lower version is already installed.
> >   - yq
> >   - jq
> >   - coreutils (if using Mac OS)
> >
> > The vote will be open for at least 72 hours i.e. until 2023-10-19 20:00
> > UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >
>
> --
> - MRM
>

Re: [Operator] [VOTE] Release the Solr Operator v0.8.0 RC1

2023-10-19 Thread Mark Miller 
+1

Successfully smoke tested the Solr Operator v0.8.0!

On Mon, Oct 16, 2023 at 2:37 PM Jason Gerlowski 
wrote:

> Please vote for release candidate 1 for the Solr Operator v0.8.0
>
> The artifacts can be downloaded from:
>
>
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0
>
> You can run the full smoke tester, with instructions below.
> However, it is also encouraged to go and use the artifacts yourself in
> a test Kubernetes cluster.
> The smoke tester does not require you to download or install the RC
> artifacts before running.
> If you plan on just running the smoke tests, then ignore all other
> instructions.
>
> The artifacts are laid out in the following way:
>   * solr-operator-v0.8.0.tgz - Contains the source release
>   * crds/ - Contains the CRD files
>   * helm-charts/ - Contains the Helm release packages
>
> The RC Docker image can be found at:
>   apache/solr-operator:v0.8.0-rc1
>
> The RC Helm repo can be added with:
>   helm repo add apache-solr-rc
>
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/helm-charts
>
> You can install the RC Solr Operator and Solr CRDs and an example Solr
> Cloud with:
>   curl -sL0 "https://dist.apache.org/repos/dist/release/solr/KEYS"; |
> gpg --import --quiet
>   # This will export your public keys into a format that helm can
> understand.
>   # Skip verification by removing "--verify" in the helm command below.
>   if ! (gpg --no-default-keyring --keyring=~/.gnupg/pubring.gpg
> --list-keys "60392455"); then gpg --export >~/.gnupg/pubring.gpg; fi
>   kubectl create -f
>
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/crds/all-with-dependencies.yaml
> || \
> kubectl replace -f
>
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/crds/all-with-dependencies.yaml
>   helm install --verify solr-operator apache-solr-rc/solr-operator
> --set image.tag=v0.8.0-rc1
>   helm install --verify example apache-solr-rc/solr
>
> You can run the full smoke tester directly with this command: (First
> checkout the release-0.8 branch of the solr-operator)
>
> # First clear your go-mod cache to make sure old cache entries don't
> cause smoke test failures
> make mod-clean
> ./hack/release/smoke_test/smoke_test.sh -v "v0.8.0" -s "f2c2710" -i
> "apache/solr-operator:v0.8.0-rc1" -g "60392455" \
> -l '
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0
> '
>
> If you want to run the smoke test with a specific version of
> kubernetes, use the -k option with a full version tag. (e.g. -k
> v1.19.3)
> If you want to run the smoke test with a custom version of solr, use
> the -t option with an official Solr image version. (e.g. -t 8.10.0)
>   However, for this smoke test, you must use a solr version that
> supports incremental backups. (i.e. 8.9+)
>
> Make sure you have the following installed before running the smoke test:
>   - Docker (Give it enough memory and CPU to run ~12 containers, 3 of
> which are Solr nodes)
> More information on required resources can be found here:
> https://kind.sigs.k8s.io/docs/user/quick-start/#settings-for-docker-desktop
>   - Go 1.20
>   - Kubectl
>   - GnuPG
>   - Helm v3.4.0+
>   - Kustomize (v4.0.0+) This will be installed for you, but NOT
> upgraded if a lower version is already installed.
>   - yq
>   - jq
>   - coreutils (if using Mac OS)
>
> The vote will be open for at least 72 hours i.e. until 2023-10-19 20:00
> UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

-- 
- MRM

Re: [Operator] [VOTE] Release the Solr Operator v0.8.0 RC1

2023-10-19 Thread Radu Gheorghe 
+1

Ran the smoke test
[...]



Local end-to-end cluster test successfully run!






Successfully smoke tested the Solr Operator v0.8.0!

Best regards,
Radu
--
Elasticsearch/OpenSearch & Solr Consulting, Production Support & Training
Sematext Cloud - Full Stack Observability
https://sematext.com/ 


On Tue, Oct 17, 2023 at 5:45 PM Houston Putman  wrote:

> +1 (binding)
>
> I ran the smoke tests:
>
> 
> > Successfully smoke tested the Solr Operator v0.8.0!
>
>
> I also ran the end-to-end integration tests with the RC docker image and
> Solr 9.4 and 8.11
>
> $ make e2e-tests OPERATOR_IMAGE=apache/solr-operator:v0.8.0-rc1
> > SOLR_IMAGE=solr:9.4
>
> ...
>
> Will run 23 of 23 specs
> > Running in parallel across 3 processes
> > •••
> >
> > Ran 23 of 23 Specs in 481.983 seconds
> > SUCCESS! -- 23 Passed | 0 Failed | 0 Pending | 0 Skipped
>
>
> $ make e2e-tests OPERATOR_IMAGE=apache/solr-operator:v0.8.0-rc1
> > SOLR_IMAGE=solr:8.11
>
> ...
>
> Will run 23 of 23 specs
>
> Running in parallel across 3 processes
>
>
>
> S••
> >
> Ran 22 of 23 Specs in 442.690 seconds
> > SUCCESS! -- 22 Passed | 0 Failed | 0 Pending | 1 Skipped
>
>
> - Houston
>
> On Mon, Oct 16, 2023 at 3:37 PM Jason Gerlowski 
> wrote:
>
> > Please vote for release candidate 1 for the Solr Operator v0.8.0
> >
> > The artifacts can be downloaded from:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0
> >
> > You can run the full smoke tester, with instructions below.
> > However, it is also encouraged to go and use the artifacts yourself in
> > a test Kubernetes cluster.
> > The smoke tester does not require you to download or install the RC
> > artifacts before running.
> > If you plan on just running the smoke tests, then ignore all other
> > instructions.
> >
> > The artifacts are laid out in the following way:
> >   * solr-operator-v0.8.0.tgz - Contains the source release
> >   * crds/ - Contains the CRD files
> >   * helm-charts/ - Contains the Helm release packages
> >
> > The RC Docker image can be found at:
> >   apache/solr-operator:v0.8.0-rc1
> >
> > The RC Helm repo can be added with:
> >   helm repo add apache-solr-rc
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/helm-charts
> >
> > You can install the RC Solr Operator and Solr CRDs and an example Solr
> > Cloud with:
> >   curl -sL0 "https://dist.apache.org/repos/dist/release/solr/KEYS"; |
> > gpg --import --quiet
> >   # This will export your public keys into a format that helm can
> > understand.
> >   # Skip verification by removing "--verify" in the helm command below.
> >   if ! (gpg --no-default-keyring --keyring=~/.gnupg/pubring.gpg
> > --list-keys "60392455"); then gpg --export >~/.gnupg/pubring.gpg; fi
> >   kubectl create -f
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/crds/all-with-dependencies.yaml
> > || \
> > kubectl replace -f
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0/crds/all-with-dependencies.yaml
> >   helm install --verify solr-operator apache-solr-rc/solr-operator
> > --set image.tag=v0.8.0-rc1
> >   helm install --verify example apache-solr-rc/solr
> >
> > You can run the full smoke tester directly with this command: (First
> > checkout the release-0.8 branch of the solr-operator)
> >
> > # First clear your go-mod cache to make sure old cache entries don't
> > cause smoke test failures
> > make mod-clean
> > ./hack/release/smoke_test/smoke_test.sh -v "v0.8.0" -s "f2c2710" -i
> > "apache/solr-operator:v0.8.0-rc1" -g "60392455" \
> > -l '
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.8.0-RC1-revf2c27102a7e9056c6fe7d8cea6c97bac5a47fcc0
> > '
> >
> > If you want to run the smoke test with a specific version of
> > kubernetes, use the -k option with a full version tag. (e.g. -k
> > v1.19.3)
> > If you want to run the smoke test with a custom version of solr, use
> > the -t option with an official Solr image version. (e.g. -t 8.10.0)
> >   However, for this smoke test, you must use a solr version that
> > supports incremental backups. (i.e. 8.9+)
> >
> > Make sure you have the following installed before running the smoke test:
> >   - Docker (Give it enough memory and CPU to run ~12 containers, 3 of
> > which are Solr nodes)
> > More information on required resources can be found here:
> >
> https://kind.sigs.k8s.io/docs/user/quick-start/#settings-for-docker-desktop
> >   - Go 1.20
> >   - Kubectl
> >   - GnuPG
> >   - Helm v3.4.0+
> >   - Kustomize (v4.0.0+) This will be installed for you, but NOT
> > upgraded if a lower version is already i

Re: The _version_ field; why is it necessary?

2023-10-19 Thread Ishan Chattopadhyaya 
The VersionInfo bucket lazy creation thing feels like an unnecessary
optimization to me. I think 65k version buckets as a default doesn't make
sense. Reducing that default to 1k or so should suffice. Historic reasons
to have it at 65k is documented somewhere in jira, more to do with
improving leader to follower throughput. But, those who are concerned about
that can switch to TLOG replicas and I guess then they won't be affected
adversely? Maybe Tim Potter (who increased the defaults to 65k) might
remember more info/context. Having said that, I don't oppose that change
per se.

On Thu, 19 Oct, 2023, 7:28 pm David Smiley, 
wrote:

> While we touch VersionInfo in https://github.com/apache/solr/pull/2021 I
> see no class javadocs on it.  It's really frustrating; we're left to
> wonder/guess the sorts of things I ask in this email.  Could  someone
> knowledgeable (like Mark) care to suggest javadocs for this class?  A
> couple sentences is better than nothing.
>
> Houston: Can you (or anyone) please elaborate on an example where the
> _version_ field is needed for TLOG non-leader to gain leadership and retain
> data integrity?  I naively think the leader shares its updates with a
> follower sequentially as it happens.
>
> ~ David
>
>
> On Wed, Oct 18, 2023 at 9:45 AM Houston Putman 
> wrote:
>
> > I believe its still useful for TLOG replicas as well. When they gain
> > leadership, and they replay the TLOG which could have the same issues
> that
> > non leader NRT replicas have.
> >
> > - Houston
> >
> > On Wed, Oct 18, 2023 at 8:26 AM David Smiley 
> > wrote:
> >
> > > Thank you both.  It helps to know that "_version"_ is for, I would say
> > > succinctly, "NRT replication".  I mean; that deserves to be said
> > internally
> > > in some places!
> > > Might it be advantageous to imagine it being optional for non-NRT
> > > replicas?  I'm not sure if it saves anything or reduces complexity
> > > anywhere.
> > > Related question:  Is the VersionInfo (with its striped VersionBucket
> > > locks) related to this -- is it a vestige of "_version_" or is it for
> > > something else?  If it isn't for something else, then I could imagine
> it
> > > being omitted for non-NRT; maybe a dummy implementation.  BTW Bruno
> > opened
> > > an issue/PR on it yesterday --
> > > https://issues.apache.org/jira/browse/SOLR-17036
> > >
> > > ~ David
> > >
> > >
> > > On Wed, Oct 18, 2023 at 1:41 AM Ishan Chattopadhyaya <
> > > ichattopadhy...@gmail.com> wrote:
> > >
> > > > Fyi, SOLR-5944, is unreadable, but introduced the concept of previous
> > > > version or something like that.
> > > >
> > > > On Wed, 18 Oct, 2023, 10:35 am Mark Miller, 
> > > wrote:
> > > >
> > > > > The primary reason is as Ishan says - so that update reorders from
> > > leader
> > > > > to replica can be handled in both normal and failure cases.
> > > > >
> > > > > It’s also true that a part of the reason that the per document, NRT
> > > > design,
> > > > > with versions, was chosen was a desire to support per document
> > > optimistic
> > > > > concurrency.
> > > > >
> > > > > On Tue, Oct 17, 2023 at 11:37 PM Ishan Chattopadhyaya <
> > > > > ichattopadhy...@gmail.com> wrote:
> > > > >
> > > > > > Also DBQs use the version field to ensure they are applied
> > correctly,
> > > > > even
> > > > > > if a DBQ is reordered
> > > > > >
> > > > > > On Wed, 18 Oct, 2023, 10:05 am Ishan Chattopadhyaya, <
> > > > > > ichattopadhy...@gmail.com> wrote:
> > > > > >
> > > > > > > To ensure reordered updates are processed properly from leader
> to
> > > > other
> > > > > > > replicas in NRT replication mode.
> > > > > > >
> > > > > > > On Wed, 18 Oct, 2023, 9:55 am David Smiley, <
> dsmi...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > >> Question: Does the _version_ field have a purpose other than
> for
> > > > > "atomic
> > > > > > >> updates"?
> > > > > > >> I know SolrCloud and/or having an UpdateLog insists on it.
> But
> > I
> > > > > don't
> > > > > > >> know if it's for that feature alone, or for additional
> > non-obvious
> > > > > > >> internal
> > > > > > >> workings of SolrCloud.  Mostly I'm just asking to have a
> deeper
> > > > > > >> understanding; the field doesn't bother me.  If someone knows
> of
> > > any
> > > > > > docs
> > > > > > >> on it or old interesting JIRAs to read, I'd appreciate it.
> > > > > > >>
> > > > > > >> ~ David Smiley
> > > > > > >> Apache Lucene/Solr Search Developer
> > > > > > >> http://www.linkedin.com/in/davidwsmiley
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: The _version_ field; why is it necessary?

2023-10-19 Thread Ishan Chattopadhyaya 
On Thu, 19 Oct, 2023, 7:28 pm David Smiley, 
wrote:

> While we touch VersionInfo in https://github.com/apache/solr/pull/2021 I
> see no class javadocs on it.  It's really frustrating; we're left to
> wonder/guess the sorts of things I ask in this email.  Could  someone
> knowledgeable (like Mark) care to suggest javadocs for this class?  A
> couple sentences is better than nothing.
>
> Houston: Can you (or anyone) please elaborate on an example where the
> _version_ field is needed for TLOG non-leader to gain leadership and retain
> data integrity?  I naively think the leader shares its updates with a
> follower sequentially as it happens.
>

Updates can be reordered from leader to non leader replicas (TLOG, NRT),
esp during multithreaded indexing.


> ~ David
>
>
> On Wed, Oct 18, 2023 at 9:45 AM Houston Putman 
> wrote:
>
> > I believe its still useful for TLOG replicas as well. When they gain
> > leadership, and they replay the TLOG which could have the same issues
> that
> > non leader NRT replicas have.
> >
> > - Houston
> >
> > On Wed, Oct 18, 2023 at 8:26 AM David Smiley 
> > wrote:
> >
> > > Thank you both.  It helps to know that "_version"_ is for, I would say
> > > succinctly, "NRT replication".  I mean; that deserves to be said
> > internally
> > > in some places!
> > > Might it be advantageous to imagine it being optional for non-NRT
> > > replicas?  I'm not sure if it saves anything or reduces complexity
> > > anywhere.
> > > Related question:  Is the VersionInfo (with its striped VersionBucket
> > > locks) related to this -- is it a vestige of "_version_" or is it for
> > > something else?  If it isn't for something else, then I could imagine
> it
> > > being omitted for non-NRT; maybe a dummy implementation.  BTW Bruno
> > opened
> > > an issue/PR on it yesterday --
> > > https://issues.apache.org/jira/browse/SOLR-17036
> > >
> > > ~ David
> > >
> > >
> > > On Wed, Oct 18, 2023 at 1:41 AM Ishan Chattopadhyaya <
> > > ichattopadhy...@gmail.com> wrote:
> > >
> > > > Fyi, SOLR-5944, is unreadable, but introduced the concept of previous
> > > > version or something like that.
> > > >
> > > > On Wed, 18 Oct, 2023, 10:35 am Mark Miller, 
> > > wrote:
> > > >
> > > > > The primary reason is as Ishan says - so that update reorders from
> > > leader
> > > > > to replica can be handled in both normal and failure cases.
> > > > >
> > > > > It’s also true that a part of the reason that the per document, NRT
> > > > design,
> > > > > with versions, was chosen was a desire to support per document
> > > optimistic
> > > > > concurrency.
> > > > >
> > > > > On Tue, Oct 17, 2023 at 11:37 PM Ishan Chattopadhyaya <
> > > > > ichattopadhy...@gmail.com> wrote:
> > > > >
> > > > > > Also DBQs use the version field to ensure they are applied
> > correctly,
> > > > > even
> > > > > > if a DBQ is reordered
> > > > > >
> > > > > > On Wed, 18 Oct, 2023, 10:05 am Ishan Chattopadhyaya, <
> > > > > > ichattopadhy...@gmail.com> wrote:
> > > > > >
> > > > > > > To ensure reordered updates are processed properly from leader
> to
> > > > other
> > > > > > > replicas in NRT replication mode.
> > > > > > >
> > > > > > > On Wed, 18 Oct, 2023, 9:55 am David Smiley, <
> dsmi...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > >> Question: Does the _version_ field have a purpose other than
> for
> > > > > "atomic
> > > > > > >> updates"?
> > > > > > >> I know SolrCloud and/or having an UpdateLog insists on it.
> But
> > I
> > > > > don't
> > > > > > >> know if it's for that feature alone, or for additional
> > non-obvious
> > > > > > >> internal
> > > > > > >> workings of SolrCloud.  Mostly I'm just asking to have a
> deeper
> > > > > > >> understanding; the field doesn't bother me.  If someone knows
> of
> > > any
> > > > > > docs
> > > > > > >> on it or old interesting JIRAs to read, I'd appreciate it.
> > > > > > >>
> > > > > > >> ~ David Smiley
> > > > > > >> Apache Lucene/Solr Search Developer
> > > > > > >> http://www.linkedin.com/in/davidwsmiley
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: The _version_ field; why is it necessary?

2023-10-19 Thread David Smiley 
While we touch VersionInfo in https://github.com/apache/solr/pull/2021 I
see no class javadocs on it.  It's really frustrating; we're left to
wonder/guess the sorts of things I ask in this email.  Could  someone
knowledgeable (like Mark) care to suggest javadocs for this class?  A
couple sentences is better than nothing.

Houston: Can you (or anyone) please elaborate on an example where the
_version_ field is needed for TLOG non-leader to gain leadership and retain
data integrity?  I naively think the leader shares its updates with a
follower sequentially as it happens.

~ David


On Wed, Oct 18, 2023 at 9:45 AM Houston Putman 
wrote:

> I believe its still useful for TLOG replicas as well. When they gain
> leadership, and they replay the TLOG which could have the same issues that
> non leader NRT replicas have.
>
> - Houston
>
> On Wed, Oct 18, 2023 at 8:26 AM David Smiley 
> wrote:
>
> > Thank you both.  It helps to know that "_version"_ is for, I would say
> > succinctly, "NRT replication".  I mean; that deserves to be said
> internally
> > in some places!
> > Might it be advantageous to imagine it being optional for non-NRT
> > replicas?  I'm not sure if it saves anything or reduces complexity
> > anywhere.
> > Related question:  Is the VersionInfo (with its striped VersionBucket
> > locks) related to this -- is it a vestige of "_version_" or is it for
> > something else?  If it isn't for something else, then I could imagine it
> > being omitted for non-NRT; maybe a dummy implementation.  BTW Bruno
> opened
> > an issue/PR on it yesterday --
> > https://issues.apache.org/jira/browse/SOLR-17036
> >
> > ~ David
> >
> >
> > On Wed, Oct 18, 2023 at 1:41 AM Ishan Chattopadhyaya <
> > ichattopadhy...@gmail.com> wrote:
> >
> > > Fyi, SOLR-5944, is unreadable, but introduced the concept of previous
> > > version or something like that.
> > >
> > > On Wed, 18 Oct, 2023, 10:35 am Mark Miller, 
> > wrote:
> > >
> > > > The primary reason is as Ishan says - so that update reorders from
> > leader
> > > > to replica can be handled in both normal and failure cases.
> > > >
> > > > It’s also true that a part of the reason that the per document, NRT
> > > design,
> > > > with versions, was chosen was a desire to support per document
> > optimistic
> > > > concurrency.
> > > >
> > > > On Tue, Oct 17, 2023 at 11:37 PM Ishan Chattopadhyaya <
> > > > ichattopadhy...@gmail.com> wrote:
> > > >
> > > > > Also DBQs use the version field to ensure they are applied
> correctly,
> > > > even
> > > > > if a DBQ is reordered
> > > > >
> > > > > On Wed, 18 Oct, 2023, 10:05 am Ishan Chattopadhyaya, <
> > > > > ichattopadhy...@gmail.com> wrote:
> > > > >
> > > > > > To ensure reordered updates are processed properly from leader to
> > > other
> > > > > > replicas in NRT replication mode.
> > > > > >
> > > > > > On Wed, 18 Oct, 2023, 9:55 am David Smiley, 
> > > > wrote:
> > > > > >
> > > > > >> Question: Does the _version_ field have a purpose other than for
> > > > "atomic
> > > > > >> updates"?
> > > > > >> I know SolrCloud and/or having an UpdateLog insists on it.  But
> I
> > > > don't
> > > > > >> know if it's for that feature alone, or for additional
> non-obvious
> > > > > >> internal
> > > > > >> workings of SolrCloud.  Mostly I'm just asking to have a deeper
> > > > > >> understanding; the field doesn't bother me.  If someone knows of
> > any
> > > > > docs
> > > > > >> on it or old interesting JIRAs to read, I'd appreciate it.
> > > > > >>
> > > > > >> ~ David Smiley
> > > > > >> Apache Lucene/Solr Search Developer
> > > > > >> http://www.linkedin.com/in/davidwsmiley
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Community Virtual Meetup, October 2023

2023-10-19 Thread Jason Gerlowski 
> Please the meetup group owner can create the meetup and zoom/meet link, so we 
> can start sharing about the meetup on social media?

Created, see below!  (Don't forget to put these on the Confluence
"Meeting Notes" page when you get a chance)

Meet link: https://meet.google.com/vov-zirs-mno

Meetup.com event:
https://www.meetup.com/apache-solr-virtual-community-meetups/events/296835049
(If you organize again in the future and you create a Meetup.com
account, we can give you the required permissions to create this
yourself next time.)

Thanks again Alejandro!

Jason

On Thu, Oct 19, 2023 at 9:25 AM Alessandro Benedetti
 wrote:
>
> I'll be travelling to the Middle East (it should be 19:00 where I'll be),
> I'll try to attend!
>
> The idea of a competition is a cool one, I'm not a fan of rushing stuff and
> I'm not sure how much time we should allocate to such an activity, I
> suspect half an hour will not produce anything useful.
> But I'm definitely happy to see this as a separate new activity!
>
> --
> *Alessandro Benedetti*
> Director @ Sease Ltd.
> *Apache Lucene/Solr Committer*
> *Apache Solr PMC Member*
>
> e-mail: a.benede...@sease.io
>
>
> *Sease* - Information Retrieval Applied
> Consulting | Training | Open Source
>
> Website: Sease.io 
> LinkedIn  | Twitter
>  | Youtube
>  | Github
> 
>
>
> On Thu, 19 Oct 2023 at 14:22, Arrieta, Alejandro <
> aarri...@perrinsoftware.com> wrote:
>
> > Hello Team,
> >
> > Option A:
> > Thursday, Oct  26th, 9 AM Pacific/12PM US East
> > had the most/all votes so we have date and time.
> >
> > Please the meetup group owner can create the meetup and zoom/meet link, so
> > we can start sharing about the meetup on social media?
> >
> > Solr Wiki meetup link:
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=272927807
> >
> > Note: I created the newsletter as meeting notes and they appear on the list
> > of meetups, I will fix this later today. First time using Solr Wiki.
> >
> > Kind Regards,
> > Alejandro Arrieta
> >
> >
> > On Tue, Oct 17, 2023 at 8:21 AM Jason Gerlowski 
> > wrote:
> >
> > > Thanks for volunteering Alejandro.  Option 1 works for me.
> > >
> > > Ping me here or on Slack if you run into any permission issues (in
> > > Confluence, Meetup.com, etc.) getting things setup for the meetup;
> > > happy to help!
> > >
> > > > eating your own dogfood kind of competitions
> > >
> > > I really like the idea!  Though I agree with David that it seems like
> > > something that maybe merits its own event.  Unless the actual
> > > challenge part is asynchronous/offline?  That'd maybe be a bit less
> > > social/interactive, but it would help us fit the idea into the current
> > > monthly meetup, if that's the goal.  Anyway, definitely a fun idea
> > > worth pursuing!  Maybe spin off a separate thread to discuss, Ishan?
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Tue, Oct 17, 2023 at 12:43 AM David Smiley 
> > > wrote:
> > > >
> > > > I prefer the 26th (Thursday) as well.
> > > > ~ David
> > > >
> > > >
> > > > On Mon, Oct 16, 2023 at 11:06 AM Arrieta, Alejandro <
> > > > aarri...@perrinsoftware.com> wrote:
> > > >
> > > > > Hello Team,
> > > > >
> > > > > 1) pick me
> > > > >
> > > > > 2) proposed dates/time
> > > > > Thursday, Oct  26th, 9 AM Pacific/12PM US East
> > > > > or
> > > > > Friday, Oct  27th, 9 AM Pacific/12PM US East
> > > > > To have at least one week to promote the event.
> > > > > The vote should end Wednesday, Oct 18th, 11:59 PM Pacific, to publish
> > > the
> > > > > meetup link on Thursday, Oct 19th.
> > > > >
> > > > > Kind Regards,
> > > > > Alejandro Arrieta
> > > > >
> > > > > On Mon, Oct 16, 2023 at 9:40 AM Jason Gerlowski <
> > gerlowsk...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hey all,
> > > > > >
> > > > > > It's time once again to start thinking ahead to our Virtual Meetup
> > > for
> > > > > > October.  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 mid-week or so,
> > > I'm
> > > > > > more than happy to set things up for this month.
> > > > > >
> > > > > > 2. When should we meet?  It's already a good bit into the month, so
> > > > > > we'll have to plan for the latter half.  If you have any
> > > > > > opinions, please discuss.
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Jason
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe

Re: [DISCUSS] Community Virtual Meetup, October 2023

2023-10-19 Thread Alessandro Benedetti 
I'll be travelling to the Middle East (it should be 19:00 where I'll be),
I'll try to attend!

The idea of a competition is a cool one, I'm not a fan of rushing stuff and
I'm not sure how much time we should allocate to such an activity, I
suspect half an hour will not produce anything useful.
But I'm definitely happy to see this as a separate new activity!

--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*

e-mail: a.benede...@sease.io


*Sease* - Information Retrieval Applied
Consulting | Training | Open Source

Website: Sease.io 
LinkedIn  | Twitter
 | Youtube
 | Github



On Thu, 19 Oct 2023 at 14:22, Arrieta, Alejandro <
aarri...@perrinsoftware.com> wrote:

> Hello Team,
>
> Option A:
> Thursday, Oct  26th, 9 AM Pacific/12PM US East
> had the most/all votes so we have date and time.
>
> Please the meetup group owner can create the meetup and zoom/meet link, so
> we can start sharing about the meetup on social media?
>
> Solr Wiki meetup link:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=272927807
>
> Note: I created the newsletter as meeting notes and they appear on the list
> of meetups, I will fix this later today. First time using Solr Wiki.
>
> Kind Regards,
> Alejandro Arrieta
>
>
> On Tue, Oct 17, 2023 at 8:21 AM Jason Gerlowski 
> wrote:
>
> > Thanks for volunteering Alejandro.  Option 1 works for me.
> >
> > Ping me here or on Slack if you run into any permission issues (in
> > Confluence, Meetup.com, etc.) getting things setup for the meetup;
> > happy to help!
> >
> > > eating your own dogfood kind of competitions
> >
> > I really like the idea!  Though I agree with David that it seems like
> > something that maybe merits its own event.  Unless the actual
> > challenge part is asynchronous/offline?  That'd maybe be a bit less
> > social/interactive, but it would help us fit the idea into the current
> > monthly meetup, if that's the goal.  Anyway, definitely a fun idea
> > worth pursuing!  Maybe spin off a separate thread to discuss, Ishan?
> >
> > Best,
> >
> > Jason
> >
> > On Tue, Oct 17, 2023 at 12:43 AM David Smiley 
> > wrote:
> > >
> > > I prefer the 26th (Thursday) as well.
> > > ~ David
> > >
> > >
> > > On Mon, Oct 16, 2023 at 11:06 AM Arrieta, Alejandro <
> > > aarri...@perrinsoftware.com> wrote:
> > >
> > > > Hello Team,
> > > >
> > > > 1) pick me
> > > >
> > > > 2) proposed dates/time
> > > > Thursday, Oct  26th, 9 AM Pacific/12PM US East
> > > > or
> > > > Friday, Oct  27th, 9 AM Pacific/12PM US East
> > > > To have at least one week to promote the event.
> > > > The vote should end Wednesday, Oct 18th, 11:59 PM Pacific, to publish
> > the
> > > > meetup link on Thursday, Oct 19th.
> > > >
> > > > Kind Regards,
> > > > Alejandro Arrieta
> > > >
> > > > On Mon, Oct 16, 2023 at 9:40 AM Jason Gerlowski <
> gerlowsk...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > It's time once again to start thinking ahead to our Virtual Meetup
> > for
> > > > > October.  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 mid-week or so,
> > I'm
> > > > > more than happy to set things up for this month.
> > > > >
> > > > > 2. When should we meet?  It's already a good bit into the month, so
> > > > > we'll have to plan for the latter half.  If you have any
> > > > > opinions, please discuss.
> > > > >
> > > > > Best,
> > > > >
> > > > > Jason
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > > > > For additional commands, e-mail: dev-h...@solr.apache.org
> > > > >
> > > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >
>

Re: [DISCUSS] Community Virtual Meetup, October 2023

2023-10-19 Thread Arrieta, Alejandro 
Hello Team,

Option A:
Thursday, Oct  26th, 9 AM Pacific/12PM US East
had the most/all votes so we have date and time.

Please the meetup group owner can create the meetup and zoom/meet link, so
we can start sharing about the meetup on social media?

Solr Wiki meetup link:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=272927807

Note: I created the newsletter as meeting notes and they appear on the list
of meetups, I will fix this later today. First time using Solr Wiki.

Kind Regards,
Alejandro Arrieta


On Tue, Oct 17, 2023 at 8:21 AM Jason Gerlowski 
wrote:

> Thanks for volunteering Alejandro.  Option 1 works for me.
>
> Ping me here or on Slack if you run into any permission issues (in
> Confluence, Meetup.com, etc.) getting things setup for the meetup;
> happy to help!
>
> > eating your own dogfood kind of competitions
>
> I really like the idea!  Though I agree with David that it seems like
> something that maybe merits its own event.  Unless the actual
> challenge part is asynchronous/offline?  That'd maybe be a bit less
> social/interactive, but it would help us fit the idea into the current
> monthly meetup, if that's the goal.  Anyway, definitely a fun idea
> worth pursuing!  Maybe spin off a separate thread to discuss, Ishan?
>
> Best,
>
> Jason
>
> On Tue, Oct 17, 2023 at 12:43 AM David Smiley 
> wrote:
> >
> > I prefer the 26th (Thursday) as well.
> > ~ David
> >
> >
> > On Mon, Oct 16, 2023 at 11:06 AM Arrieta, Alejandro <
> > aarri...@perrinsoftware.com> wrote:
> >
> > > Hello Team,
> > >
> > > 1) pick me
> > >
> > > 2) proposed dates/time
> > > Thursday, Oct  26th, 9 AM Pacific/12PM US East
> > > or
> > > Friday, Oct  27th, 9 AM Pacific/12PM US East
> > > To have at least one week to promote the event.
> > > The vote should end Wednesday, Oct 18th, 11:59 PM Pacific, to publish
> the
> > > meetup link on Thursday, Oct 19th.
> > >
> > > Kind Regards,
> > > Alejandro Arrieta
> > >
> > > On Mon, Oct 16, 2023 at 9:40 AM Jason Gerlowski  >
> > > wrote:
> > >
> > > > Hey all,
> > > >
> > > > It's time once again to start thinking ahead to our Virtual Meetup
> for
> > > > October.  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 mid-week or so,
> I'm
> > > > more than happy to set things up for this month.
> > > >
> > > > 2. When should we meet?  It's already a good bit into the month, so
> > > > we'll have to plan for the latter half.  If you have any
> > > > opinions, please discuss.
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > > > For additional commands, e-mail: dev-h...@solr.apache.org
> > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>