[jira] [Updated] (LUCENE-10055) Update release scripts and documentation to use new INFRA svn repo
[ https://issues.apache.org/jira/browse/LUCENE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated LUCENE-10055: Description: Apache infra is deprecating (and soon removing) the SVN repo that we used to use for storing documentation that is hosted via the Lucene website. The new repo (https://svn.apache.org/repos/infra/sites/lucene) is still mounted to Apache hosts, and we will be able to use it similarly. The release wizard and release scripts need to be updated to use this new SVN repo, and paths within the repository. The directory structure is now (under the repo and path linked above): - core/ (javadocs) More information can be found at INFRA-21504 was: Apache infra is deprecating (and soon removing) the SVN repo that we used to use for storing documentation that is hosted via the Lucene website. The [new repo|https://issues.apache.org/jira/browse/INFRA-21504] (https://svn.apache.org/repos/infra/sites/lucene) is still mounted to Apache hosts, and we will be able to use it similarly. The release wizard and release scripts need to be updated to use this new SVN repo, and paths within the repository. The directory structure is now (under the repo and path linked above): - core/ (javadocs) > Update release scripts and documentation to use new INFRA svn repo > -- > > Key: LUCENE-10055 > URL: https://issues.apache.org/jira/browse/LUCENE-10055 > Project: Lucene - Core > Issue Type: Task > Components: release wizard >Affects Versions: 8.10 >Reporter: Houston Putman >Priority: Blocker > > Apache infra is deprecating (and soon removing) the SVN repo that we used to > use for storing documentation that is hosted via the Lucene website. > The new repo (https://svn.apache.org/repos/infra/sites/lucene) is still > mounted to Apache hosts, and we will be able to use it similarly. > The release wizard and release scripts need to be updated to use this new SVN > repo, and paths within the repository. > The directory structure is now (under the repo and path linked above): > - core/ (javadocs) > More information can be found at INFRA-21504 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10055) Update release scripts and documentation to use new INFRA svn repo
Houston Putman created LUCENE-10055: --- Summary: Update release scripts and documentation to use new INFRA svn repo Key: LUCENE-10055 URL: https://issues.apache.org/jira/browse/LUCENE-10055 Project: Lucene - Core Issue Type: Task Components: release wizard Affects Versions: 8.10 Reporter: Houston Putman Apache infra is deprecating (and soon removing) the SVN repo that we used to use for storing documentation that is hosted via the Lucene website. The [new repo|https://issues.apache.org/jira/browse/INFRA-21504] (https://svn.apache.org/repos/infra/sites/lucene) is still mounted to Apache hosts, and we will be able to use it similarly. The release wizard and release scripts need to be updated to use this new SVN repo, and paths within the repository. The directory structure is now (under the repo and path linked above): - core/ (javadocs) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15167) Move lucene-solr-operator repo
[ https://issues.apache.org/jira/browse/SOLR-15167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17299632#comment-17299632 ] Houston Putman commented on SOLR-15167: --- Infra ticket has been created: INFRA-21561 Shooting for Monday March 15 now. > Move lucene-solr-operator repo > -- > > Key: SOLR-15167 > URL: https://issues.apache.org/jira/browse/SOLR-15167 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > The lucene-solr-operator repo will be (once again) moved, now to > "solr-operator". This must be ordered thorugh an INFRA ticker. > As this will once again break the URL for helm, that also needs an update in > relevant places. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15211) Set up solr-operator as a sub project
[ https://issues.apache.org/jira/browse/SOLR-15211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298965#comment-17298965 ] Houston Putman commented on SOLR-15211: --- Thanks for the help [~janhoy]l! I'll get started that asap. It looks like I can use URLs that will be available in the future, since there is some information in the Solr one that doesn't exist yet (e.g. https://gitbox.apache.org/repos/asf?p=solr.git). > Set up solr-operator as a sub project > - > > Key: SOLR-15211 > URL: https://issues.apache.org/jira/browse/SOLR-15211 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > * Create DOAP file for it > * Find a way to highlight the sub project on Solr webpage (with a link to > GitHub) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9829) Default github PR merging to "squash"
[ https://issues.apache.org/jira/browse/LUCENE-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298955#comment-17298955 ] Houston Putman commented on LUCENE-9829: This isn't really important since the other two options aren't allowed anymore, but for posterity: You can only specify "allowed" merge strategies, you can't set a default. Github will default to the option you used last in the same repo. Since these were your first PRs in the new repos, it defaulted to the first allowed option: "Merge commit". > Default github PR merging to "squash" > - > > Key: LUCENE-9829 > URL: https://issues.apache.org/jira/browse/LUCENE-9829 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > > I think it now creates a merge commit - don't know who did the squash default > or how to set it up on Lucene/Solr repos. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15222) Solr should not auto-create the "userfiles" dir
[ https://issues.apache.org/jira/browse/SOLR-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298951#comment-17298951 ] Houston Putman commented on SOLR-15222: --- Not sure I love requiring people create the directory on their own, but I definitely agree it shouldn't be autocreated if the feature isn't used. Would it be possible to create the directory the first time someone tries to upload a file to the "filestore"? > Solr should not auto-create the "userfiles" dir > --- > > Key: SOLR-15222 > URL: https://issues.apache.org/jira/browse/SOLR-15222 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Priority: Major > > The "userfiles" feature is relatively obscure and might be subsumed by the > "file store". I don't think an obscure feature should be auto-creating its > "userfiles" directory. Even a popular one; not sure it makes sense. If a > user wants to use this feature, they are welcome to create the directory. > Solr has other optional directories, like solr-home/lib that are not > auto-created; it's not clear to me why this one is. I've found the > auto-creation of this dir to be annoying in two ways. One is in Solr's tests > – there are existing Jira issues that show stack traces about this even > though it's ignored. Secondly is as a down-stream consumer for > running/building Solr plugins that have a Solr home dir pointing somewhere > that suddenly has this userfiles dir popping up despite me having no plans to > use it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15229) Link Solr DOAP correctly from website
[ https://issues.apache.org/jira/browse/SOLR-15229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298283#comment-17298283 ] Houston Putman commented on SOLR-15229: --- When we update the releaseWizard to do Solr alone, should we move the doap file to the website? > Link Solr DOAP correctly from website > - > > Key: SOLR-15229 > URL: https://issues.apache.org/jira/browse/SOLR-15229 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > It is recommended to have the DOAP file on the project's website, as it is > confusing that the DOAP file exists in different versions in the various code > branches (it is only the DOAP files from master branch that is used). So in > this Jira we'll > * -Move Solr's DOAP file to the solr-site.git repo (e.g. > [https://solr.apache.org/doap-Solr.rdf)|https://solr.apache.org/doap-Solr.rdf]- > * Update .htaccess redirect so [https://solr.apache.org/doap/solr.rdf] > points to our DOAP in git > * Update > [https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml] > to link to the new location > Last step will be to update .htaccess once again to point to new solr.git > once it is live (see [https://github.com/apache/solr-site/pull/5)] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15167) Move lucene-solr-operator repo
[ https://issues.apache.org/jira/browse/SOLR-15167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297458#comment-17297458 ] Houston Putman commented on SOLR-15167: --- I'm planning on doing the move on Friday March 12th. The helm charts are now at a stable location: https://solr.apache.org/charts > Move lucene-solr-operator repo > -- > > Key: SOLR-15167 > URL: https://issues.apache.org/jira/browse/SOLR-15167 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > The lucene-solr-operator repo will be (once again) moved, now to > "solr-operator". This must be ordered thorugh an INFRA ticker. > As this will once again break the URL for helm, that also needs an update in > relevant places. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15167) Move lucene-solr-operator repo
[ https://issues.apache.org/jira/browse/SOLR-15167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293789#comment-17293789 ] Houston Putman commented on SOLR-15167: --- I think it'll be good to announce after the repo has a permanent location. I can handle doing the website and ANNOUNCE emails. It shouldn't take long anyways. I'm ready to move once we have the solr site up and running, that I can host the helm charts at. I think it should be listed as a subproject, but I'm not exactly sure what that entails. Actually I do think we will need a separate sub-project, since we will need a separate DOAP file, right? > Move lucene-solr-operator repo > -- > > Key: SOLR-15167 > URL: https://issues.apache.org/jira/browse/SOLR-15167 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Houston Putman >Priority: Major > > The lucene-solr-operator repo will be (once again) moved, now to > "solr-operator". This must be ordered thorugh an INFRA ticker. > As this will once again break the URL for helm, that also needs an update in > relevant places. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15190) Create a release repo for Solr
[ https://issues.apache.org/jira/browse/SOLR-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293787#comment-17293787 ] Houston Putman commented on SOLR-15190: --- We will need to have this if the solr-operator needs a release, correct? If so I imagine the Solr Operator v0.3.0 will be cut much sooner than Solr 9.0 > Create a release repo for Solr > -- > > Key: SOLR-15190 > URL: https://issues.apache.org/jira/browse/SOLR-15190 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > I think this will be created as we do the first release, i.e. nothing > explicit to do here until then? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14499) New Solr TLP site
[ https://issues.apache.org/jira/browse/SOLR-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292932#comment-17292932 ] Houston Putman commented on SOLR-14499: --- Also on the mailing list page bq. NOTE: Please do not send mail to this list with usage questions or configuration questions and problems, that is what the solr-user mailing list is for. should be changed to: bq. NOTE: Please do not send mail to this list with usage questions or configuration questions and problems, that is what the users mailing list is for. > New Solr TLP site > - > > Key: SOLR-14499 > URL: https://issues.apache.org/jira/browse/SOLR-14499 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Paletton-color-palette.html, code-hilite-after.png, > code-hilite-before.png, only-yellow.png, solr-has-moved-modal.png, > solr-new-site-screenshot.png, solr-security-and-news.png, > solr-site-green.png, solr-site-green.png, solr-site-yellow.png, > solr-site-yellow.png, stacked.png > > > # Get setup solr-site repo (start from lucene-site repo) > # Setup a temporary "work in progress" page on solr.apache.org > # Remove all lucene TLP, lucene-core and pylucene content, including > templates and css etc > # Move Solr index.html as main index file > # Simplify folder structure for Pelican > # Publish the new site -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14499) New Solr TLP site
[ https://issues.apache.org/jira/browse/SOLR-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292922#comment-17292922 ] Houston Putman commented on SOLR-14499: --- Some of the resources links still go to /solr/, such as the Ref Guide and the Java docs. Is this intentional, or are we planning on removing the /solr/ from the URL path when moving these resources? > New Solr TLP site > - > > Key: SOLR-14499 > URL: https://issues.apache.org/jira/browse/SOLR-14499 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Paletton-color-palette.html, code-hilite-after.png, > code-hilite-before.png, only-yellow.png, solr-has-moved-modal.png, > solr-new-site-screenshot.png, solr-security-and-news.png, > solr-site-green.png, solr-site-green.png, solr-site-yellow.png, > solr-site-yellow.png, stacked.png > > > # Get setup solr-site repo (start from lucene-site repo) > # Setup a temporary "work in progress" page on solr.apache.org > # Remove all lucene TLP, lucene-core and pylucene content, including > templates and css etc > # Move Solr index.html as main index file > # Simplify folder structure for Pelican > # Publish the new site -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15194) JWTIssuerConfig only allows HTTPS urls, not HTTP, which is overly strict.
[ https://issues.apache.org/jira/browse/SOLR-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291037#comment-17291037 ] Houston Putman commented on SOLR-15194: --- A thanks for the correction [~janhoy]! > JWTIssuerConfig only allows HTTPS urls, not HTTP, which is overly strict. > - > > Key: SOLR-15194 > URL: https://issues.apache.org/jira/browse/SOLR-15194 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Affects Versions: master (9.0), 8.8.1 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Setting up JWT should always be done with HTTPS urls, but especially in dev > and test, require HTTPS is too much. > Let Solr relax a bit, and log a warning if the url is HTTP versus HTTPS. > > Keycloak, out of the box for example doesn't have SSL enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15194) JWTIssuerConfig only allows HTTPS urls, not HTTP, which is overly strict.
[ https://issues.apache.org/jira/browse/SOLR-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291010#comment-17291010 ] Houston Putman commented on SOLR-15194: --- I think this is a good idea. People also may be terminating TLS before a request hits Solr. So while Solr does not have TLS enabled, that does not mean requests are not protected. > JWTIssuerConfig only allows HTTPS urls, not HTTP, which is overly strict. > - > > Key: SOLR-15194 > URL: https://issues.apache.org/jira/browse/SOLR-15194 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Affects Versions: master (9.0), 8.8.1 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Minor > > Setting up JWT should always be done with HTTPS urls, but especially in dev > and test, require HTTPS is too much. > Let Solr relax a bit, and log a warning if the url is HTTP versus HTTPS. > > Keycloak, out of the box for example doesn't have SSL enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14499) New Solr TLP site
[ https://issues.apache.org/jira/browse/SOLR-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289396#comment-17289396 ] Houston Putman commented on SOLR-14499: --- I think I prefer the burnt-yellow -> green -> black option. This shows news independently from security announcements. Also both are on top, as announcements should be IMO. It looks really nice > New Solr TLP site > - > > Key: SOLR-14499 > URL: https://issues.apache.org/jira/browse/SOLR-14499 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Paletton-color-palette.html, only-yellow.png, > solr-new-site-screenshot.png, solr-security-and-news.png, > solr-site-green.png, solr-site-green.png, solr-site-yellow.png, > solr-site-yellow.png, stacked.png > > > # Get setup solr-site repo (start from lucene-site repo) > # Setup a temporary "work in progress" page on solr.apache.org > # Remove all lucene TLP, lucene-core and pylucene content, including > templates and css etc > # Move Solr index.html as main index file > # Simplify folder structure for Pelican > # Publish the new site -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15186) Find a better way to host javadoc and refGuide for website
[ https://issues.apache.org/jira/browse/SOLR-15186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289150#comment-17289150 ] Houston Putman commented on SOLR-15186: --- This will also be useful for hosting the Solr Helm Charts, since we will hopefully be hosting those via the website. They should be small enough to store in the solr-site repo, but we can use the same solution as we choose for javadoc and refguide. I'm up for either. We can also start with solr-site, and move them to the javadoc and refGuide location once we solidify those two. > Find a better way to host javadoc and refGuide for website > -- > > Key: SOLR-15186 > URL: https://issues.apache.org/jira/browse/SOLR-15186 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: website >Reporter: Jan Høydahl >Priority: Major > > Spinoff from SOLR-15177 > It is said that the svn space we host our historic javadoc and refguide > content is deprecated and we should find some better way to serve that static > content. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15176) Mailing list for solr-operator?
[ https://issues.apache.org/jira/browse/SOLR-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288529#comment-17288529 ] Houston Putman commented on SOLR-15176: --- Good question. We can always start with sharing the lists, as is done now, and create separate ones if there is enough demand. > Mailing list for solr-operator? > --- > > Key: SOLR-15176 > URL: https://issues.apache.org/jira/browse/SOLR-15176 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Do we need a separate mailing list for the solr-operator? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-15177: -- Comment: was deleted (was: I'm not sure if this is the right ticket to discuss this, but we should make sure that the old location of the ref guide (https://lucene.apache.org/solr/guide/) and all sub-links, all forward correctly to the new location.) > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15177) Handle RefGuide and JavaDoc on solr.apache.org site
[ https://issues.apache.org/jira/browse/SOLR-15177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288473#comment-17288473 ] Houston Putman commented on SOLR-15177: --- I'm not sure if this is the right ticket to discuss this, but we should make sure that the old location of the ref guide (https://lucene.apache.org/solr/guide/) and all sub-links, all forward correctly to the new location. > Handle RefGuide and JavaDoc on solr.apache.org site > --- > > Key: SOLR-15177 > URL: https://issues.apache.org/jira/browse/SOLR-15177 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Make sure we have a working solution for referencing both old and new (9.x) > ref-guides and javadoc. > * Shall we move solr-related content in svn and point everything to the new > site? > * Make sure .htaccess rules work for this -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15019) Replica placement API needs a way to fetch existing replica metrics
[
https://issues.apache.org/jira/browse/SOLR-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286680#comment-17286680
]
Houston Putman commented on SOLR-15019:
---
[~ab], I was looking around the available metrics in the metrics endpoint and I
noticed something troubling.
This patch added the ability to get System Environment Variables via the
metrics handler. In theory this should be similar to retrieving the system
properties passed to Solr (which has been available since Solr 8 at least).
However, there is a big difference between the two. Users decide which system
properties should be passed to Solr, and can restrict them. However this is not
the case with environment variables. Those can be in use for other applications
or generally not meant to be used by Solr at all.
The biggest issue I have is with sensitive information being accessible via the
metrics handler through these envVars. Solr is able to protect well-known
system properties by default, because these have defined names that Solr is
looking for, such as {{zkDigestPassword}} or
{{javax.net.ssl.keyStorePassword}}. However, since Solr isn't reading these
values from environment variables, it has no knowledge of the environment
variables users may be using to store this information. [The code is merely
using|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L247-L254]
the same {{hiddenSysProps}} used to protect sysProps. However this default
list is unchanged and the documentation around metrics wasn't changed to
reflect that envVars are also visible now.
Is it absolutely necessary to be able to use Env Vars for autoscaling? If we
could rely only on system properties, then we wouldn't have to have this
additional vector that people have to lock down. I don't really think it's
reasonable to expect users to know all sensitive env vars available for a
system, and list them in the metrics config. Those could change during runtime
or be unknown to the person running the instance.
> Replica placement API needs a way to fetch existing replica metrics
> ---
>
> Key: SOLR-15019
> URL: https://issues.apache.org/jira/browse/SOLR-15019
> Project: Solr
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 9h 20m
> Remaining Estimate: 0h
>
> Replica placement API was introduced in SOLR-14613. It offers a few sample
> (and simple) implementations of placement plugins.
> However, this API doesn't offer support for retrieving per-replica metrics,
> which are required for calculating more realistic placements. For example,
> when calculating placements for ADDREPLICA on an already existing collection
> the plugin should know what is the size of replica in order to avoid placing
> large replicas on nodes with insufficient free disk space.
> After discussing this with [~ilan] we propose the following additions to the
> API:
> * use the existing {{AttributeFetcher}} interface as a facade for retrieving
> per-replica values (currently it only retrieves per-node values)
> * add {{ShardValues}} interface to represent strongly-typed API for key
> metrics, such as replica size, number of docs, number of update and search
> requests.
> Plugins could then use this API like this:
> {code}
> AttributeFetcher attributeFetcher = ...
> SolrCollection solrCollection = ...
> Set metricNames = ...
> attributeFetcher.requestCollectionMetrics(solrCollection,
> solrCollection.getShardNames(), metricNames);
> AttributeValues attributeValues = attributeFetcher.fetchAttributes();
> ShardValues shardValues =
> attributeValues.getShardMetrics(solrCollection.getName(), shardName);
> int sizeInGB = shardValues.getSizeInGB(); // retrieves shard leader metrics
> int replicaSizeInGB = shardValues.getSizeInGB(replica);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9780) Only validate JARs for tasks that are enabled.
[
https://issues.apache.org/jira/browse/LUCENE-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved LUCENE-9780.
Fix Version/s: master (9.0)
Assignee: Houston Putman
Resolution: Fixed
> Only validate JARs for tasks that are enabled.
> --
>
> Key: LUCENE-9780
> URL: https://issues.apache.org/jira/browse/LUCENE-9780
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently if you disable parts of the build, such as the tasks in
> {{solr-ref-guide}}, the {{checkDanglingLicenseFiles}} task can fail. This is
> because if all tasks for a module are disabled, then the {{jarInfos}} task
> will be disabled, resulting in a missing {{jarInfos}} property.
> I understand this isn't a normal use case for the gradle check functionality,
> but because you can't build the {{solr-ref-guide}} with proxy repos, it's
> necessary to disable the project when trying to build in a restricted
> environment. (The solr-ref-guide is meant to be ignored from the Licenses
> checks, however it still fails when you disable tasks for the project.)
> An easy fix would be to merely check to make sure a task is enabled before
> trying to get the {{jarInfos}} for it's project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9780) Only validate JARs for tasks that are enabled.
Houston Putman created LUCENE-9780:
--
Summary: Only validate JARs for tasks that are enabled.
Key: LUCENE-9780
URL: https://issues.apache.org/jira/browse/LUCENE-9780
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: master (9.0)
Reporter: Houston Putman
Currently if you disable parts of the build, such as the tasks in
{{solr-ref-guide}}, the {{checkDanglingLicenseFiles}} task can fail. This is
because if all tasks for a module are disabled, then the {{jarInfos}} task will
be disabled, resulting in a missing {{jarInfos}} property.
I understand this isn't a normal use case for the gradle check functionality,
but because you can't build the {{solr-ref-guide}} with proxy repos, it's
necessary to disable the project when trying to build in a restricted
environment. (The solr-ref-guide is meant to be ignored from the Licenses
checks, however it still fails when you disable tasks for the project.)
An easy fix would be to merely check to make sure a task is enabled before
trying to get the {{jarInfos}} for it's project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15129) Use the Solr TGZ artifact as Docker context
[
https://issues.apache.org/jira/browse/SOLR-15129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284025#comment-17284025
]
Houston Putman commented on SOLR-15129:
---
I have created an issue in the Docker solr repo, and tagged tianon. Please feel
free to add any information if I have missed it.
https://github.com/docker-solr/docker-solr/issues/368
> Use the Solr TGZ artifact as Docker context
> ---
>
> Key: SOLR-15129
> URL: https://issues.apache.org/jira/browse/SOLR-15129
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Priority: Major
>
> As discussed in SOLR-15127, there is a need for a unified Dockerfile that
> allows for release and local builds.
> This ticket is an attempt to achieve this by using the Solr distribution TGZ
> as the docker context to build from.
> Therefore release images would be completely reproducible by running:
> {{docker build -f solr-9.0.0/Dockerfile
> https://www.apache.org/dyn/closer.lua/lucene/solr/9.0.0/solr-9.0.0.tgz}}
> The changes to the Solr distribution would include adding a Dockerfile at
> {{solr-/Dockerfile}}, adding the docker scripts under
> {{solr-/docker}}, and adding a version file at
> {{solr-/VERSION.txt}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-15129) Use the Solr TGZ artifact as Docker context
[
https://issues.apache.org/jira/browse/SOLR-15129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283393#comment-17283393
]
Houston Putman edited comment on SOLR-15129 at 2/11/21, 9:43 PM:
-
[~dsmiley], that's what the _/elasticsearch image looks like. It's a hardcoded
sha reference of the image built within elastic.
{{FROM
docker.elastic.co/elasticsearch/elasticsearch:7.10.1@sha256:5d8f1962907ef60746a8cf61c8a7f2b8755510ee36bdee0f65417f90a38a0139}}
We could certainly make that a part of the ReleaseWizard. It would stop us from
doing incremental updates however for base images. I don't think that's a
sticking point though.
As per Hoss' comments above about the git repository being hosted on apache
hardware, and the binary release being hosted on mirrors, couldn't we use
https://downloads.apache.org/lucene/solr/8.8.0/solr-8.8.0.tgz? That's hosted on
apache hardware. I don't see a large difference in the security provided by the
git repo vs the security provided by the tgz on apache hardware.
I can summarize our master plan and include the options we are looking at
(github and binary release).
was (Author: houston):
[~dsmiley], that's what the _/elasticsearch image looks like. It's a hardcoded
sha reference of the image built within elastic.
{{FROM
docker.elastic.co/elasticsearch/elasticsearch:7.10.1@sha256:5d8f1962907ef60746a8cf61c8a7f2b8755510ee36bdee0f65417f90a38a0139}}
We could certainly make that a part of the ReleaseWizard. It would stop us from
doing incremental updates however for base images. I don't think that's a
sticking point though.
As per Hoss' comments above about the git repository being hosted on apache
hardware, and the binary release being hosted on mirrors, couldn't we use
https://downloads.apache.org/lucene/solr/8.8.0/solr-8.8.0.tgz? That's hosted on
apache hardware. I don't see a large difference in the security provided by the
git repo vs the security provided by the tgz on apache hardware.
I can summarize our master plan and have it be independent of which input we
use (github or binary release), since I doubt that will make a difference in
whether they accept it or not.
> Use the Solr TGZ artifact as Docker context
> ---
>
> Key: SOLR-15129
> URL: https://issues.apache.org/jira/browse/SOLR-15129
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Priority: Major
>
> As discussed in SOLR-15127, there is a need for a unified Dockerfile that
> allows for release and local builds.
> This ticket is an attempt to achieve this by using the Solr distribution TGZ
> as the docker context to build from.
> Therefore release images would be completely reproducible by running:
> {{docker build -f solr-9.0.0/Dockerfile
> https://www.apache.org/dyn/closer.lua/lucene/solr/9.0.0/solr-9.0.0.tgz}}
> The changes to the Solr distribution would include adding a Dockerfile at
> {{solr-/Dockerfile}}, adding the docker scripts under
> {{solr-/docker}}, and adding a version file at
> {{solr-/VERSION.txt}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15129) Use the Solr TGZ artifact as Docker context
[
https://issues.apache.org/jira/browse/SOLR-15129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283393#comment-17283393
]
Houston Putman commented on SOLR-15129:
---
[~dsmiley], that's what the _/elasticsearch image looks like. It's a hardcoded
sha reference of the image built within elastic.
{{FROM
docker.elastic.co/elasticsearch/elasticsearch:7.10.1@sha256:5d8f1962907ef60746a8cf61c8a7f2b8755510ee36bdee0f65417f90a38a0139}}
We could certainly make that a part of the ReleaseWizard. It would stop us from
doing incremental updates however for base images. I don't think that's a
sticking point though.
As per Hoss' comments above about the git repository being hosted on apache
hardware, and the binary release being hosted on mirrors, couldn't we use
https://downloads.apache.org/lucene/solr/8.8.0/solr-8.8.0.tgz? That's hosted on
apache hardware. I don't see a large difference in the security provided by the
git repo vs the security provided by the tgz on apache hardware.
I can summarize our master plan and have it be independent of which input we
use (github or binary release), since I doubt that will make a difference in
whether they accept it or not.
> Use the Solr TGZ artifact as Docker context
> ---
>
> Key: SOLR-15129
> URL: https://issues.apache.org/jira/browse/SOLR-15129
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Priority: Major
>
> As discussed in SOLR-15127, there is a need for a unified Dockerfile that
> allows for release and local builds.
> This ticket is an attempt to achieve this by using the Solr distribution TGZ
> as the docker context to build from.
> Therefore release images would be completely reproducible by running:
> {{docker build -f solr-9.0.0/Dockerfile
> https://www.apache.org/dyn/closer.lua/lucene/solr/9.0.0/solr-9.0.0.tgz}}
> The changes to the Solr distribution would include adding a Dockerfile at
> {{solr-/Dockerfile}}, adding the docker scripts under
> {{solr-/docker}}, and adding a version file at
> {{solr-/VERSION.txt}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15127) All-In-One Dockerfile for building local images as well as reproducible release builds directly from (remote) git tags
[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280023#comment-17280023
]
Houston Putman commented on SOLR-15127:
---
I think having a conditional RUN in the Dockerfile to support 2 different ways
of building is convenient, but I don't think it makes it very clear for users
to understand where the resulting image comes from. (because it could have been
either of the two code paths)
I do very much agree that having a "build from a remote git url" approach would
be user friendly for users wanting to build images of various points in the git
history. I actually am more in favor of having a strict build from source, than
having the RUN give two separate options. If the build-image was completely
restricted to using gradle, then we could also get the SOLR_VERSION from
gradle. Just add a {{./gradlew solrVersion}} task, or something like that.
While I do think that would be convenient for users trying to build without a
Java environment, it would be a downgrade in usability for local development.
Not being able to use local gradle settings would be unfortunate.
I do agree with your issues in SOLR-15127, regarding not being able to validate
the Solr TGZ context before using it as a context. It is unfortunate that
docker doesn't provide us with the ability to verify TGZs before using the
context, because I do think that the TGZ solution finds the middle ground of
the issues mentioned above.
Sorry I don't have a clear opinion on how to go forward. I think there are
downsides for all 3 options. But for now I think the lowest downside option is:
Build from clean git repo, without the conditional in RUN. We will have to
think of how this integrates with the rest of the gradle build. It will
certainly be interesting.
> All-In-One Dockerfile for building local images as well as reproducible
> release builds directly from (remote) git tags
> --
>
> Key: SOLR-15127
> URL: https://issues.apache.org/jira/browse/SOLR-15127
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-15127.patch
>
>
> There was a recent dev@lucene discussion about the future of the
> github/docker-solr repo and (Apache) "official" solr docker images and using
> the "apache/solr" nameing vs (docker-library official) "_/solr" names...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAD4GwrNCPEnAJAjy4tY%3DpMeX5vWvnFyLe9ZDaXmF4J8XchA98Q%40mail.gmail.com%3E
> In that disussion, mak pointed out that docker-library evidently allows for
> some more flexibility in the way "official" docker-library packages can be
> built (compared to the rules that were evidnlty in place when the mak setup
> the current docker-solr image building process/tooling), pointing out how the
> "docker official" elasticsearch images are current built from the "elastic
> official" elasticsearch images...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3C3CED9683-1DD2-4F08-97F9-4FC549EDE47D%40greenhills.co.uk%3E
> Based on this, I proposed that we could probably restructure the Solr
> Dockerfile so that it could be useful for both "local development" -- using
> the current repo checkout -- as well as for "apache official" apache/solr
> images that could be reproducibly built directly from pristine git tags using
> the remote git URL syntax supported by "docker build" (and then -- evidently
> -- extended by trivial one line Dockerfiles for the "docker-library official"
> _/solr images)...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101221423340.16298%40slate%3E
> This jira tracks this idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15132) Add window paramater to the nodes Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-15132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17278266#comment-17278266
]
Houston Putman commented on SOLR-15132:
---
my question is, does "nodes()" have any idea what "time_ten_seconds" is, or is
it just walking the previous 3 buckets that are returned from the facet? is the
window not just a number of buckets at the end of the day?
> Add window paramater to the nodes Streaming Expression
> --
>
> Key: SOLR-15132
> URL: https://issues.apache.org/jira/browse/SOLR-15132
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
>
> The *nodes* Streaming Expression performs a breadth first graph traversal.
> This ticket will add a *window* parameter to allow the nodes expression to
> traverse the graph within a window of time.
> To take advantage of this feature you must index the content with a String
> field which is an ISO timestamp truncated at ten seconds. Then the *window*
> parameter can be applied to walk the graph within a *window prior* to a
> specific ten second window and perform aggregations.
> Here is an example using Solr logs to answer the following question:
> What types of log events occurred in the 30 second window prior to 10 second
> windows with the most slow queries:
> {code}
> nodes(facet(logs, q="qtime_s:[5000 TO *]", buckets="time_ten_seconds",
> rows="25"),
> walk="time_ten_seconds->time_ten_seconds",
> window="3",
> gather="type_s",
> count(*))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15132) Add window paramater to the nodes Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-15132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17278222#comment-17278222
]
Houston Putman commented on SOLR-15132:
---
If this is just looking at the last {{n}} buckets when {{window=n}}, then why
does the bucket field need to be an ISO timestamp in a string field?
> Add window paramater to the nodes Streaming Expression
> --
>
> Key: SOLR-15132
> URL: https://issues.apache.org/jira/browse/SOLR-15132
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
>
> The *nodes* Streaming Expression performs a breadth first graph traversal.
> This ticket will add a *window* parameter to allow the nodes expression to
> traverse the graph within a window of time.
> To take advantage of this feature you must index the content with a String
> field which is an ISO timestamp truncated at ten seconds. Then the *window*
> parameter can be applied to walk the graph within a *window prior* to a
> specific ten second window and perform aggregations.
> Here is an example using Solr logs to answer the following question:
> What types of log events occurred in the 30 second window prior to 10 second
> windows with the most slow queries:
> {code}
> nodes(facet(logs, q="qtime_s:[5000 TO *]", buckets="time_ten_seconds",
> rows="25"),
> walk="time_ten_seconds->time_ten_seconds",
> window="3",
> gather="type_s",
> count(*))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-15127) All-In-One Dockerfile for building local images as well as reproducible release builds directly from (remote) git tags
[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277530#comment-17277530
]
Houston Putman edited comment on SOLR-15127 at 2/2/21, 11:49 PM:
-
I think there are two possible ways of going forward with something that the
official Docker image people might be ok with.
# Using the git tags, as with your example. Doing the gradle build in the
multi-stage build.
# [~dsmiley]'s suggestion of using the Solr TGZ release as the docker context
itself.
** In order to have the Solr TGZ become the docker context, we would merely
need to add the Dockerfile and solr/docker/scripts to the release.
I'll put up a PR that would use the Solr TGZ as the docker context, allowing us
to use docker build directly with the released artifacts. That way we can
compare pros/cons of each approach. (Can be found at SOLR-15129)
Besides this bigger question. There are some things I really like in your patch:
* Trying to remove the SOLR_VERSION argument (Big improvement, as there would
be no required ARGs)
** I think we can actually add the version as a file inside the release, and
then read it into an env var as a part of RUN.
Then we can sym-link from /opt/solr to /opt/solr-$version, to keep backwards
compatibility.
* Consolidating the last two RUN layers
I am split on the jattach thing. It will be great when it can be moved to the
{{apt-get install}} section. Until then, I don't mind if it's fetched in the
actual image or the builder image. Did you move it to the builder so that the
final image wouldn't need the GITHUB_URL arg?
was (Author: houston):
I think there are two possible ways of going forward with something that the
official Docker image people might be ok with.
# Using the git tags, as with your example. Doing the gradle build in the
multi-stage build.
# [~dsmiley]'s suggestion of using the Solr TGZ release as the docker context
itself.
** In order to have the Solr TGZ become the docker context, we would merely
need to add the Dockerfile and solr/docker/scripts to the release.
I'll put up a PR that would use the Solr TGZ as the docker context, allowing us
to use docker build directly with the released artifacts. That way we can
compare pros/cons of each approach.
Besides this bigger question. There are some things I really like in your patch:
* Trying to remove the SOLR_VERSION argument (Big improvement, as there would
be no required ARGs)
** I think we can actually add the version as a file inside the release, and
then read it into an env var as a part of RUN.
Then we can sym-link from /opt/solr to /opt/solr-$version, to keep backwards
compatibility.
* Consolidating the last two RUN layers
I am split on the jattach thing. It will be great when it can be moved to the
{{apt-get install}} section. Until then, I don't mind if it's fetched in the
actual image or the builder image. Did you move it to the builder so that the
final image wouldn't need the GITHUB_URL arg?
> All-In-One Dockerfile for building local images as well as reproducible
> release builds directly from (remote) git tags
> --
>
> Key: SOLR-15127
> URL: https://issues.apache.org/jira/browse/SOLR-15127
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-15127.patch
>
>
> There was a recent dev@lucene discussion about the future of the
> github/docker-solr repo and (Apache) "official" solr docker images and using
> the "apache/solr" nameing vs (docker-library official) "_/solr" names...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAD4GwrNCPEnAJAjy4tY%3DpMeX5vWvnFyLe9ZDaXmF4J8XchA98Q%40mail.gmail.com%3E
> In that disussion, mak pointed out that docker-library evidently allows for
> some more flexibility in the way "official" docker-library packages can be
> built (compared to the rules that were evidnlty in place when the mak setup
> the current docker-solr image building process/tooling), pointing out how the
> "docker official" elasticsearch images are current built from the "elastic
> official" elasticsearch images...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3C3CED9683-1DD2-4F08-97F9-4FC549EDE47D%40greenhills.co.uk%3E
> Based on this, I proposed that we could probably restructure the Solr
> Dockerfile so that it could be useful for both "local development" -- using
> the current repo checkout -- as well as for "apache official" apache/solr
> images that could be reproducibly built directly from pristine git tags using
> the remote git URL syntax supported by "docker build"
[jira] [Created] (SOLR-15129) Use the Solr TGZ artifact as Docker context
Houston Putman created SOLR-15129:
-
Summary: Use the Solr TGZ artifact as Docker context
Key: SOLR-15129
URL: https://issues.apache.org/jira/browse/SOLR-15129
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (9.0)
Reporter: Houston Putman
As discussed in SOLR-15127, there is a need for a unified Dockerfile that
allows for release and local builds.
This ticket is an attempt to achieve this by using the Solr distribution TGZ as
the docker context to build from.
Therefore release images would be completely reproducible by running:
{{docker build -f solr-9.0.0/Dockerfile
https://www.apache.org/dyn/closer.lua/lucene/solr/9.0.0/solr-9.0.0.tgz}}
The changes to the Solr distribution would include adding a Dockerfile at
{{solr-/Dockerfile}}, adding the docker scripts under
{{solr-/docker}}, and adding a version file at
{{solr-/VERSION.txt}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15127) All-In-One Dockerfile for building local images as well as reproducible release builds directly from (remote) git tags
[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277530#comment-17277530
]
Houston Putman commented on SOLR-15127:
---
I think there are two possible ways of going forward with something that the
official Docker image people might be ok with.
# Using the git tags, as with your example. Doing the gradle build in the
multi-stage build.
# [~dsmiley]'s suggestion of using the Solr TGZ release as the docker context
itself.
** In order to have the Solr TGZ become the docker context, we would merely
need to add the Dockerfile and solr/docker/scripts to the release.
I'll put up a PR that would use the Solr TGZ as the docker context, allowing us
to use docker build directly with the released artifacts. That way we can
compare pros/cons of each approach.
Besides this bigger question. There are some things I really like in your patch:
* Trying to remove the SOLR_VERSION argument (Big improvement, as there would
be no required ARGs)
** I think we can actually add the version as a file inside the release, and
then read it into an env var as a part of RUN.
Then we can sym-link from /opt/solr to /opt/solr-$version, to keep backwards
compatibility.
* Consolidating the last two RUN layers
I am split on the jattach thing. It will be great when it can be moved to the
{{apt-get install}} section. Until then, I don't mind if it's fetched in the
actual image or the builder image. Did you move it to the builder so that the
final image wouldn't need the GITHUB_URL arg?
> All-In-One Dockerfile for building local images as well as reproducible
> release builds directly from (remote) git tags
> --
>
> Key: SOLR-15127
> URL: https://issues.apache.org/jira/browse/SOLR-15127
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-15127.patch
>
>
> There was a recent dev@lucene discussion about the future of the
> github/docker-solr repo and (Apache) "official" solr docker images and using
> the "apache/solr" nameing vs (docker-library official) "_/solr" names...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAD4GwrNCPEnAJAjy4tY%3DpMeX5vWvnFyLe9ZDaXmF4J8XchA98Q%40mail.gmail.com%3E
> In that disussion, mak pointed out that docker-library evidently allows for
> some more flexibility in the way "official" docker-library packages can be
> built (compared to the rules that were evidnlty in place when the mak setup
> the current docker-solr image building process/tooling), pointing out how the
> "docker official" elasticsearch images are current built from the "elastic
> official" elasticsearch images...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3C3CED9683-1DD2-4F08-97F9-4FC549EDE47D%40greenhills.co.uk%3E
> Based on this, I proposed that we could probably restructure the Solr
> Dockerfile so that it could be useful for both "local development" -- using
> the current repo checkout -- as well as for "apache official" apache/solr
> images that could be reproducibly built directly from pristine git tags using
> the remote git URL syntax supported by "docker build" (and then -- evidently
> -- extended by trivial one line Dockerfiles for the "docker-library official"
> _/solr images)...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101221423340.16298%40slate%3E
> This jira tracks this idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-8319) NPE when creating pivot
[ https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276653#comment-17276653 ] Houston Putman commented on SOLR-8319: -- The query isn't coming from QParser.parse. Instead QueryBuilder.createFieldQuery is explicitly returning a null Query in a few code paths, such as when there are no tokens contained within a field search value. This is hit when a stopword is provided as a value. > NPE when creating pivot > --- > > Key: SOLR-8319 > URL: https://issues.apache.org/jira/browse/SOLR-8319 > Project: Solr > Issue Type: Bug >Reporter: Neil Ireson >Priority: Major > Attachments: SOLR-8319.patch > > Time Spent: 10m > Remaining Estimate: 0h > > I get a NPE, the trace is shown at the end. > The problem seems to be this line in the getSubset method: > Query query = ft.getFieldQuery(null, field, pivotValue); > Which takes a value from the index and then analyses it to create a query. I > believe the problem is that when my analysis process is applied twice it > results in a null query. OK this might be seen as my issue because of dodgy > analysis, I thought it might be because I have the wrong order with > LengthFilterFactory before EnglishPossessiveFilterFactory and > KStemFilterFactory, i.e.: > > > > So that "cat's" -> "cat" -> "", however any filter order I tried still > resulted in a NPE, and perhaps there is a viable case where parsing a term > twice results in a null query. > The thing is I don't see why when the query term comes from the index it has > to undergo any analysis. If the term is from the index can it not simply be > created using a TermQuery, which I would imagine would also be faster. I > altered the "getFieldQuery" line above to the following and that has fixed my > NPE issue. > Query query = new TermQuery(new Term(field.getName(), pivotValue)); > So far this hasn't caused any other issues but perhaps that is due to my use > of Solr, rather than actually fixing an issue. > o.a.s.c.SolrCore java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91) > at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130) > at > org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375) > at > org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at
[jira] [Commented] (SOLR-8319) NPE when creating pivot
[
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17275262#comment-17275262
]
Houston Putman commented on SOLR-8319:
--
The reason for the NPE on different values of {{facet.limit}} is because of
refinements. This logic is only called whenever refinements need to be made for
pivot facet results. Refinements are made because the first-pass in getting
facet results does not get exact results. It will ask for the top n terms from
each shard. If limit=n and the top n terms all have results from all shards,
then no refinement is needed, because the top n terms all have exact results.
If some of the top n terms are not included in some shard results, then
refinement requests have to be sent to those shards to get exact results.
When limit = -1, then no refinements are done because it asks for all results
from every shard.
When limit <= 3, then the stopword values are not close-enough to the top 3 to
need refinements.
When limit >= 4, then the stopwords are close enough to being selected for the
results that they need to be refined.
> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
> Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
> Attachments: SOLR-8319.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
> Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I
> believe the problem is that when my analysis process is applied twice it
> results in a null query. OK this might be seen as my issue because of dodgy
> analysis, I thought it might be because I have the wrong order with
> LengthFilterFactory before EnglishPossessiveFilterFactory and
> KStemFilterFactory, i.e.:
>
>
>
> So that "cat's" -> "cat" -> "", however any filter order I tried still
> resulted in a NPE, and perhaps there is a viable case where parsing a term
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has
> to undergo any analysis. If the term is from the index can it not simply be
> created using a TermQuery, which I would imagine would also be faster. I
> altered the "getFieldQuery" line above to the following and that has fixed my
> NPE issue.
> Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use
> of Solr, rather than actually fixing an issue.
> o.a.s.c.SolrCore java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.h
[jira] [Commented] (SOLR-8319) NPE when creating pivot
[
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17275256#comment-17275256
]
Houston Putman commented on SOLR-8319:
--
I have done just a bit of digging, but the reason why a null query is returned
is because the stop word itself contains no tokens, and [a query with no tokens
gets returned as
null|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/util/QueryBuilder.java#L343].
The default {{FieldType.getFieldQuery}} is not used, because
{{TextField.getFieldQuery}} overrides it. This is the method that eventually
(through other methods) calls the null-returning
{{QueryBuilder.createFieldQuery}}.
I agree that doing analyzation of a single token is not necessary and can
generally be skipped. I think it makes sense to add a method to {{FieldType}}
that does a non-analyzed field search. From what I can tell, this would only be
different from the {{FieldType.getFieldQuery}} implementation for
{{TextField}}. But going through and doing the changes, I noticed that there
was a TODO: in another place for this exact use case.
I think it would also be good to check for null, but I think this is a useful
method to have anyways. And after this change there shouldn't be a code path to
return null from that method. I'll put up a patch with my proposal.
> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
> Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
> Attachments: SOLR-8319.patch
>
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
> Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I
> believe the problem is that when my analysis process is applied twice it
> results in a null query. OK this might be seen as my issue because of dodgy
> analysis, I thought it might be because I have the wrong order with
> LengthFilterFactory before EnglishPossessiveFilterFactory and
> KStemFilterFactory, i.e.:
>
>
>
> So that "cat's" -> "cat" -> "", however any filter order I tried still
> resulted in a NPE, and perhaps there is a viable case where parsing a term
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has
> to undergo any analysis. If the term is from the index can it not simply be
> created using a TermQuery, which I would imagine would also be faster. I
> altered the "getFieldQuery" line above to the following and that has fixed my
> NPE issue.
> Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use
> of Solr, rather than actually fixing an issue.
> o.a.s.c.SolrCore java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.ecli
[jira] [Resolved] (SOLR-15075) Remove the Docker Gradle plugin dependency and solr/docker/package module
[ https://issues.apache.org/jira/browse/SOLR-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-15075. --- Fix Version/s: master (9.0) Assignee: Houston Putman Resolution: Fixed > Remove the Docker Gradle plugin dependency and solr/docker/package module > - > > Key: SOLR-15075 > URL: https://issues.apache.org/jira/browse/SOLR-15075 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker, Gradle >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Fix For: master (9.0) > > Time Spent: 4h > Remaining Estimate: 0h > > Currently Solr uses the [gradle docker > plugin|https://github.com/palantir/gradle-docker] to manage building Solr > docker images. When migrating the docker build into Solr, using the plugin > was the path of least resistance and allowed us to migrate without having to > think a lot about the gradle part. > Now that the docker image building works, it may be beneficial to migrate > away from the docker plugin, so that we can have better control over build > process. The steps are simple enough anyways, so we wouldn't be sacrificing > much to have more flexibility. > Given the discussion in the community over release vs local docker image > builds, there does not seem to be a desire to have separate builds for them. > Therefore we no longer need the solr/docker/package module. Instead the > solr/docker module will pull in the solr/packaging output and directly put it > into the docker image. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15102) Create release workflow for Solr docker images
Houston Putman created SOLR-15102: - Summary: Create release workflow for Solr docker images Key: SOLR-15102 URL: https://issues.apache.org/jira/browse/SOLR-15102 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: Docker Affects Versions: master (9.0) Reporter: Houston Putman Currently the official Solr docker images are built via the docker-solr repository. Starting with 9.0, Solr will be maintaining its own official docker image. Therefore we also need release steps for this. There are a few things that need to be done for this: * Decide how a release image should be built. * Decide how we will support Solr being an Official Docker Image * Make sure that compatibility between local images and official release images is maintained and verified * Add docker image release instructions to the release wizard -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269705#comment-17269705
]
Houston Putman commented on SOLR-13105:
---
RC1 just failed, so it should be easy to get this into RC2!
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14297) Remove apache commons-codec Base64 calls in favor of java 8 alternatives
[ https://issues.apache.org/jira/browse/SOLR-14297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14297: -- Fix Version/s: master (9.0) Resolution: Fixed Status: Resolved (was: Patch Available) Thanks for the contribution [~asalamon74]! > Remove apache commons-codec Base64 calls in favor of java 8 alternatives > > > Key: SOLR-14297 > URL: https://issues.apache.org/jira/browse/SOLR-14297 > Project: Solr > Issue Type: Improvement >Reporter: Andras Salamon >Assignee: Houston Putman >Priority: Minor > Fix For: master (9.0) > > Attachments: SOLR-14297-01.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Java8 has a builtin Base64 encoder and decoder, there is no need to use > commons-codec for this purpose. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14297) Remove apache commons-codec Base64 calls in favor of java 8 alternatives
[ https://issues.apache.org/jira/browse/SOLR-14297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman reassigned SOLR-14297: - Assignee: Houston Putman > Remove apache commons-codec Base64 calls in favor of java 8 alternatives > > > Key: SOLR-14297 > URL: https://issues.apache.org/jira/browse/SOLR-14297 > Project: Solr > Issue Type: Improvement >Reporter: Andras Salamon >Assignee: Houston Putman >Priority: Minor > Attachments: SOLR-14297-01.patch > > Time Spent: 50m > Remaining Estimate: 0h > > Java8 has a builtin Base64 encoder and decoder, there is no need to use > commons-codec for this purpose. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14297) Remove apache commons-codec Base64 calls in favor of java 8 alternatives
[ https://issues.apache.org/jira/browse/SOLR-14297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268868#comment-17268868 ] Houston Putman commented on SOLR-14297: --- There is a lot more usage of the Solr Commons Base64 class, so I would suggest tackling that in a separate ticket. > Remove apache commons-codec Base64 calls in favor of java 8 alternatives > > > Key: SOLR-14297 > URL: https://issues.apache.org/jira/browse/SOLR-14297 > Project: Solr > Issue Type: Improvement >Reporter: Andras Salamon >Priority: Minor > Attachments: SOLR-14297-01.patch > > Time Spent: 40m > Remaining Estimate: 0h > > Java8 has a builtin Base64 encoder and decoder, there is no need to use > commons-codec for this purpose. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12613) Rename "Cloud" tab as "Cluster" in Admin UI
[
https://issues.apache.org/jira/browse/SOLR-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268017#comment-17268017
]
Houston Putman commented on SOLR-12613:
---
Yeah, definitely misinterpreted the scope of this ticket. Thanks for clearing
that up Jan!
> Rename "Cloud" tab as "Cluster" in Admin UI
> ---
>
> Key: SOLR-12613
> URL: https://issues.apache.org/jira/browse/SOLR-12613
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
> Labels: newdev
> Fix For: 8.1, master (9.0)
>
>
> Spinoff from SOLR-8207. When adding more cluster-wide functionality to the
> Admin UI, it feels better to name the "Cloud" UI tab as "Cluster".
> In addition to renaming the "Cloud" tab, we should also change the URL part
> from {{~cloud}} to {{~cluster}}, update reference guide page names,
> screenshots and references etc.
> I propose this change is not introduced in 7.x due to the impact, so tagged
> it as fix-version 8.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15075) Remove the Docker Gradle plugin dependency and solr/docker/package module
[ https://issues.apache.org/jira/browse/SOLR-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-15075: -- Description: Currently Solr uses the [gradle docker plugin|https://github.com/palantir/gradle-docker] to manage building Solr docker images. When migrating the docker build into Solr, using the plugin was the path of least resistance and allowed us to migrate without having to think a lot about the gradle part. Now that the docker image building works, it may be beneficial to migrate away from the docker plugin, so that we can have better control over build process. The steps are simple enough anyways, so we wouldn't be sacrificing much to have more flexibility. Given the discussion in the community over release vs local docker image builds, there does not seem to be a desire to have separate builds for them. Therefore we no longer need the solr/docker/package module. Instead the solr/docker module will pull in the solr/packaging output and directly put it into the docker image. was: Currently Solr uses the [gradle docker plugin|https://github.com/palantir/gradle-docker] to manage building Solr docker images. When migrating the docker build into Solr, using the plugin was the path of least resistance and allowed us to migrate without having to think a lot about the gradle part. Now that the docker image building works, it may be beneficial to migrate away from the docker plugin, so that we can have better control over build process. The steps are simple enough anyways, so we wouldn't be sacrificing much to have more flexibility. Summary: Remove the Docker Gradle plugin dependency and solr/docker/package module (was: Remove the Docker Gradle plugin dependency) > Remove the Docker Gradle plugin dependency and solr/docker/package module > - > > Key: SOLR-15075 > URL: https://issues.apache.org/jira/browse/SOLR-15075 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker, Gradle >Affects Versions: master (9.0) >Reporter: Houston Putman >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently Solr uses the [gradle docker > plugin|https://github.com/palantir/gradle-docker] to manage building Solr > docker images. When migrating the docker build into Solr, using the plugin > was the path of least resistance and allowed us to migrate without having to > think a lot about the gradle part. > Now that the docker image building works, it may be beneficial to migrate > away from the docker plugin, so that we can have better control over build > process. The steps are simple enough anyways, so we wouldn't be sacrificing > much to have more flexibility. > Given the discussion in the community over release vs local docker image > builds, there does not seem to be a desire to have separate builds for them. > Therefore we no longer need the solr/docker/package module. Instead the > solr/docker module will pull in the solr/packaging output and directly put it > into the docker image. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12613) Rename "Cloud" tab as "Cluster" in Admin UI
[
https://issues.apache.org/jira/browse/SOLR-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17266246#comment-17266246
]
Houston Putman commented on SOLR-12613:
---
I feel like if you are going to change "SolrCloud mode" in the reference guide,
it should change everywhere. A major version (aka 9) is a good time to get that
done.
> Rename "Cloud" tab as "Cluster" in Admin UI
> ---
>
> Key: SOLR-12613
> URL: https://issues.apache.org/jira/browse/SOLR-12613
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
> Labels: newdev
> Fix For: 8.1, master (9.0)
>
>
> Spinoff from SOLR-8207. When adding more cluster-wide functionality to the
> Admin UI, it feels better to name the "Cloud" UI tab as "Cluster".
> In addition to renaming the "Cloud" tab, we should also change the URL part
> from {{~cloud}} to {{~cluster}}, update reference guide page names,
> screenshots and references etc.
> I propose this change is not introduced in 7.x due to the impact, so tagged
> it as fix-version 8.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14216) Exclude HealthCheck from authentication
[
https://issues.apache.org/jira/browse/SOLR-14216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17263651#comment-17263651
]
Houston Putman commented on SOLR-14216:
---
I think this makes a lot of sense. It'd be ok to make this configurable, but I
think the option should absolutely be there to remove auth from the health
check handler.
[~janhoy] I see that you deleted your PR. Are you no longer interested in the
feature or did you just delete it because it was stale?
> Exclude HealthCheck from authentication
> ---
>
> Key: SOLR-14216
> URL: https://issues.apache.org/jira/browse/SOLR-14216
> Project: Solr
> Issue Type: Improvement
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{HealthCheckHandler}} on {{/api/node/health}} and
> {{/solr/admin/info/health}} should by default not be subject to
> authentication, but be open for all. This allows for load balancers and
> various monitoring to probe Solr's health without having to support the auth
> scheme in place. I can't see any reason we need auth on the health endpoint.
> It is possible to achieve the same by setting blockUnknown=false and
> configuring three RBAC permissions: One for v1 endpoint, one for v2 endpoint
> and one "all" catch all at the end of the chain. But this is cumbersome so
> better have this ootb.
> An alternative solution is to create a separate HttpServer for health check,
> listening on a different port, just like embedded ZK and JMX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14999.
---
Resolution: Fixed
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17261882#comment-17261882
]
Houston Putman commented on SOLR-14999:
---
Thanks for finding that. I'll work on a fix.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14999.
---
Fix Version/s: 8.8
Resolution: Fixed
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus
[ https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17261439#comment-17261439 ] Houston Putman commented on SOLR-11795: --- I agree that co-existing would be the best course of action. The prometheus exporter is a wonderful tool to collect cluster-level metrics. However, having node-level metrics surfaced via one endpoint can limit their usefulness. Many cloud platforms offer autoscaling, by watching metrics for each individual instance. We can't really use these easily without providing Prometheus endpoints for each individual node. I think the split also makes it easier for users to specify what metrics they want, as well as consume their metrics. And given the number of service discovery mechanisms that Prometheus has, I don't think it will be a large burden on users to scrape the exporter as well as all individual Solr nodes. > Add Solr metrics exporter for Prometheus > > > Key: SOLR-11795 > URL: https://issues.apache.org/jira/browse/SOLR-11795 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter, metrics >Affects Versions: 7.2 >Reporter: Minoru Osuka >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 7.3, 8.0 > > Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, > SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, > SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, > SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, > SOLR-11795-doc.patch, SOLR-11795-ref-guide.patch, SOLR-11795.patch, > solr-dashboard.png, solr-exporter-diagram.png > > Time Spent: 20m > Remaining Estimate: 0h > > I 'd like to monitor Solr using Prometheus and Grafana. > I've already created Solr metrics exporter for Prometheus. I'd like to > contribute to contrib directory if you don't mind. > !solr-exporter-diagram.png|thumbnail! > !solr-dashboard.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260828#comment-17260828
]
Houston Putman commented on SOLR-13105:
---
I agree it would be great if we could put .adoc files in a hierarchy. As long
as it isn't too much work to maintain or switch to.
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15075) Remove the Docker Gradle plugin dependency
Houston Putman created SOLR-15075: - Summary: Remove the Docker Gradle plugin dependency Key: SOLR-15075 URL: https://issues.apache.org/jira/browse/SOLR-15075 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Gradle, Docker Affects Versions: master (9.0) Reporter: Houston Putman Currently Solr uses the [gradle docker plugin|https://github.com/palantir/gradle-docker] to manage building Solr docker images. When migrating the docker build into Solr, using the plugin was the path of least resistance and allowed us to migrate without having to think a lot about the gradle part. Now that the docker image building works, it may be beneficial to migrate away from the docker plugin, so that we can have better control over build process. The steps are simple enough anyways, so we wouldn't be sacrificing much to have more flexibility. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259834#comment-17259834
]
Houston Putman commented on SOLR-14999:
---
So we can't "deprecate" jetty.port really, since it's a variable used in the
Jetty XML. This would be possible if Solr owned the setup of Jetty, but there
is no way of putting multiple variables to read from in the jetty xml. (Aka,
use solr.port.listen -> solr.port -> jetty.port -> 8983, in that order). This
is a SIP already, SOLR-14361.
We could also have bin/solr do some smart renaming of variables, but not
everyone uses bin/solr.
Is "solr.port.listen" something we are ok punting on until later, or should we
wait to make the "solr.port.advertise" until we can make both changes? We could
also decide to make "solr.port.listen" a 9.0 thing, and make it explicitly
clear to everyone that the name has changed in the major version and they need
to use the new system property if they are not using bin/solr.
Personally, I think that "solr.port.advertise" is useful-enough on its own to
put into 8.8, and we can decide on how we want to change "jetty.port" to
"solr.port.listen" in the future.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9564) Format code automatically and enforce it
[ https://issues.apache.org/jira/browse/LUCENE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247684#comment-17247684 ] Houston Putman commented on LUCENE-9564: +1, I think this is a terrific idea! Golang has a formatter built into the language, so many Go projects will require the formatting to be correct in order to merge. I have many gripes with the language, but this something they got 100% right. It is so nice to have consistent code and not have to worry about maintaining it. > Format code automatically and enforce it > > > Key: LUCENE-9564 > URL: https://issues.apache.org/jira/browse/LUCENE-9564 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Time Spent: 2h 20m > Remaining Estimate: 0h > > This is a trivial change but a bold move. And I'm sure it's not for everyone. > I started using google java format [1] in my projects a while ago and have > never looked back since. It is an oracle-style formatter (doesn't allow > customizations or deviations from the defined 'ideal') - this takes some > getting used to - but it also eliminates *all* the potential differences > between IDEs, configs, etc. And the formatted code typically looks much > better than hand-edited one. It is also verifiable on precommit (so you can't > commit code that deviates from what you'd get from automated formatting > output). > The biggest benefit I see is that refactorings become such a joy and keep the > code neat, everywhere. Before you commit you just reformat everything > automatically, no matter how much you messed it up. > This isn't a change for everyone. I myself love hand-edited, neat code... but > the reality is that with IDE support for automated code changes and so many > people with different styles working on the same codebase keeping it neat is > a big pain. > Checkstyle and other tools are fine for ensuring certain rules but they don't > take the burden of formatting off your shoulders. This tool does. > Like I said - I had *great* reservations about using it at the beginning but > over time got so used to it that I almost can't live without it now. It's > like magic - you play with the code in any way you like, then run formatting > and it's nice and neat. > The downside is that automated formatting does imply potential merge problems > in backward patches (or any currently existing branches). > Like I said, it is a bold move. Just throwing this for your consideration. > -I've added a PR that adds spotless but it's not ready; some files would have > to be excluded as they currently violate header rules.- > A more interesting thing is here where the current code is automatically > reformatted - this branch is for eyeballing only. > https://github.com/dweiss/lucene-solr/compare/LUCENE-9564...dweiss:LUCENE-9564-example > [1] https://google.github.io/styleguide/javaguide.html -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235711#comment-17235711 ] Houston Putman commented on SOLR-6733: -- Is there still interest in this idea? If so, I'd volunteer to help take it forward. > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235050#comment-17235050
]
Houston Putman commented on SOLR-14999:
---
+1 I'm a fan of that idea. It might be difficult doing this multi-level
defaulting in the jetty config. But I haven't looked at that yet. Will
investigate
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14999:
--
Description:
Currently the default settings in {{solr.xml}} allow the specification of one
port, {{jetty.port}} which the bin/solr script provides from the {{SOLR_PORT}}
environment variable. This port is used twice. Jetty uses it to listen for
requests, and the clusterState uses the port to advertise the address of the
Solr Node.
In cloud environments, it's sometimes crucial to be able to listen on one port
and advertise yourself as listening on another. This is because there is a
proxy that listens on the advertised port, and forwards the request to the
server which is listening to the jetty port.
Solr already supports having a separate Jetty port and Live Nodes port
(examples provided in the dev-list discussion linked below). I suggest that we
add this to the default solr config so that users can use the default solr.xml
in cloud configurations, and the solr/bin script will enable easy use of this
feature.
There has been [discussion on this exact
problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
on the dev list already.
I propose the new system property to be used for {{hostPort}} in the solr.xml.
I am open to changing the name, but to me it is more descriptive than
{{hostPort}}.
{{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
bin/solr).
The xml field {{}} would not be changed however, just the system
property that is used to fill the value in the default {{solr.xml}}.
was:
Currently the default settings in {{solr.xml}} allow the specification of one
port, {{jetty.port}} which the bin/solr script provides from the {{SOLR_PORT}}
environment variable. This port is used twice. Jetty uses it to listen for
requests, and the clusterState uses the port to advertise the address of the
Solr Node.
In cloud environments, it's sometimes crucial to be able to listen on one port
and advertise yourself as listening on another. This is because there is a
proxy that listens on the advertised port, and forwards the request to the
server which is listening to the jetty port.
Solr already supports having a separate Jetty port and Live Nodes port
(examples provided in the dev-list discussion linked below). I suggest that we
add this to the default solr config so that users can use the default solr.xml
in cloud configurations, and the solr/bin script will enable easy use of this
feature.
There has been [discussion on this exact
problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
on the dev list already.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> --
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
[jira] [Created] (SOLR-14999) Add built-in option to advertise Solr with a different port than Jetty listens on.
Houston Putman created SOLR-14999:
-
Summary: Add built-in option to advertise Solr with a different
port than Jetty listens on.
Key: SOLR-14999
URL: https://issues.apache.org/jira/browse/SOLR-14999
Project: Solr
Issue Type: Improvement
Reporter: Houston Putman
Assignee: Houston Putman
Currently the default settings in {{solr.xml}} allow the specification of one
port, {{jetty.port}} which the bin/solr script provides from the {{SOLR_PORT}}
environment variable. This port is used twice. Jetty uses it to listen for
requests, and the clusterState uses the port to advertise the address of the
Solr Node.
In cloud environments, it's sometimes crucial to be able to listen on one port
and advertise yourself as listening on another. This is because there is a
proxy that listens on the advertised port, and forwards the request to the
server which is listening to the jetty port.
Solr already supports having a separate Jetty port and Live Nodes port
(examples provided in the dev-list discussion linked below). I suggest that we
add this to the default solr config so that users can use the default solr.xml
in cloud configurations, and the solr/bin script will enable easy use of this
feature.
There has been [discussion on this exact
problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
on the dev list already.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14949) Ability to customize docker image name/base image
[
https://issues.apache.org/jira/browse/SOLR-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14949:
--
Description:
The current docker build will generate an image with the name
{{apache/solr:}}. If users want to build custom images and push them
to their own docker orgs, then this should be more customizable.
The following inputs should be customizable in the first pass at least:
* Docker Image Repo - default "apache/solr"
* Docker Image Tag - default to the project version
* Docker Image Name (This will set the entire thing, overriding the previous
two options) - Defaults to ":"
* Base Docker Image (This is the docker image that Solr Builds itself on top
of) - Defaults to "openjdk:11-jre-slim"
* Github URL ("github.com" or a mirror for github releases. This allows for
building the solr docker image behind a firewall that does not have access to
github.com)
All will be optional.
was:
The current docker build will generate an image with the name
{{apache/solr:}}. If users want to build custom images and push them
to their own docker orgs, then this should be more customizable.
The following inputs should be customizable in the first pass at least:
* Docker Image Repo - default "apache/solr"
* Docker Image Tag - default to the project version
* Docker Image Name (This will set the entire thing, overriding the previous
two options) - Defaults to ":"
* Base Docker Image (This is the docker image that Solr Builds itself on top
of) - Defaults to "openjdk:11-jre-slim"
All will be optional.
> Ability to customize docker image name/base image
> -
>
> Key: SOLR-14949
> URL: https://issues.apache.org/jira/browse/SOLR-14949
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The current docker build will generate an image with the name
> {{apache/solr:}}. If users want to build custom images and push them
> to their own docker orgs, then this should be more customizable.
> The following inputs should be customizable in the first pass at least:
> * Docker Image Repo - default "apache/solr"
> * Docker Image Tag - default to the project version
> * Docker Image Name (This will set the entire thing, overriding the previous
> two options) - Defaults to ":"
> * Base Docker Image (This is the docker image that Solr Builds itself on top
> of) - Defaults to "openjdk:11-jre-slim"
> * Github URL ("github.com" or a mirror for github releases. This allows for
> building the solr docker image behind a firewall that does not have access to
> github.com)
> All will be optional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14949) Ability to customize docker image name/base image
[
https://issues.apache.org/jira/browse/SOLR-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14949.
---
Fix Version/s: master (9.0)
Resolution: Fixed
> Ability to customize docker image name/base image
> -
>
> Key: SOLR-14949
> URL: https://issues.apache.org/jira/browse/SOLR-14949
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The current docker build will generate an image with the name
> {{apache/solr:}}. If users want to build custom images and push them
> to their own docker orgs, then this should be more customizable.
> The following inputs should be customizable in the first pass at least:
> * Docker Image Repo - default "apache/solr"
> * Docker Image Tag - default to the project version
> * Docker Image Name (This will set the entire thing, overriding the previous
> two options) - Defaults to ":"
> * Base Docker Image (This is the docker image that Solr Builds itself on top
> of) - Defaults to "openjdk:11-jre-slim"
> All will be optional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11767) Please create SolrCloud Helm Chart or Controller for Kubernetes
[ https://issues.apache.org/jira/browse/SOLR-11767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-11767. --- Resolution: Done The [Solr Operator|https://github.com/bloomberg/solr-operator] is being adopted by the Apache Lucene project. > Please create SolrCloud Helm Chart or Controller for Kubernetes > --- > > Key: SOLR-11767 > URL: https://issues.apache.org/jira/browse/SOLR-11767 > Project: Solr > Issue Type: Improvement > Components: AutoScaling >Affects Versions: 7.1 > Environment: Azure AKS, On-Prem Kuberenetes 1.8 >Reporter: Rodney Aaron Stainback >Priority: Major > Original Estimate: 168h > Remaining Estimate: 168h > > Please creates a highly avialable auto-scaling Kubernetes Helm Chart or > Controller/Custom Resource for easy deployment of SolrCloud in Kubernetes in > any environement. Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14907.
---
Fix Version/s: 8.8
Resolution: Fixed
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7, 8.8
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> {code}
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> {code}
> V2:
> * Uploading a configSet:
> {code} PUT - /api/cluster/configs/{name}{code}
> * Uploading a file in a configSet:
> {code} PUT - /api/cluster/configs/{name}/{filename}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14955) Add env var options for the Prometheus Exporter bin scripts
[ https://issues.apache.org/jira/browse/SOLR-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-14955. --- Fix Version/s: 8.8 Resolution: Fixed > Add env var options for the Prometheus Exporter bin scripts > --- > > Key: SOLR-14955 > URL: https://issues.apache.org/jira/browse/SOLR-14955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - prometheus-exporter >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Fix For: 8.8 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The prometheus exporter bin scripts get the job done, but are quite lean and > don't provide a large amount of help in setting up the exporter. > A list of things that could be improved: > * Allowing users to pass [command line > options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] > through environment variables > * Support the ZK ACL environment variables > * Similar memory options to solr/bin/solr > These are just a few ideas, but a little work would go a long way here. > Previous discussion: > * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] > * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14955) Add env var options for the Prometheus Exporter bin scripts
[ https://issues.apache.org/jira/browse/SOLR-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman reassigned SOLR-14955: - Assignee: Houston Putman > Add env var options for the Prometheus Exporter bin scripts > --- > > Key: SOLR-14955 > URL: https://issues.apache.org/jira/browse/SOLR-14955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - prometheus-exporter >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > > The prometheus exporter bin scripts get the job done, but are quite lean and > don't provide a large amount of help in setting up the exporter. > A list of things that could be improved: > * Allowing users to pass [command line > options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] > through environment variables > * Support the ZK ACL environment variables > * Similar memory options to solr/bin/solr > These are just a few ideas, but a little work would go a long way here. > Previous discussion: > * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] > * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14957) Add Prometheus Exporter bin to PATH in docker image
[
https://issues.apache.org/jira/browse/SOLR-14957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14957.
---
Fix Version/s: master (9.0)
Resolution: Fixed
> Add Prometheus Exporter bin to PATH in docker image
> ---
>
> Key: SOLR-14957
> URL: https://issues.apache.org/jira/browse/SOLR-14957
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - prometheus-exporter, Docker
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently the Solr docker image contains the prometheus exporter script
> {{bin/solr-exporter}}, and this script is executable. Therefore the
> prometheus exporter _can_ be run via the Solr docker image.
> However the user has to know the location of this script when trying to run
> the prometheus-exporter. It would be best if the {{prometheus-exporter/bin}}
> were added to the PATH, so that the prometheus exporter could be run through
> the following:
> {code:bash}
> docker run solr solr-exporter -b http://host.docker.internal:8983/solr
> {code}
> Discussion at
> [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14947) Gradle docker build task should output image id or tag
[
https://issues.apache.org/jira/browse/SOLR-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219105#comment-17219105
]
Houston Putman commented on SOLR-14947:
---
Unfortunately it does not seem possible to get the image id from the docker
task.
> Gradle docker build task should output image id or tag
> --
>
> Key: SOLR-14947
> URL: https://issues.apache.org/jira/browse/SOLR-14947
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Houston Putman
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When calling {{./gradlew docker}} it build the image, but I have no idea what
> it's called so that I can run it.
> When I run with {{--info}} I get the requested output, but also a lot of
> other stuff.
> {code}
> Successfully built 02d86c5c7357
> Successfully tagged apache/solr:9.0.0-SNAPSHOT
> :solr:docker:docker (Thread[Execution worker for ':' Thread 11,5,main])
> completed. Took 0.172 secs.
> {code}
> We could put some of that in a {{doLast}} block, similar to
> https://github.com/apache/lucene-solr/blob/master/gradle/releasing.gradle#L51
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14947) Gradle docker build task should output image id or tag
[
https://issues.apache.org/jira/browse/SOLR-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14947.
---
Fix Version/s: master (9.0)
Resolution: Done
> Gradle docker build task should output image id or tag
> --
>
> Key: SOLR-14947
> URL: https://issues.apache.org/jira/browse/SOLR-14947
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Houston Putman
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When calling {{./gradlew docker}} it build the image, but I have no idea what
> it's called so that I can run it.
> When I run with {{--info}} I get the requested output, but also a lot of
> other stuff.
> {code}
> Successfully built 02d86c5c7357
> Successfully tagged apache/solr:9.0.0-SNAPSHOT
> :solr:docker:docker (Thread[Execution worker for ':' Thread 11,5,main])
> completed. Took 0.172 secs.
> {code}
> We could put some of that in a {{doLast}} block, similar to
> https://github.com/apache/lucene-solr/blob/master/gradle/releasing.gradle#L51
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14957) Add Prometheus Exporter bin to PATH in docker image
[
https://issues.apache.org/jira/browse/SOLR-14957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14957:
--
Description:
Currently the Solr docker image contains the prometheus exporter script
{{bin/solr-exporter}}, and this script is executable. Therefore the prometheus
exporter _can_ be run via the Solr docker image.
However the user has to know the location of this script when trying to run the
prometheus-exporter. It would be best if the {{prometheus-exporter/bin}} were
added to the PATH, so that the prometheus exporter could be run through the
following:
{code:bash}
docker run solr solr-exporter -b http://host.docker.internal:8983/solr
{code}
Discussion at
[docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307]
was:
Currently the Solr docker image contains the prometheus exporter script
{{bin/solr-exporter}}, and this script is executable. Therefore the prometheus
exporter _can_ be run via the Solr docker image.
However the user has to know the location of this script when trying to run the
prometheus-exporter. It would be best if the {{prometheus-exporter/bin}} were
added to the PATH, so that the prometheus exporter could be run through the
following:
{code:bash}
docker run solr solr-exporter -b http://host.docker.internal:8983/solr
{code}
> Add Prometheus Exporter bin to PATH in docker image
> ---
>
> Key: SOLR-14957
> URL: https://issues.apache.org/jira/browse/SOLR-14957
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - prometheus-exporter, Docker
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
>
> Currently the Solr docker image contains the prometheus exporter script
> {{bin/solr-exporter}}, and this script is executable. Therefore the
> prometheus exporter _can_ be run via the Solr docker image.
> However the user has to know the location of this script when trying to run
> the prometheus-exporter. It would be best if the {{prometheus-exporter/bin}}
> were added to the PATH, so that the prometheus exporter could be run through
> the following:
> {code:bash}
> docker run solr solr-exporter -b http://host.docker.internal:8983/solr
> {code}
> Discussion at
> [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14957) Add Prometheus Exporter bin to PATH in docker image
Houston Putman created SOLR-14957:
-
Summary: Add Prometheus Exporter bin to PATH in docker image
Key: SOLR-14957
URL: https://issues.apache.org/jira/browse/SOLR-14957
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: contrib - prometheus-exporter, Docker
Affects Versions: master (9.0)
Reporter: Houston Putman
Assignee: Houston Putman
Currently the Solr docker image contains the prometheus exporter script
{{bin/solr-exporter}}, and this script is executable. Therefore the prometheus
exporter _can_ be run via the Solr docker image.
However the user has to know the location of this script when trying to run the
prometheus-exporter. It would be best if the {{prometheus-exporter/bin}} were
added to the PATH, so that the prometheus exporter could be run through the
following:
{code:bash}
docker run solr solr-exporter -b http://host.docker.internal:8983/solr
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14955) Add env var options for the Prometheus Exporter bin scripts
[ https://issues.apache.org/jira/browse/SOLR-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14955: -- Description: The prometheus exporter bin scripts get the job done, but are quite lean and don't provide a large amount of help in setting up the exporter. A list of things that could be improved: * Allowing users to pass [command line options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] through environment variables * Support the ZK ACL environment variables * Similar memory options to solr/bin/solr These are just a few ideas, but a little work would go a long way here. Previous discussion: * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] was: The prometheus exporter bin scripts get the job done, but are quite lean and don't provide a large amount of help in setting up the exporter. A list of things that could be improved: * Allowing users to pass [command line options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] through environment variables * Support the ZK ACL environment variables * Similar memory options to solr/bin/solr These are just a few ideas, but there is a large difference between the user experience of bin/solr and bin/prometheus-exporter. A little work would go a long way here. Previous discussion: * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] > Add env var options for the Prometheus Exporter bin scripts > --- > > Key: SOLR-14955 > URL: https://issues.apache.org/jira/browse/SOLR-14955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - prometheus-exporter >Reporter: Houston Putman >Priority: Major > > The prometheus exporter bin scripts get the job done, but are quite lean and > don't provide a large amount of help in setting up the exporter. > A list of things that could be improved: > * Allowing users to pass [command line > options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] > through environment variables > * Support the ZK ACL environment variables > * Similar memory options to solr/bin/solr > These are just a few ideas, but a little work would go a long way here. > Previous discussion: > * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] > * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14955) Add env var options for the Prometheus Exporter bin scripts
[ https://issues.apache.org/jira/browse/SOLR-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14955: -- Summary: Add env var options for the Prometheus Exporter bin scripts (was: Improve the Prometheus Exporter bin scripts) > Add env var options for the Prometheus Exporter bin scripts > --- > > Key: SOLR-14955 > URL: https://issues.apache.org/jira/browse/SOLR-14955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - prometheus-exporter >Reporter: Houston Putman >Priority: Major > > The prometheus exporter bin scripts get the job done, but are quite lean and > don't provide a large amount of help in setting up the exporter. > A list of things that could be improved: > * Allowing users to pass [command line > options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] > through environment variables > * Support the ZK ACL environment variables > * Similar memory options to solr/bin/solr > These are just a few ideas, but there is a large difference between the user > experience of bin/solr and bin/prometheus-exporter. A little work would go a > long way here. > Previous discussion: > * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] > * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14955) Improve the Prometheus Exporter bin scripts
Houston Putman created SOLR-14955: - Summary: Improve the Prometheus Exporter bin scripts Key: SOLR-14955 URL: https://issues.apache.org/jira/browse/SOLR-14955 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: contrib - prometheus-exporter Reporter: Houston Putman The prometheus exporter bin scripts get the job done, but are quite lean and don't provide a large amount of help in setting up the exporter. A list of things that could be improved: * Allowing users to pass [command line options|https://lucene.apache.org/solr/guide/8_6/monitoring-solr-with-prometheus-and-grafana.html#command-line-parameters] through environment variables * Support the ZK ACL environment variables * Similar memory options to solr/bin/solr These are just a few ideas, but there is a large difference between the user experience of bin/solr and bin/prometheus-exporter. A little work would go a long way here. Previous discussion: * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14953) Create an individual Docker image for the Prometheus Exporter
Houston Putman created SOLR-14953: - Summary: Create an individual Docker image for the Prometheus Exporter Key: SOLR-14953 URL: https://issues.apache.org/jira/browse/SOLR-14953 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: contrib - prometheus-exporter, Docker Affects Versions: master (9.0) Reporter: Houston Putman Currently the prometheus exporter is packaged within the overall Solr Docker image. While this is useful, it doesn't provide the best experience for users. If used to run the Prometheus Exporter, the Solr docker image contains mostly irrelevant things which add considerable complexity and size to the image. With a separate image, we could provide a better more intuitive user experience that is actually optimized for running the prometheus exporter, and be considerably slimmer than the Solr image. Previous discussions: * SOLR-14915 * [docker-solr#307|https://github.com/docker-solr/docker-solr/issues/307] * [docker-solr#224|https://github.com/docker-solr/docker-solr/pull/224] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14907:
--
Description:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Uploading a configSet:
** PUT - /cluster/configs/\{name}
* Uploading a file in a configSet:
** PUT - /cluster/configs/\{name}/\{filename}
was:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Uploading a configSet:
** PUT - /cluster/configs/\{name}
* Uploading a file in a configSet:
** PUT - /cluster/configs/\{name}/files/\{filename}
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> V2:
> * Uploading a configSet:
> ** PUT - /cluster/configs/\{name}
> * Uploading a file in a configSet:
> ** PUT - /cluster/configs/\{name}/\{filename}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14949) Ability to customize docker image name/base image
Houston Putman created SOLR-14949:
-
Summary: Ability to customize docker image name/base image
Key: SOLR-14949
URL: https://issues.apache.org/jira/browse/SOLR-14949
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: Docker
Affects Versions: master (9.0)
Reporter: Houston Putman
Assignee: Houston Putman
The current docker build will generate an image with the name
{{apache/solr:}}. If users want to build custom images and push them
to their own docker orgs, then this should be more customizable.
The following inputs should be customizable in the first pass at least:
* Docker Image Repo - default "apache/solr"
* Docker Image Tag - default to the project version
* Docker Image Name (This will set the entire thing, overriding the previous
two options) - Defaults to ":"
* Base Docker Image (This is the docker image that Solr Builds itself on top
of) - Defaults to "openjdk:11-jre-slim"
All will be optional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14947) Gradle docker build task should output image id or tag
[
https://issues.apache.org/jira/browse/SOLR-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217035#comment-17217035
]
Houston Putman commented on SOLR-14947:
---
Created a PR that outputs the following after a successful build of {{./gradlew
docker}}
{code:java}
Solr Docker Image Created
Name: apache/solr:9.0.0-SNAPSHOT
Base Image: openjdk:11-jre-slim{code}
> Gradle docker build task should output image id or tag
> --
>
> Key: SOLR-14947
> URL: https://issues.apache.org/jira/browse/SOLR-14947
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Houston Putman
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When calling {{./gradlew docker}} it build the image, but I have no idea what
> it's called so that I can run it.
> When I run with {{--info}} I get the requested output, but also a lot of
> other stuff.
> {code}
> Successfully built 02d86c5c7357
> Successfully tagged apache/solr:9.0.0-SNAPSHOT
> :solr:docker:docker (Thread[Execution worker for ':' Thread 11,5,main])
> completed. Took 0.172 secs.
> {code}
> We could put some of that in a {{doLast}} block, similar to
> https://github.com/apache/lucene-solr/blob/master/gradle/releasing.gradle#L51
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14907:
--
Description:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Uploading a configSet:
** PUT - /cluster/configs/\{name}
* Uploading a file in a configSet:
** PUT - /cluster/configs/\{name}/files/\{filename}
was:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Creating a configSet:
** POST - /cluster/configs/\{name}
* Updating a configSet:
** PUT - /cluster/configs/\{name}
* Creating a file in a configSet:
** POST - /cluster/configs/\{name}/files/\{filename}
* Updating a file in a configSet:
** PUT - /cluster/configs/\{name}/files/\{filename}
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> V2:
> * Uploading a configSet:
> ** PUT - /cluster/configs/\{name}
> * Uploading a file in a configSet:
> ** PUT - /cluster/configs/\{name}/files/\{filename}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216997#comment-17216997
]
Houston Putman commented on SOLR-14907:
---
bq. I suppose you are trying to map overwrite=true/false to the restful action
Yeah that's the idea.
After reading through that though, I think you are right that PUT works best
overall for both create & update. And users can override the "overwrite=false"
if they so desire. Slightly awkward that the default behavior is different
between v1 and v2, but it does make the most since with the REST API.
I'll make those changes real quick.
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> V2:
> * Creating a configSet:
> ** POST - /cluster/configs/\{name}
> * Updating a configSet:
> ** PUT - /cluster/configs/\{name}
> * Creating a file in a configSet:
> ** POST - /cluster/configs/\{name}/files/\{filename}
> * Updating a file in a configSet:
> ** PUT - /cluster/configs/\{name}/files/\{filename}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14877) Add github PR Action for running SolrJ tests
[ https://issues.apache.org/jira/browse/SOLR-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-14877. --- Resolution: Implemented > Add github PR Action for running SolrJ tests > > > Key: SOLR-14877 > URL: https://issues.apache.org/jira/browse/SOLR-14877 > Project: Solr > Issue Type: Test > Components: github, SolrJ, Tests >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > The gradle tests would only be run if the code within SolrJ is changed by the > PR. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14907:
--
Description:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Creating a configSet:
** POST - /cluster/configs/\{name}
* Updating a configSet:
** PUT - /cluster/configs/\{name}
* Creating a file in a configSet:
** POST - /cluster/configs/\{name}/files/\{filename}
* Updating a file in a configSet:
** PUT - /cluster/configs/\{name}/files/\{filename}
was:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Creating a configSet:
** POST - /cluster/configs/\{name}
* Updating a configSet:
** PUT - /cluster/configs/\{name}
* Creating a file in a configSet:
** POST - /cluster/configs/\{name}/file/\{filename}
* Updating a file in a configSet:
** PUT - /cluster/configs/\{name}/file/\{filename}
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> V2:
> * Creating a configSet:
> ** POST - /cluster/configs/\{name}
> * Updating a configSet:
> ** PUT - /cluster/configs/\{name}
> * Creating a file in a configSet:
> ** POST - /cluster/configs/\{name}/files/\{filename}
> * Updating a file in a configSet:
> ** PUT - /cluster/configs/\{name}/files/\{filename}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216784#comment-17216784
]
Houston Putman commented on SOLR-14907:
---
Added the proposed APIs in the Jira description. Good call on the
[~noble.paul], I should have included it from the start.
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> V2:
> * Creating a configSet:
> ** POST - /cluster/configs/\{name}
> * Updating a configSet:
> ** PUT - /cluster/configs/\{name}
> * Creating a file in a configSet:
> ** POST - /cluster/configs/\{name}/file/\{filename}
> * Updating a file in a configSet:
> ** PUT - /cluster/configs/\{name}/file/\{filename}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-14907:
--
Description:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
The following APIs are being proposed:
V1:
Adding to the configSet upload one urlParam, filePath:
"http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
V2:
* Creating a configSet:
** POST - /cluster/configs/\{name}
* Updating a configSet:
** PUT - /cluster/configs/\{name}
* Creating a file in a configSet:
** POST - /cluster/configs/\{name}/file/\{filename}
* Updating a file in a configSet:
** PUT - /cluster/configs/\{name}/file/\{filename}
was:
After SOLR-10391 was implemented, users are now able to overwrite existing
configSets using the configSet API. However the files uploaded are still
required to be zipped and indexed from the base configSet path in ZK. Users
might want to just update a single file, such as a synonyms list, and not have
to tar it up first.
The proposed solution is to add parameters to the UPLOAD configSet action, to
allow this single-file use case. This would utilize the protections already
provided by the API, such as maintaining the trustiness of configSets being
modified.
This feature is part of the solution to replace managed resources, which is
planned to be deprecated and removed by 9.0 (SOLR-14766).
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet&filePath=solrconfig.xml&overwrite=true";
> V2:
> * Creating a configSet:
> ** POST - /cluster/configs/\{name}
> * Updating a configSet:
> ** PUT - /cluster/configs/\{name}
> * Creating a file in a configSet:
> ** POST - /cluster/configs/\{name}/file/\{filename}
> * Updating a file in a configSet:
> ** PUT - /cluster/configs/\{name}/file/\{filename}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14907) Support single file upload/overwrite in configSet API
[ https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215516#comment-17215516 ] Houston Putman commented on SOLR-14907: --- Working on a PR today, will likely incorporate v2 APIs for regular upload as well. Might as well since it's basically the same code. > Support single file upload/overwrite in configSet API > - > > Key: SOLR-14907 > URL: https://issues.apache.org/jira/browse/SOLR-14907 > Project: Solr > Issue Type: Improvement > Components: configset-api >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Fix For: 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > After SOLR-10391 was implemented, users are now able to overwrite existing > configSets using the configSet API. However the files uploaded are still > required to be zipped and indexed from the base configSet path in ZK. Users > might want to just update a single file, such as a synonyms list, and not > have to tar it up first. > The proposed solution is to add parameters to the UPLOAD configSet action, to > allow this single-file use case. This would utilize the protections already > provided by the API, such as maintaining the trustiness of configSets being > modified. > This feature is part of the solution to replace managed resources, which is > planned to be deprecated and removed by 9.0 (SOLR-14766). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14915) Prometheus-exporter should not depend on Solr-core
[ https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215039#comment-17215039 ] Houston Putman commented on SOLR-14915: --- I think it makes sense to remain as a contrib module, so in the same repo. I think releasing the exporter individually would be a good idea, as well as creating a separate docker image. I had a PR for the docker-solr repo around a year ago that did something similar, but didn't get merged for various reasons. In general there is no reason why the two need to live together, so I'm all for it. I don't think there's any harm in providing the composite binaries, in addition to having the individual binaries available. More choices with little extra work for us :) > Prometheus-exporter should not depend on Solr-core > -- > > Key: SOLR-14915 > URL: https://issues.apache.org/jira/browse/SOLR-14915 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: patch.patch > > Time Spent: 40m > Remaining Estimate: 0h > > I think it's *crazy* that our Prometheus exporter depends on Solr-core -- > this thing is a _client_ of Solr; it does not live within Solr. The exporter > ought to be fairly lean. One consequence of this dependency is that, for > example, security vulnerabilities reported against Solr (e.g. Jetty) can (and > do, where I work) wind up being reported against this module even though > Prometheus isn't using Jetty. > From my evaluation today of what's going on, it appears the crux of the > problem is that the prometheus exporter uses some utility mechanisms in > Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit > hole goes deeper...) and DOMUtils (further depends on PropertiesUtil). It > can easy be made to not use XmlConfig. DOMUtils & PropertiesUtil could move > to SolrJ which already has lots of little dependency-free utilities needed by > SolrJ and Solr-core alike. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214775#comment-17214775
]
Houston Putman commented on SOLR-14907:
---
+1 on supporting the V2 API, but since it fits fairly well into the V1 API I'm
not sure we should make it V2 only. And I like the suggested path, though I
might change file-name to be a urlParam instead of a part of the path, because
it could contain multiple {{/}}s, which might be confusing.
According to the ref guide, the UPLOAD configSet command does not have a V2 API
yet. Maybe we create another ticket to add a v2 command for configSet upload,
and this can be a part of that ticket.
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14907) Support single file upload/overwrite in configSet API
[ https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-14907. --- Fix Version/s: 8.7 Resolution: Implemented > Support single file upload/overwrite in configSet API > - > > Key: SOLR-14907 > URL: https://issues.apache.org/jira/browse/SOLR-14907 > Project: Solr > Issue Type: Improvement > Components: configset-api >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Fix For: 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > After SOLR-10391 was implemented, users are now able to overwrite existing > configSets using the configSet API. However the files uploaded are still > required to be zipped and indexed from the base configSet path in ZK. Users > might want to just update a single file, such as a synonyms list, and not > have to tar it up first. > The proposed solution is to add parameters to the UPLOAD configSet action, to > allow this single-file use case. This would utilize the protections already > provided by the API, such as maintaining the trustiness of configSets being > modified. > This feature is part of the solution to replace managed resources, which is > planned to be deprecated and removed by 9.0 (SOLR-14766). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14907) Support single file upload/overwrite in configSet API
[ https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman reassigned SOLR-14907: - Assignee: Houston Putman > Support single file upload/overwrite in configSet API > - > > Key: SOLR-14907 > URL: https://issues.apache.org/jira/browse/SOLR-14907 > Project: Solr > Issue Type: Improvement > Components: configset-api >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > After SOLR-10391 was implemented, users are now able to overwrite existing > configSets using the configSet API. However the files uploaded are still > required to be zipped and indexed from the base configSet path in ZK. Users > might want to just update a single file, such as a synonyms list, and not > have to tar it up first. > The proposed solution is to add parameters to the UPLOAD configSet action, to > allow this single-file use case. This would utilize the protections already > provided by the API, such as maintaining the trustiness of configSets being > modified. > This feature is part of the solution to replace managed resources, which is > planned to be deprecated and removed by 9.0 (SOLR-14766). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14907) Support single file upload/overwrite in configSet API
Houston Putman created SOLR-14907: - Summary: Support single file upload/overwrite in configSet API Key: SOLR-14907 URL: https://issues.apache.org/jira/browse/SOLR-14907 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: configset-api Reporter: Houston Putman After SOLR-10391 was implemented, users are now able to overwrite existing configSets using the configSet API. However the files uploaded are still required to be zipped and indexed from the base configSet path in ZK. Users might want to just update a single file, such as a synonyms list, and not have to tar it up first. The proposed solution is to add parameters to the UPLOAD configSet action, to allow this single-file use case. This would utilize the protections already provided by the API, such as maintaining the trustiness of configSets being modified. This feature is part of the solution to replace managed resources, which is planned to be deprecated and removed by 9.0 (SOLR-14766). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14893) Allow UpdateRequestProcessors to add non-error messages to the response
Houston Putman created SOLR-14893: - Summary: Allow UpdateRequestProcessors to add non-error messages to the response Key: SOLR-14893 URL: https://issues.apache.org/jira/browse/SOLR-14893 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: UpdateRequestProcessors Reporter: Houston Putman There are many reasons why a UpdateRequestProcessor would want to send a response back to the user: * Informing the user on the results when they use schema-guessing mode (SOLR-14701) * Building a new Processor that uses the lucene monitor library to alert on incoming documents that match saved queries * The Language detection URPs could respond with the languages selected for each document. Currently URPs can be passed in the Response object via the URPFactory that creates it. However, whenever the URP is placed in the chain after the DistributedURP, the response that it sends back will be dismissed by the DURP and not merged and sent back to the user. The bulk of the logic here would be to add logic in the DURP to accept custom messages in the responses of the updates it sends, and then merge those into an overall response to send to the user. Each URP could be responsible for merging its section of responses, because that will likely contain business logic for the URP that the DURP is not aware of. The SolrJ classes would also need updates to give the user an easy way to read response messages. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14856) Add docker build & tests as a github action
[ https://issues.apache.org/jira/browse/SOLR-14856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14856: -- Affects Version/s: master (9.0) > Add docker build & tests as a github action > --- > > Key: SOLR-14856 > URL: https://issues.apache.org/jira/browse/SOLR-14856 > Project: Solr > Issue Type: Improvement > Components: Docker, github >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Currently we only run precommit as a github action. For master (9.0+) only, > we could add building and testing the Solr docker image as a test as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14856) Add docker build & tests as a github action
[ https://issues.apache.org/jira/browse/SOLR-14856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-14856. --- Fix Version/s: master (9.0) Resolution: Implemented > Add docker build & tests as a github action > --- > > Key: SOLR-14856 > URL: https://issues.apache.org/jira/browse/SOLR-14856 > Project: Solr > Issue Type: Improvement > Components: Docker, github >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Minor > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we only run precommit as a github action. For master (9.0+) only, > we could add building and testing the Solr docker image as a test as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14877) Add github PR Action for running SolrJ tests
[ https://issues.apache.org/jira/browse/SOLR-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198545#comment-17198545 ] Houston Putman commented on SOLR-14877: --- Locally the solrJ tests run in under 3 minutes. In the github action, the solrJ tests took 19 minutes. That is quite long for a github action, so I'm not necessarily keen on adding it yet. > Add github PR Action for running SolrJ tests > > > Key: SOLR-14877 > URL: https://issues.apache.org/jira/browse/SOLR-14877 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: github, SolrJ, Tests >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The gradle tests would only be run if the code within SolrJ is changed by the > PR. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14877) Add github PR Action for running SolrJ tests
Houston Putman created SOLR-14877: - Summary: Add github PR Action for running SolrJ tests Key: SOLR-14877 URL: https://issues.apache.org/jira/browse/SOLR-14877 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: github, SolrJ, Tests Affects Versions: master (9.0) Reporter: Houston Putman Assignee: Houston Putman The gradle tests would only be run if the code within SolrJ is changed by the PR. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14789: -- Description: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. Discussion around this feature has taken place on the [dev mailing list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E] and SOLR-11245. was: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. Discussion around this feature has taken place on the > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. > Discussion around this feature has taken place on the [dev mailing > list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E] > and SOLR-11245. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14789: -- Description: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. Discussion around this feature has taken place on the was: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. > Discussion around this feature has taken place on the -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[
https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196202#comment-17196202
]
Houston Putman commented on SOLR-14789:
---
{quote}victim of poor JIRA management
{quote}
That's fair. I was trying to clean up the JIRA and break it up into logical
tasks, but I can see how that obfuscated the discussion. I'll update the ticket
to include links to relevant discussions.
{quote}Do we agree that we should use Alpine? Do we agree that we should
support something like "pre-create" collections? Have we done a security audit
of the merged code and are we sure that the containers are production ready and
secure? These are questions I'd have appreciated if we discussed before diving
straight into a code merge.
{quote}
So I think that these questions are much more easily addressed now. The
consensus from the various discussions on the topic was that the code should be
migrated to lucene-solr. Now that the (peer-reviewed) code lives in
lucene-solr, all of these implementation questions are relatively independent,
and can be addressed without blocking each other. If you look at the parent
issue, SOLR-14168, there are many tasks that are on the roadmap. The work on
these items can be done in manageable chunks. That PR was never meant to be a
"final product". This was to get us started so that we can more easily improve
it for the 9.0 release.
There are really good ideas around reducing the footprint of
{{/solr/docker/include/scripts}} (formerly {{docker-solr/scripts}}), but
working on and testing these ideas will be much easier having all of the code
in one place. For example, you can take functionality from docker/scripts and
add it to solr/bin, or solr itself, and have a one step build and test.
I think a security audit would be great, but wouldn't that also be necessary
when bringing it in as a separate repo? I honestly think that would be a very
valuable thing to add as a gradle task in this module. Can you create a Jira
under the parent ticket to get a security audit created? I'm by no means a
security expert, so while I'm happy to help with the work I should probably not
be defining the problem.
Side note, we don't use alpine for anything. Mike brought up this concern in
the PR and it was replaced with {{scratch}}.
{quote}non-essential to Solr's core
{quote}
I don't necessarily agree with this. It is clear that much of the world is
moving to containerized/serverless deployments. Using Solr in a container
should be a fully supported paradigm, just as we support unix and windows
systems through {{solr/bin}}. Also having the image as a part of the official
project will help us move Solr in the direction of being more docker
friendly/cloud native.
As for the increase in PRs/JIRA issues. I would hope that a lot of the
questions move to the mailing lists, which I have seen used already. There are
less than 15 PRs from docker-solr over the last year that are actually relevant
to it's current form in {{lucene-solr}}, so I don't think it's going to be a
large burden to deal with. If there are a large number of PRs, then that's even
better. We'll have an even greater docker image for the future!
> Absorb and maintain docker-solr functionality for Solr 9.0+
> ---
>
> Key: SOLR-14789
> URL: https://issues.apache.org/jira/browse/SOLR-14789
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Blocker
> Fix For: master (9.0)
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Migrate the docker image building and testing from the
> [https://github.com/docker-solr/docker-solr] repo into Solr. This is only
> applicable for 9.0+. Backporting Docker functionality to Solr 8x will be
> handled separately.
>
> This is meant to be a first pass migration and not solve all issues. The goal
> is:
> * Docker images be built in a flexible way that will allow for release and
> local builds to share the same business logic
> * Building and testing should be integrated with the gradle build
> * Maintain current usage documentation in their current form, but
> documentation on building images should go in the ref-guide. The usage
> documentation will be migrated separately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195826#comment-17195826 ] Houston Putman edited comment on SOLR-14789 at 9/15/20, 2:41 AM: - There isn't discussion on this ticket, but that doesn't mean that there wasn't discussion happening. Discussion happened on [JIRA|https://issues.apache.org/jira/browse/SOLR-11245], the [dev list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E], [slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1597865287041800] and obviously the [github PR|https://github.com/apache/lucene-solr/pull/1769]. I think that covers the bases pretty well. Re-reading those, there's discussion from multiple community members, committers & PMC members and I see many opinions that the docker-solr repo should be rehomed to lucene-solr. I'm also not sure how this was a code dump. The PR had comments from 5 community members, all of which were addressed and iterated on. The PR was open for 3 weeks and you were even tagged from the first day, but did not reply or give any feedback. I understand that you are busy and have other things that are going on, but there has been over a month of discussion (plus the mailing list from back in february). I very much believe that the code that generates the solr docker image should live in the same repo as Solr, and I'm happy to discuss that further. As mentioned in the title of the issue, this is only meant for master, so there is time for us to improve the docker images for 9.0+ as well as the processes for generating them. The docker-solr repo will continue to be used for 8.x releases. was (Author: houston): There isn't discussion on this ticket, but that doesn't mean that there wasn't discussion happening. Discussion happened on JIRA, the [dev list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E], [slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1597865287041800] and obviously the [github PR|https://github.com/apache/lucene-solr/pull/1769]. I think that covers the bases pretty well. Re-reading those, there's discussion from multiple community members, committers & PMC members and I see many opinions that the docker-solr repo should be rehomed to lucene-solr. I'm also not sure how this was a code dump. The PR had comments from 5 community members, all of which were addressed and iterated on. The PR was open for 3 weeks and you were even tagged from the first day, but did not reply or give any feedback. I understand that you are busy and have other things that are going on, but there has been over a month of discussion (plus the mailing list from back in february). I very much believe that the code that generates the solr docker image should live in the same repo as Solr, and I'm happy to discuss that further. As mentioned in the title of the issue, this is only meant for master, so there is time for us to improve the docker images for 9.0+ as well as the processes for generating them. The docker-solr repo will continue to be used for 8.x releases. > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195826#comment-17195826 ] Houston Putman commented on SOLR-14789: --- There isn't discussion on this ticket, but that doesn't mean that there wasn't discussion happening. Discussion happened on JIRA, the [dev list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E], [slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1597865287041800] and obviously the [github PR|https://github.com/apache/lucene-solr/pull/1769]. I think that covers the bases pretty well. Re-reading those, there's discussion from multiple community members, committers & PMC members and I see many opinions that the docker-solr repo should be rehomed to lucene-solr. I'm also not sure how this was a code dump. The PR had comments from 5 community members, all of which were addressed and iterated on. The PR was open for 3 weeks and you were even tagged from the first day, but did not reply or give any feedback. I understand that you are busy and have other things that are going on, but there has been over a month of discussion (plus the mailing list from back in february). I very much believe that the code that generates the solr docker image should live in the same repo as Solr, and I'm happy to discuss that further. As mentioned in the title of the issue, this is only meant for master, so there is time for us to improve the docker images for 9.0+ as well as the processes for generating them. The docker-solr repo will continue to be used for 8.x releases. > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14856) Add docker build & tests as a github action
[
https://issues.apache.org/jira/browse/SOLR-14856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195450#comment-17195450
]
Houston Putman commented on SOLR-14856:
---
I understand your concern. Initially I did this just as a POC, but after
looking at the available configurations I think it would be a good addition.
Github Actions allow you to only run a specified task if certain paths are
changed in the PR. So by setting those paths to {{solr/docker}}, {{solr/bin}},
{{solr/packaging}} and {{solr/contrib/prometheus-exporter/bin}} for the Docker
tests, we can test those components fairly well without affecting PRs for other
components.
But this was just an idea I had, It's ok if the consensus is that the
cost/reward is not there.
> Add docker build & tests as a github action
> ---
>
> Key: SOLR-14856
> URL: https://issues.apache.org/jira/browse/SOLR-14856
> Project: Solr
> Issue Type: Improvement
> Components: Docker, github
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Minor
>
> Currently we only run precommit as a github action. For master (9.0+) only,
> we could add building and testing the Solr docker image as a test as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14858) Create docker test for the prometheus exporter
Houston Putman created SOLR-14858: - Summary: Create docker test for the prometheus exporter Key: SOLR-14858 URL: https://issues.apache.org/jira/browse/SOLR-14858 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: Docker, Tests Affects Versions: master (9.0) Reporter: Houston Putman Currently there are a fair number of tests for running the Solr docker image, however none of them actually test running the prometheus exporter from within the image. This should spin up a solr container as well as a prometheus exporter container that collects metrics from the solr container. Check that the metrics endpoint is available and sends back results. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14857) Parallelize Solr Docker tests
Houston Putman created SOLR-14857: - Summary: Parallelize Solr Docker tests Key: SOLR-14857 URL: https://issues.apache.org/jira/browse/SOLR-14857 Project: Solr Issue Type: Improvement Components: Docker, Tests Affects Versions: master (9.0) Reporter: Houston Putman Currently the Solr docker tests are run concurrently. The contexts and image names are all unique, so there is no reason they can't be run in parallel. I would imagine that this would be a configuration passed to the gradle task, which already has command line options for specifying tests to skip or tests to run. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14856) Add docker build & tests as a github action
[ https://issues.apache.org/jira/browse/SOLR-14856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14856: -- Parent: (was: SOLR-14168) Issue Type: Improvement (was: Sub-task) > Add docker build & tests as a github action > --- > > Key: SOLR-14856 > URL: https://issues.apache.org/jira/browse/SOLR-14856 > Project: Solr > Issue Type: Improvement > Components: Docker, github >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Minor > > Currently we only run precommit as a github action. For master (9.0+) only, > we could add building and testing the Solr docker image as a test as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
