-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solr tweaks #1466
Solr tweaks #1466
Conversation
Again back to https://github.com/sunspot/sunspot#manually-adjusting-solr-parameters Based on console testing, it could also work to remove |
Generated by 🚫 Danger |
OK, here i'm stuck -- bc based on my testing on the Solr console on staging, we need to set I can try some other variations, like |
Trying |
Should be able to test this with http://staging.laboratoriopublico.org/searches/test/test?q=stk500_recv |
Unfortunate... @icarito -- any inspirations? In summary: We know the exact Solr query we want, we just can't get Sunspot to create it. Alternatively, we aren't sure why the default Sunspot-generated query (with Actually, to be specific, using |
Added more detail to the sunspot issue and opened one on Stack Overflow: https://stackoverflow.com/questions/44617017/difficulty-getting-more-than-exact-field-match-results-on-sunspot-solr-with-qf |
Trying to set
And full results... |
OK, another variation which worked on external Solr but did not pass embedded solr tests: Failure:
<[]> expected to be != to
<[]>.
test_should_get_search_test_action(SearchesControllerTest)
test/solr/searches_controller_test.rb:23:in `block in <class:SearchesControllerTest>' Sebastian -- the alternative here is that we could simply drop support of the embedded gem What would that take? Changes to:
This seems like a way forward even if we don't figure out what's going on. I suspect the embedded solr is just an older version and is not responding to the same queries in the same ways. Maybe it's not using |
Actually i like this plan a lot. It's closer to how we'll be deploying anyways. |
Attempting these steps now -- not 100% sure of the |
86f9ac1
to
b02f033
Compare
Seems close -- solr container starts up, but it seems to run /after/ |
301b4a1
to
418233c
Compare
Hmm, so what is going on here? Can you push up a copy without logging on, not a force push? What's the specific error? |
418233c
to
f6ede88
Compare
Logging is the only place where we are seeing the actual error. |
Ok, so the reindex appears to be working fine. I'll try to reproduce in a local environment. |
Hi, Sebastian -- how's this going? |
I don't why, I thought we had solved it. Likely needs a last push, will review it now. Sorry! |
I've merged this into |
Yikes! So staging should have its own index, right? Is that then in
sunspot.yml?
…On Tue, Jul 11, 2017 at 3:18 PM, Sebastian Silva ***@***.***> wrote:
I've merged this into unstable branch so that we can use jenkins to track
this.
This made me notice that in our current setup, staging and production are
sharing the same pad.publiclab.org Solr index! At one point I stopped the
Solr container in pad.publiclab.org and experienced a 500 error in
publiclab.org/dashboard! So I think we need to doublecheck our fallbacks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1466 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABfJ9AIBdr0KrCbRyTJVI33e4CjvN9kks5sM8p3gaJpZM4N7ue8>
.
|
Yes! I've closed the firewall at pad.publiclab.org to only accept connections from publiclab.org (dropping requests from tycho.media.mit.edu). That should ensure isolation from staging. I'm going to set SOLR_URL in Jenkins, it should override the config in |
In fact, having firewalled tycho from pad.publiclab.org should affect staging and allow to debug the fallback. Checking it... |
I'm not seeing the staging server fail after restricting access to pad.publiclab.org. I'll check it further tonight. |
My fault, I had put the wrong address in SOLR_URL env variable in jenkins config. It appears to be working fine after changing it. |
I think staging is working except without access to Solr. I'll have a closer look tonight. |
Okay I was trying to reindex tonight and got this:
This is because the firewall is set to DROP and I guess the Solr-check is timing out instead of immediately failing, taking a long time. I'll make a patch to enable Solr container in |
@jywarren sincerely I've spent a lot of time on this one and I can't tell why it's failing. I would appreciate your help. |
Ok we can look at this tomorrow! Thanks for spending time on this. My first thought is can we view and reproduce this query directly on solr console on staging. |
Today Jeff and I worked on this, configuring the staging environment to run from the test RAILS_ENV, and discovered that the indexer was indexing the seed data instead of the test data. We're attempting to reindex after the original tests have been run, to see if it will include the test data. |
YESS! |
HOORAAYYYYYYYY lets get this on staging fast! |
Ready to merge, right? if so, can you hit merge and i'll push to staging? |
Yes, please!
…On 13/07/17 14:43, Jeffrey Warren wrote:
Ready to merge, right? if so, can you hit merge and i'll push to staging?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1466 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMMSxZlxbVkiuOYcMW7bXRsIo5-4W1Uks5sNnNdgaJpZM4N7ue8>.
|
Note that staging will be broken until I restore the staging database from a dump. I can do it later today. |
Staging is back with a reindexed solr container, all lights green. |
rake test:all
Please be sure you've reviewed our contribution guidelines at https://publiclab.org/wiki/contributing-to-public-lab-software
We have a loose schedule of reviewing and pulling in changes every Tuesday and Friday, and publishing changes on Fridays. Please alert developers on plots-dev@googlegroups.com when your request is ready or if you need assistance.
Thanks!