15:00:11 #startmeeting 2022-03-08 - Developer Meeting 15:00:11 Meeting started Tue Mar 8 15:00:11 2022 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:11 The meeting name has been set to '2022_03_08___developer_meeting' 15:00:15 #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2022-03-08 15:00:24 #topic Introductions 15:00:25 #info JBoyer = Jason Boyer, EOLI 15:00:26 #info abowling = Adam Bowling, Emerald Data Networks 15:00:33 Whois 15:00:46 #info phasefx = Jason Etheridge, EOLI 15:00:46 #info dluch = Debbie Luchenbill, MOBIUS 15:00:48 #info mmorgan = Michele Morgan, NOBLE 15:00:51 #info csharp = Chris Sharp, GPLS 15:00:51 #info sandbergja = Jane Sandberg, Evergreen enthusiast 15:00:58 #info collum = Garry Collum, KCPL 15:01:02 #info shulabear = Shula Link, GCHRL in GAPines 15:01:09 sandbergja++ 15:01:09 #info berick Bill Erickson, KCLS 15:01:16 sandbergja++ 15:01:29 @who is an Evergreen enthusiast? 15:01:29 eglogbot is an Evergreen enthusiast. 15:01:29 sandbergja++ 15:01:34 pinesol: nah 15:01:34 csharp_: uh huh.. please tell me more about that 15:01:50 Yay! Hi, sandbergja!! 15:02:06 sandbergja++ 15:02:09 heya! 15:02:21 Ok, people can feel free to #info-up as they arrive. 15:02:24 #info terranm Terran McCanna, PINES 15:02:58 Lots of placeholders today, so lets skip ahead a little. 15:03:07 #topic Documentation 15:03:09 #info Minutes from March 3 meeting can be found here: https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:dig_meetings 15:03:14 #info We are updating and reorganizing the official docs and are going to need devs to check over some of the documentation for installation, configuration/customization, etc. to make sure it's complete and correct. So please keep an eye out for those asks! 15:03:27 DIG folks, anything to add to those? 15:03:32 Nope! 15:03:40 dluch++ 15:03:51 dluch++ 15:04:00 dig++ 15:04:02 #topic Launchpad Status - snapshots 15:04:02 #info Open Bugs - 2683 15:04:09 #info Pullrequests - 115 15:04:09 #info Signedoff - 44 15:04:18 #topic Launchpad Status - Updates 15:04:18 v 15:04:20 #info Bugs Added - 35 15:04:29 #info Pullrequest tag Added - 17 15:04:29 #info Signedoff tag Added - 5 15:04:33 #info Fix Committed - 10 15:04:47 And finally on to 15:04:47 #topic New Business 15:04:55 #info LP 1787968 - How to track down errors for files that look like they should work 15:04:56 Launchpad bug 1787968 in Evergreen "Wishlist: Cover image uploader" [Wishlist,Confirmed] https://launchpad.net/bugs/1787968 - Assigned to Michele Morgan (mmorgan) 15:05:00 mmorgan ? 15:05:24 This is looking really good, but some uploads fail inexplicably 15:05:35 Just looking for clues to figure out why. 15:05:57 I ... think I opened the wrong bug then 15:06:01 Can't find anything logged on the server. 15:06:27 mmorgan: do you have nginx in front of everything? 15:06:45 phasefx: no, I don't 15:07:02 mmorgan: be sure to check the stderr logs in /openils/var/log too 15:07:07 k. I've seen file limits enforced in nginx cause problems 15:07:39 OH! I have had some fun with this on my personal instance. :/ In my case POSTs are being redirected with 301's, which then turns them into GETs which doesn't get it. 15:07:40 * mmorgan has checked the stderr logs and haven't seen anything there 15:07:58 oh yeah, could be similar to the request size thing we hit where ejabberd croks? 15:08:05 er... croaks 15:08:41 mmorgan, do you have any proxy setup or do both apache and websocketd listen live on the external IP? 15:09:14 JBoyer: no proxy involved 15:09:18 Because I think apache can have an upload size limit but I don't know what the default is. 15:09:30 it's sad, but my debugging method of choice would be to sprinkle log output througout the code and see what spits out last 15:09:51 Wouldn't it be logged somewhere if a limit were hit? 15:10:21 Maybe. It's hard to say, and definitely wouldn't hit OpenSRF / Evergreen logs. 15:11:32 I want to say I've seen those pop in the apache logs when I've had them, but don't quote me on that. 15:11:39 If you're using the Evergreen rsyslog config it could be in the apache logs, otherwise probably in /var/log/apache2/* 15:11:55 mmorgan: look into wireshark/tshark or tcpdump as the upload is happening 15:12:06 mmorgan: the uploads that cause problems are consistent? send me a link to a file and I can look later 15:12:15 (on the receiving server) 15:12:39 I can at least confirm or rule out whether it's the file or the environment 15:13:00 phasefx: Yes, the failures are consistent. 15:13:25 * mmorgan will provide a link 15:13:30 mmorgan++ 15:14:15 So basically turn up logging to the max and scour every log, will give that a try. 15:14:58 transparent proxy (this file is a virus) 15:15:33 mmorgan: that was marginally useful for me - those logs are super dense 15:15:52 unless this is on a low-traffic server 15:15:54 * phasefx can't tell you how many times leaving the log details up has caused him to run out of disk space :) 15:16:00 oh yea 15:16:30 test server, so should be ok :) 15:16:52 Thanks for the tips! 15:16:56 mmorgan++ 15:16:59 phasefx++ 15:17:03 csharp_++ 15:17:15 phasefx++ 15:17:22 Ok, any other new business or last minute bolts of inspiration lightning? 15:17:23 csharp_++ 15:17:26 👍 15:17:47 csharp_++ 15:17:51 mmorgan++ 15:17:55 phasefx++ 15:18:16 one thing about the cover uploader since we're talking about it 15:18:34 * rfrasur gets her ears all atune. 15:18:35 it will basically require multi-server environments to use an NFS share for cover images 15:19:05 IIRC if the connection to the NFS server hangs it will cause OPAC pages with cover images to fail to load 15:19:38 I haven't had a chance to reproduce this yet but wanted to flag it early 15:20:23 could do less real-time and more klunky stuff, but yeah 15:21:01 I don't think it should block the new feature from being committed or anything, just something to look out for once the feature goes in 15:21:23 * mmorgan also has one more comment 15:21:46 but the problem space should be explored already for a given installation with regards to reports 15:22:04 On my test server, I had to create the directories for the cover images, so thought mention of that should go in release notes. 15:22:11 Yeah, that's worth documenting since I think this is the one use of shared space that could cause patron-facing problems. (Though I don't know what happens if the existing custom covers stuff isn't repsonding) 15:23:50 anyway I'll test more and file a bug when I can 15:24:14 jeffdavis++ 15:24:18 jeffdavis++ 15:24:45 mmorgan, I forgot the vandelay settings had an effect here, make sure that your importer directory isn't /tmp, because that doesn't work on more recent Ubuntu and Debian releases. 15:25:13 Something like /openils/var/data/vandelay is a good alternative (that would also need to be created) 15:25:47 Speaking of, we should change that in the example config because /tmp doesn't work on single-server installs anymore etiehr. 15:25:48 JBoyer: Good thought, but that's not the issue. Many files upload just fine. 15:25:57 Ah, well. 15:26:28 May have something to do with files that have been manipulated. 15:27:17 But they still fit the specs re size and type 15:27:26 Hmm, possibly something abut metadata tags that the perl modules don't like. 15:27:51 Anyway, things to consider once this meeting is wrapped. 15:27:54 #topic Announcements 15:27:58 #info Next Meeting is April 12, 2022 15:28:06 #endmeeting