| Time |
Nick |
Message |
| 00:52 |
|
sleary joined #evergreen |
| 07:15 |
|
dickreckard joined #evergreen |
| 07:16 |
dickreckard |
hello everyone :) |
| 07:16 |
dickreckard |
we are some evergreen maintainers for a small uni library with an upgrade dilemma.. |
| 07:20 |
dickreckard |
we skipped quite many upgrades ( we are still running 3.2.2 ). we are now installing new servers, and we are really wondering if its best to go through all the ~30 sql upgrades to bring the db up to the newer version, with many possible hiccups, or if to export all patrons and all records and items, and batch-re-import everything into a new installation, preparing a sheet to re-insert all |
| 07:20 |
dickreckard |
currently active circulations, loans etc (probably losing circulation history) |
| 07:21 |
dickreckard |
would be really helpful to hear some opinions or experience with this ^^ thanks! |
| 07:31 |
|
collum joined #evergreen |
| 07:59 |
|
BDorsey joined #evergreen |
| 08:23 |
JBoyer |
dickreckard, I've helped with some upgrades that skipped about that many versions, there are only a couple places that things could get weird or take a long time, |
| 08:23 |
JBoyer |
and if you setup a test database (you don't even need the newer version of Evergreen running to test the upgrade scripts) you should be able to plan for all of those. |
| 08:24 |
JBoyer |
And since all of the upgrade scripts either work or don't you don't have to worry about the db being left in a hard-to-debug state. |
| 08:28 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:51 |
Bmagic |
csharp_: I'm starting on that machine, should have something soon |
| 08:53 |
Bmagic |
Making coffee first :) |
| 08:54 |
Dyrcona |
@coffee [someone] |
| 08:54 |
* pinesol |
brews and pours a cup of Ruvuma Tanzanian Peaberry, and sends it sliding down the bar to eby |
| 08:58 |
|
terranm joined #evergreen |
| 09:12 |
|
kmlussier joined #evergreen |
| 09:17 |
|
JBoyer joined #evergreen |
| 09:17 |
dickreckard |
JBoyer: thanks a lot for the input! In what sense updates either work or don't? so you think we might get stuck with a db that can't update further? |
| 09:19 |
Bmagic |
dickreckard: I would go with the sql script upgrade approach. It would be much less time consuming |
| 09:20 |
JBoyer |
Well, for example, if you run the 3.2.2-3.2.3-upgrade-db.sql script, it will either work entirely leaving your db as expected for a 3.2.3 system, or it will fail and tell you what went wrong so you can fix the issue and then run the script again. |
| 09:20 |
JBoyer |
And if an upgrade fails, it rolls back every change it tried to make, so you'd be left with the same 3.2.2 db that you had before trying to apply the update. |
| 09:22 |
Bmagic |
JBoyer speaks truth! And I'll echo him: we always practice the upgrade SQL scripts on a test copy of the database in order to see which ones fail and why. Make the required adjustments to the SQL scripts to fit our database needs. Most* of the time we don't have to make changes. You won't know until you try |
| 09:23 |
|
dguarrac joined #evergreen |
| 09:30 |
Dyrcona |
dickreckard: Do you have access to another PostgreSQL database where you can test the database upgrade? |
| 09:33 |
|
smayo joined #evergreen |
| 09:33 |
* Bmagic |
waves at smayo |
| 09:34 |
|
jvwoolf joined #evergreen |
| 09:34 |
* Bmagic |
waves at jvwoolf |
| 09:35 |
* jvwoolf |
waves at Bmagic |
| 09:35 |
* smayo |
waves at Bmagic |
| 09:35 |
Bmagic |
It's gonna be a glorious day |
| 09:36 |
* jvwoolf |
is WFH on the couch with a sick baby |
| 09:36 |
Bmagic |
Evergreen is the best ILS on the planet and today we level it up |
| 09:36 |
jvwoolf |
Living the dream LOL |
| 09:36 |
Bmagic |
jvwoolf++ |
| 09:36 |
jvwoolf |
Bmagic++ |
| 09:36 |
jvwoolf |
#1 hype man |
| 09:37 |
Bmagic |
Can I get an Eeeeee! |
| 09:37 |
Dyrcona |
So, fun with autorenewals on a test system: 1 failed to renew last night because the circ drone couldn't get a transaction. Nothing in the Pg logs about it, except "there is not transaction in progress." |
| 09:37 |
smayo |
Eeeeee |
| 09:37 |
Dyrcona |
Very next autorenew event gets an error state, but from looking at the database and the logs, it actually succeeded. Both process by the same trigger drone. |
| 09:38 |
jvwoolf |
https://www.youtube.com/watch?v=0ipbu4msLSw |
| 09:38 |
dickreckard |
Bmagic: Dyrcona JBoyer, yes will go with the test db! thank you all for help :) |
| 09:38 |
Dyrcona |
No reason at all for the second to have the state='error'. |
| 09:39 |
Bmagic |
jvwoolf++ # love that battle cry |
| 09:39 |
Dyrcona |
dicreckard: I recommend you try this: https://gist.github.com/Dyrcona/00bd6b6290b6fbbb579c7f93b360ab0d It will create a database upgrade script between two arbitrary Evergreen versions. It requires git, and I guarantee the script will not work on the first try. |
| 09:39 |
Bmagic |
smayo++ # Evergreen is a long word and we'd fill up chat, but I'm glad you're with me! |
| 09:40 |
Bmagic |
Dyrcona: My theory is the drone is "bad" but continues to try to do stuff when it should be recycled |
| 09:42 |
Dyrcona |
Bmagic: Everything else processed by that drone is OK. It was also a circ drone that couldn't get a transaction (pid 60075). The other renewals was done by pid 60069, and it was OK. I checked for 'ERR :{pid}' for all of the associated cstore processes and got zip for the second one. |
| 09:43 |
|
kworstell-isl joined #evergreen |
| 09:44 |
Dyrcona |
There seem to be two things that happen with some frequency: circ can't get a transaction to renew and a/t event autocreate fails to find the AuroreneNotify event via hook. It looks like we had one of the latter in production last night. |
| 09:47 |
terranm |
If it was anyone but Bmagic, I'd think they got hacked |
| 09:48 |
terranm |
But I like that Bmagic-style hype |
| 09:52 |
|
kmlussier1 joined #evergreen |
| 09:52 |
Dyrcona |
:) |
| 09:56 |
Dyrcona |
Both events have the same update_time: 2024-03-21 05:43:13.394412-04. I think that might be significant. That they're being updated at the same time. |
| 10:04 |
Bmagic |
terranm++ # lol, good to know that yall know what I would type so you know when to be suspicious hahaha |
| 10:05 |
terranm |
Bmagic++ |
| 10:10 |
Bmagic |
csharp_: https://bugsquash3.mobiusconsortium.org is up and running at your service. I did login and test placing a hold and it worked! bugsquash2 has several patches that are candidates for having broke holds. I'll figure out which one and post on the bug |
| 10:15 |
|
kworstell_isl joined #evergreen |
| 10:16 |
|
kworstell_isl_ joined #evergreen |
| 10:24 |
Dyrcona |
ooh. got a real dead lock in a test system on Sunday: Process 3401997 ... blocked by process 3402007. ...Process 3402007 ... blocked by process 3401997. |
| 10:26 |
Dyrcona |
Looks like the hold targeter blocked a process trying to reindex the action.hold_request table and vice versa. |
| 10:26 |
* Dyrcona |
changes the hold targeter schedule. |
| 10:27 |
|
kworstell-isl joined #evergreen |
| 10:46 |
|
kenstir joined #evergreen |
| 10:48 |
|
sleary joined #evergreen |
| 10:49 |
Rogan |
dickreckard I'm late to the party but echo jboyer's statement, just exporting isolated tables and reimporting them will be a bigger pain than the sql upgrades and you will lose a lot of data |
| 11:01 |
Dyrcona |
pg_dump/pg_restore usually does not work if the schema has changed. |
| 11:02 |
kenstir |
Can I get a clue how to set up my test server for Stripe payments? I have a stripe account, and I used the library settings editor to add things to BR1, but the BR1 patron with a fine does not see any "pay fines" button. Screenshot: https://launchpadlibrarian.net/720500896/2024-03-20-Library-Settings-Editor.png |
| 11:04 |
Dyrcona |
kenstir: You added your test settings for stripe and enabled stripe as the cc processor? If so, you should be able to "pay" with one of the stripe test cards. See the strip documentation. |
| 11:05 |
kenstir |
Dyrcona Yes I did but the issue is I don't see any pay button in EG when logged in as the patron. I do see the fine. |
| 11:06 |
Dyrcona |
you restarted services and apache2 after making the settings changes? they don't always have an immediate effect. |
| 11:06 |
mmorgan |
kenstir: Did you set the library setting Allow Credit Card Payments (credit.payments.allow) to TRUE also? |
| 11:09 |
kenstir |
mmorgan: thanks looks like I didn't |
| 11:09 |
Dyrcona |
mmorgan++ |
| 11:09 |
kenstir |
Dyrcona: no I didn't |
| 11:10 |
kenstir |
mmorgan++ |
| 11:14 |
kenstir |
That setting worked! "Your payment has been approved" This makes me unreasonably happy |
| 11:15 |
terranm |
kenstir++ |
| 11:15 |
Dyrcona |
kenstir++ |
| 11:16 |
sleary |
kenstir++ mmorgan++ Dyrcona++ |
| 11:20 |
mmorgan |
kenstir++ |
| 11:58 |
|
jihpringle joined #evergreen |
| 12:15 |
|
adam_reid joined #evergreen |
| 12:18 |
|
jvwoolf joined #evergreen |
| 12:20 |
adam_reid |
Hey all! Does anyone have experience using the 856 data for cover images in Evergreen? Imported records from hoopla define the fields (example: =856 42$zCover image$uhttps://d2snwnmzyr8jue.cloudfront.net/wgu_wgu03624v_180.jpeg) |
| 12:22 |
adam_reid |
I've done a few data dumps in my templates but haven't seen the data anywhere. I'm not familiar with how to pull directly from the marc record (or if it's possible?) |
| 12:41 |
|
adam_reid joined #evergreen |
| 12:50 |
terranm |
adam_reid: I know you can access the MARC record in the OPAC templates - you might take a look at /templates-bootstrap/opac/parts/contents-summaryonly.tt2 which is pulling the 520 field |
| 12:51 |
terranm |
The /opac/parts/misc_util.tt2 file has more examples |
| 12:53 |
adam_reid |
ok, I'll dig into that one a bit further. Is most data in the MARC record available in the OPAC template typically? |
| 12:55 |
|
jvwoolf joined #evergreen |
| 12:56 |
terranm |
Yes, as far as I know |
| 12:59 |
Bmagic |
adam_reid: yes, the entire XML is available for processing and display in the TT2 templates. misc_util.tt2 does most of the heavy lifting. A couple other files parse other things like: authors.tt2, contents.tt2, series.tt2 |
| 13:02 |
adam_reid |
amazing, thank you both, I can see examples using xpath, great to see |
| 13:03 |
Dyrcona |
adam_reid: If you want to download cover images, then you might want to also look at Open-ILS/src/perlmods/lib/OpenILS/Application/Search/AddedContent.pm and Open-ILS/src/templates-bootstrap/opac/parts/record/addedcontent.tt2 |
| 13:04 |
adam_reid |
awesome, will do! |
| 13:05 |
adam_reid |
side question, is it possible to enable error reporting in my tt2 templates? so far I've been going by trial and error |
| 13:06 |
adam_reid |
I suppose that would be configured in apache, I read through some of the config but nothing stood out |
| 13:08 |
Dyrcona |
adam_reid: Templates are processed about line 128 in Open-ILS/src/perlmods/lib/OpenILS/WWW/EgWeb.pm If you set a "debug_template" option to true the Template::Toolkit debugging code will be activated. |
| 13:09 |
adam_reid |
perfect, thanks Dyrcona I'll make a note and see if I can get that working too |
| 13:10 |
Dyrcona |
Looks like you turn it on by changing "false" to "true" on line 655 of pen-ILS/examples/apache_24/eg_vhost.conf.in. |
| 13:11 |
Dyrcona |
oops. the leading "O" got cut off. |
| 13:36 |
Dyrcona |
berick++ poking at KeyDB. |
| 13:37 |
Dyrcona |
berick: A similar thing happens with MariaDB versus MySQL. Pretty much all of the MariaDB applications and variables are the same as those in MySQL. |
| 14:10 |
berick |
Dyrcona: yeah, and I'll probably be poking at https://opensearch.org/ before too long as an Elastic replacement. |
| 14:12 |
jeffdavis |
Are we ok to officially recommend disabling JIT in Postgres? I don't recall if anyone had reservations about turning it off. (bug 2042158) |
| 14:12 |
pinesol |
Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] https://launchpad.net/bugs/2042158 - Assigned to Galen Charlton (gmc) |
| 14:18 |
Dyrcona |
jeffdavis: I have reservations about turning it off, but I have not made them public. If we have queries that cause issues with the JIT we should probably fix the queries. I have not turned off JIT in my Pg 15 and Pg 16 test databases and I've not encountered the issue described in the bug. All of that said, don't let just me stop anything from going forward. |
| 14:23 |
Dyrcona |
Speaking of PostgreSQL settings, this is mainly for Bmagic: I think I'm going back to 1.1 for random_page_cost. A couple of queries that I've run since setting it to 1.0 seem slower. |
| 14:25 |
Dyrcona |
... on Pg10 anyway. |
| 14:40 |
JBoyer |
I haven't weighed in much on that or had much time to do much lately but feel the same as Dyrcona re: turning off the JIT unconditionally. |
| 14:54 |
|
kworstell_isl joined #evergreen |
| 14:54 |
|
kworstell_isl_ joined #evergreen |
| 14:55 |
Bmagic |
I agree that we need to re-work our code to be JIT friendly. But in the meantime.... disabling it fixed it for our production environment running PG15. |
| 14:56 |
|
jihpringle joined #evergreen |
| 15:03 |
|
abowling joined #evergreen |
| 15:31 |
|
kworstell-isl joined #evergreen |
| 15:55 |
|
book` joined #evergreen |
| 16:20 |
* Bmagic |
wonders if csharp_ got back to that bug |
| 17:08 |
|
mmorgan left #evergreen |
| 18:17 |
|
Stompro joined #evergreen |
| 18:43 |
|
Stompro joined #evergreen |
| 21:45 |
|
sleary joined #evergreen |
